rfc 2554 SMTP服務認證擴展

組織：中國互動出版網（）
RFC文檔中文翻譯計劃（）
E-mail：ouyang@china-pub.com
譯者：高鵬（g622   g622@xanet.edu.cn）
譯文發布時間：2001-5-11
版權：本中文翻譯文檔版權歸中國互動出版網所有?？梢杂糜诜巧虡I用途自由轉載，但必須
保留本文檔的翻譯及版權信息。  



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攻擊）?？蛻舳藨摪l出一個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 suclearcase/" target="_blank" >ccessful.


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:<e=mc2@example.com> 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.

原文轉自：http://www.kjueaiud.com