RFC3093_防火墙增进协议 (FEP)

发表于 4年以前  | 总阅读数:639 次
 组织:中国互动出版网(http://www.china-pub.com/)
RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail:ouyang@china-pub.com
译者:高鹏(g622   g622@xanet.edu.cn)
译文发布时间:2001-5-11
版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须
保留本文档的翻译及版权信息。 



Network Working Group                                           J. Myers
Request for Comments: 2554                       Netscape Communications
Category: Standards Track                                     March 1999


SMTP服务认证扩展
(RFC 2554 SMTP Service Extension for Authentication)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.


1. 简介

   本文档定义扩展邮件服务,一个SMTP(简单邮件传输协议)的客户端和服务器之间可以存
在一种认证机制,执行认证协议的交互,并为以后的邮件协议交互进行安全层次的协商。这
个扩展是SASL(简单认证与安全层)的一个方面。
   

2. 本文档中的约定
   在示例中,“c:”和“s:”分别代表了客户端和服务器端发送的数据行。
 
   本文中,关键词MUST", "MUST NOT", "SHOULD", "SHOULD NOT",  "MAY"和"Key 
words for use in RFCs to Indicate Requirement Levels"中的定义一致。

3. 验证服务扩展

   (1)  这种SMTP扩展服务的名称是“认证”。
   
   (2)  和本扩展服务关联的EHLO关键字的值是“AUTH”

   (3) AUTH EHLO关键字 是一个有空格间隔的被SASL机制支持的名字列表的参数。
   
   (4) 定义了一个新的SMTP协议的命令词 AUTH。
  
   (5) 关键词AUTH被用做一个可选的参数被加入MAIL FORM 命令中并把MAIL FROM 
命令行的的最大长度扩展到500个ansi字符。
  
   (6) 此扩展和委托协议兼容(the submission protocol [SUBMIT])。


4. AUTH命令
   
   AUTH机制 [初始化响应]

   参数:
     判别是一个SASL认证机制的字符串。

     可选的由base64编码的响应。

   约束:
         在一个AUTH命令完整结束后,本次会话就不再有其他的AUTH命令涉及了。
就是说,在一个成功的AUTH命令后,SMTP服务器用503标识的回应来拒绝任何以后的         
AUTH命令。

         在一个邮件传输过程中发出的AUTH命令是不被容许的。

   讨论:
         AUTH命令显示了一种和邮件服务器间的安全认证机制 。如果邮件服务器支持这         
种认证机制,它就会执行一个认证协议交互来认证并识别邮件用户。作为可选的情况,他也
会忽略这以后后协议交互的一个安全层。如果服务器并不支持所需要的认证协议,就会用
504的回答来拒绝这个AUTH命令。

         认证协议交互过程由一系列由认证机制定义的邮件服务器端的命令和邮件客户端         
的响应组成。

         一个邮件服务器端命令,或者所谓一个准备好响应,是一个334起头的,包含用         
base64编码的字符串文本。邮件客户端也同样由包含了用base64编码的字符串。如果邮件
客户端希望可以取消一个进行中的认证交互过程,它会发出一个仅包含一个字符"*"命令行,
邮件服务器端一旦收到这样的一个回答后,必须发一个501标识的回答,而后拒绝AUTH
命令。
         对AUTH命令来说,可选的初始化响应建议是用来在使用认证机制时保持一个往
返的回程,认证机制的定义中此建议不发送任何数据。当初始化响应部分用在这种机制时,
开始的空的发起命令不被送到客户端,并且服务器端使用的数据也好象是发送来         
响应一个空的命令。它发送一个零长度的初始化回答作为一个"="符号。如果客户端         
在认证机制的AUTH命令响应中使用初始化建议,客户端就在初始化命令中发送响应的         
数据,服务器端用535回答来拒绝AUTH命令。

         如果不能对参数用base64解码,就用501回答来拒绝AUTH命令,如果服务器
拒绝认证数据,它应该用535的回答(可以带其他详细的特殊错误代码,比如在第6节所列
的代码中的一个)来拒绝AUTH命令。如果客户端成功完成了认证交互,SMTP服务器就
应该返回一个235的响应。        
         本SASL协议梗概中描述的服务名称是SMTP.

         如果一个安全层通过了SASL认证交换,随着作为终止客户端认证交换的CRLF
(回车换行),这个安全层立即有效。在安全层起作用后,其上的SMTP协议被复位到初试
状态(这个SMTP状态是在服务器发出一个220服务准备好的消息后开始的)。接着服务器
就会放弃所有来自客户端的知识,例如,不是获得自SASL协商本身的EHLO命令的参数。
客户端也会放弃所有来自服务器端的知识,例如,不是获得自SASL协商本身的SMTP扩
展服务(这里假设一个客户端可以比较认证前后的建议的SASL机制的列表,从而检测主动
down-negotiation攻击)。客户端应该发出一个EHLO命令,此命令作为使一个安全层有效的
认证协商成功后的第一个命令。 
         服务器并不被要求一定支持任何特定的认证机制,同样认证机制要不要求必须支
持某种安全层。
         一旦一个AUTH命令失败,客户端可以通过发出另外一个AUTH命令来尝试其
他一种认证机制。
         一旦一个AUTH命令失败,服务器端的行为就好象客户端从没有发出那次AUTH         
命令一样。
         
         base64编码的字符串一般可以有任意长度。客户端和服务器端都应该可以支持         
那些由认证机制产生的合法的任意长的请求和响应字符串,而不依赖于服务器或者客户端
的、可能存在于协议实现的某些方面的行长度的限制。
         
     例如:
         S: 220 SMTP.example.com ESMTP server ready
         C: EHLO jgm.example.com
         S: 250-SMTP.example.com
         S: 250 AUTH CRAM-MD5 DIGEST-MD5
         C: AUTH FOOBAR
         S: 504 Unrecognized AUTHentication type.
         C: AUTH CRAM-MD5
         S: 334
         PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
         C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
         S: 235 Authentication successful.


5. 对应MAIL from 命令的AUTH参数

   AUTH=addr-spec

参数:
       一个包含标志的被提交给传送系统的addr-spec,或者是两个字符组成的序列"<>" ,
表明这个标志是未知的或被验明为不完成的。

       为了遵守附加在eSMTP参数上的限制,addr-spec被编码到一个xtext中,关于xtext       
语法的描述在[eSMTP-dsn]中的第5节中。     

讨论:
       对应MAIL from 命令的可选的AUTH参数容许在一个可以信赖的环境中多代理    
合作来传送个人消息的认证。
       
       如果服务器信任客户端的被验证的标志(这个标志表明这个消息最初是由给定的       
addr-spec提交的),则当需要把消息转发到任何支持AUTH扩展的服务器去的时候,服务器
应该用包含相同的addr-spec参数的AUTH命令来回复。
      
       一个MAIL FORM 参数 AUTH=<>显示最初提交的信息是未知的。服务器端并不把
这个消息作为由客户端的初始提交数据对待。 
       如果MAIL FORM的AUTH参数没有提供,客户端已经被验证,并且服务器端相信
消息
       是原始的客户端的提交,则当需要把消息转发到任何支持AUTH扩展的服务器去的
时候,
       服务器端应该在AUTH参数的中的add-spe里提供客户端标记。
       
       如果服务器端不是充分信任客户端的认证标志,或者客户端没有通过认证,则服务
器端会表现为似乎由一个AUTH=<>参数被提交一样。服务器端也可以把ahth的参数写入到      
一个log文件中去。
       
       如果提交一个AUTH=<>参数,不管是明确提供还是由于在上面段落中的条件隐含
提供,服务器端在转发消息到用AUTH扩展认证的其他任何服务器的时候都必须提供
AUTH=<>的参数。
       
       一个服务器应该把邮件列表扩展作为一个新的子任务来对待,在转发消息到列表订
户的时候,为邮件列表地址或邮件列表管理设置AUTH参数。 
       一个“硬编码”的实现是把所有客户端都当作不完全信任的。这时,这个实现只是
解析并抛弃语法有效的mial from命令的AUTH参数并提供AUTH=<>参数给任何用AUTH
扩展来做认证的服务器。
       
   例如:
       C: MAIL FROM: AUTH=e+3Dmc2@example.com
       S: 250 OK
6. 错误代码
   以下的错误代码可以被用来显示被描述的几种情况。
   
   432 需要一个密码转换
   
   这个对于AUTH命令的响应显示用户需要转换到被选择的认证机制。使用PLAIN认证
机制时会这样做。
   
   534 认证机制过于简单
 
   这个对于AUTH命令的响应显示被选择的认证机制比服务器安全政策所许可此用户的等
级要低。
   
   538 当前请求的认证机制需要加密
   
   这个对于AUTH命令的响应显示当前的认证机制必须在SMTP 连接被加密的情况下才
可以使用。
   
   454 临时认证失败
   
   这个对于AUTH命令的响应显示因为临时服务器出错而导致认证失败
   
   530 需要认证
   
   这个响应可以被任何命令返回(除了 AUTH, EHLO,   HELO, NOOP, RSET, 或 QUIT)。
它表明服务器安全策略要求认证以执行客户端的请求动作。
7. 正式的语法
   下面的语法定义使用了扩展的Backus-Naur Form (BNF)符号,它的详细说明在[abfn]。  
   除了有名的另外的方式,所有的字母表字符都是大小写不敏感的。这里使用大写或小   
写字符来定义关键字符串只是为了编辑上的清晰。具体实现必须把这些字符串做为大小   
写不敏感的方式来接受。
   
   UPALPHA         = %x41-5A            ;; Uppercase: A-Z

   LOALPHA         = %x61-7A            ;; Lowercase: a-z

   ALPHA           = UPALPHA / LOALPHA  ;; case insensitive

   DIGIT           = %x30-39            ;; Digits 0-9

   HEXDIGIT        = %x41-46 / DIGIT    ;; hexidecimal digit (uppercase)

   hexchar         = "+" HEXDIGIT HEXDIGIT

   xchar           = %x21-2A / %x2C-3C / %x3E-7E
                     ;; US-ASCII except for "+", "=", SPACE and CTL

   xtext           = *(xchar / hexchar)

   AUTH_CHAR       = ALPHA / DIGIT / "-" / "_"

   AUTH_type       = 1*20AUTH_CHAR

   AUTH_command    = "AUTH" SPACE AUTH_type [SPACE (base64 / "=")]
                     *(CRLF [base64]) CRLF

   AUTH_param      = "AUTH=" xtext
                       ;; The decoded FORM of the xtext MUST be either
                       ;; an addr-spec or the two characters "<>"

   base64          = base64_terminal /
                     ( 1*(4base64_CHAR) [base64_terminal] )

   base64_char     = UPALPHA / LOALPHA / DIGIT / "+" / "/"
                     ;; Case-sensitive

   base64_terminal = (2base64_char "==") / (3base64_char "=")

   continue_req    = "334" SPACE [base64] CRLF


   CR              = %x0C           ;; ASCII CR, carriage return

   CRLF            = CR LF

   CTL             = %x00-1F / %x7F ;; any ASCII control character and DEL

   LF              = %x0A           ;; ASCII LF, line feed

   SPACE           = %x20           ;; ASCII SP, space




8. References

   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, November 1997.

   [CRAM-MD5]  Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
               AUTHorize Extension for Simple Challenge/Response", RFC
               2195, September 1997.

   [ESMTP]     Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
               Crocker, "SMTP Service Extensions", RFC 1869, November
               1995.

   [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status
               Notifications", RFC 1891, January 1996.

   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [SASL]      Myers, J., "Simple Authentication and Security Layer
               (SASL)", RFC 2222, October 1997.

   [SUBMIT]    Gellens, R. and J. Klensin, "Message Submission", RFC
               2476, December 1998.

   [RFC821]    Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
               821, August 1982.

   [RFC822]    Crocker, D., "Standard for the Format of ARPA Internet
               Text Messages", STD 11, RFC 822, August 1982.



9. 安全上的考虑

   这里探讨有关安全的主题。

   如果客户端使用这种扩展来得到一个通过一个不安全的网络到达与之合作的服务器   
的加密信道,同时连接没有被交互认证和加密,它需要被配置为从没有向这个服务器发送邮
件。否则一个攻击者可以通过截获SMTP连接并假装服务器不能支持认证扩展或让所有
AUTH命令失败的方式偷走用户的邮件。
   
   在SASL协商发生之前,任何协议交互数据都是明文而且可以被一个主动攻击者更改,
因此,客户端和服务器端都应该抛弃在SASL协商开始前的获得的信息。
   
   这种机制不保护tcp端口,所以主动进攻者可以把一个转发连接重定向到委托端口。
AUTH=<>参数防止这种导致转发没有认证消息以恢复转发客户端的认证的攻击。
   
   一个消息托付客户端可以要求用户不管是否被告之一个适当的SASL机制都必须认证。
因此,对一个委托服务器来说,去建议一个SASL机制使不合适的,使用这种机制通过匿名   
委托给客户端不会带来任何的益处。
   
   这种扩展不是为了取代类似s/mime 或 pgp的端到端的消息签名和加密系统。它和端到
端系统要解决的问题不同。有以下主要的区别:
   
      (1) 它一般只在被信任的环境中有效。

      (2) 它保护整个消息的报头部分,而不是邮件消息的主体部分。

      (3) 它对消息委托进行认证,而不是对消息内容的作者的认证。

      (4) 它可以给发送者一定的保证:在发送者交互认证并协商了一个合适的安全层的情          
况下,这个消息确信被传递到了下一跳。

   其他有关安全问题的事项在SASL规范中有论述。


10  作者地址

   John Gardiner Myers
   Netscape Communications
   501 East Middlefield Road
   Mail Stop MV-029
   Mountain View, CA 94043

   EMail: jgmyers@netscape.com


11.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the inFORMation contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Myers                       Standards Track                    [Page 11]



RFC 2554 SMTP Service Extension for Authentication        SMTP服务认证扩展


1
RFC文档中文翻译计划
 相关推荐

刘强东夫妇:“移民美国”传言被驳斥

京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。

发布于:7月以前  |  808次阅读  |  详细内容 »

博主曝三大运营商,将集体采购百万台华为Mate60系列

日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。

发布于:7月以前  |  770次阅读  |  详细内容 »

ASML CEO警告:出口管制不是可行做法,不要“逼迫中国大陆创新”

据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。

发布于:7月以前  |  756次阅读  |  详细内容 »

抖音中长视频App青桃更名抖音精选,字节再发力对抗B站

今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。

发布于:7月以前  |  648次阅读  |  详细内容 »

威马CDO:中国每百户家庭仅17户有车

日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。

发布于:7月以前  |  589次阅读  |  详细内容 »

研究发现维生素 C 等抗氧化剂会刺激癌症生长和转移

近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。

发布于:7月以前  |  449次阅读  |  详细内容 »

苹果据称正引入3D打印技术,用以生产智能手表的钢质底盘

据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。

发布于:7月以前  |  446次阅读  |  详细内容 »

千万级抖音网红秀才账号被封禁

9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...

发布于:7月以前  |  445次阅读  |  详细内容 »

亚马逊股东起诉公司和贝索斯,称其在购买卫星发射服务时忽视了 SpaceX

9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。

发布于:7月以前  |  444次阅读  |  详细内容 »

苹果上线AppsbyApple网站,以推广自家应用程序

据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。

发布于:7月以前  |  442次阅读  |  详细内容 »

特斯拉美国降价引发投资者不满:“这是短期麻醉剂”

特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。

发布于:7月以前  |  441次阅读  |  详细内容 »

光刻机巨头阿斯麦:拿到许可,继续对华出口

据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。

发布于:7月以前  |  437次阅读  |  详细内容 »

马斯克与库克首次隔空合作:为苹果提供卫星服务

近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。

发布于:7月以前  |  430次阅读  |  详细内容 »

𝕏(推特)调整隐私政策,可拿用户发布的信息训练 AI 模型

据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。

发布于:7月以前  |  428次阅读  |  详细内容 »

荣耀CEO谈华为手机回归:替老同事们高兴,对行业也是好事

9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。

发布于:7月以前  |  423次阅读  |  详细内容 »

AI操控无人机能力超越人类冠军

《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。

发布于:7月以前  |  423次阅读  |  详细内容 »

AI生成的蘑菇科普书存在可致命错误

近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。

发布于:7月以前  |  420次阅读  |  详细内容 »

社交媒体平台𝕏计划收集用户生物识别数据与工作教育经历

社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”

发布于:7月以前  |  411次阅读  |  详细内容 »

国产扫地机器人热销欧洲,国产割草机器人抢占欧洲草坪

2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。

发布于:7月以前  |  406次阅读  |  详细内容 »

罗永浩吐槽iPhone15和14不会有区别,除了序列号变了

罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。

发布于:7月以前  |  398次阅读  |  详细内容 »