本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建議以得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準化程度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright(C)TheInternetSociety(2001)。
摘要
雖然在RFC1731中描述說，IMAP4支持大量的鑒別機制，但是，它缺乏任何機制，使得不用傳遞明文，從而避免讓密碼也通過網絡，同時也缺乏一個重要的安全架構或者郵件服務器對于每次郵件存取都要更新一個郵件系統級的用戶認證文件。這個規范提供了一個簡單的適合于IMAP4的查問/應答協議。因為它使用了鍵入md5摘要算法，并不需要任何秘密信息顯式的存儲在服務器端，它同樣適合POP3中的APOP方面的改進，這在RFC1734有具體說明。
1.介紹
在已被提議的標準中，已經為IMAP4[IMAP,IMAP-AUTH]協議具體說明了一個鑒別機制，同時為POP3協議[POP3-AUTH]說明了一個類似的鑒別機制。本文這個鑒別機制只是用來擴展的；在[IMAP-AUTH]中說明的四個方法非常強大，但需要一些安全架構支持。基本的POP3規范[POP3]同樣包含一個輕型的查問/應答機制叫做APOP。APOP由于使用這種協議隨之也帶來了危險：通常，它需要客戶端和服務器端存取共享的，以明文方式存在的機密信息。CRAM提供了一個方法來避免保存明文，在保留APOP算法簡單的情況下，僅僅使用鍵入方法的MD5就能實現。
目前為止，IMAP[IMAP]缺乏任何同APOP相對應的機制。在[IMAP-AUTH]中唯一可認為是加強機制的，大概是提供了明文方式的用戶名和口令，這通過在[IMAP]的LOGIN命令來支持。這個文檔描述了一個簡單的查問/應答機制，類似于APOP和PPPCHAP[PPP]，這個機制可以用在IMAP中（原則上，也可以用在POP3中）。
這種機制也有一些其它方法不具備的優點，即不需要服務器端在每次登陸時維護關于email的“logins”信息。雖然這種機制，不需要維護每次登錄的歷史紀錄，會提供加強的安全性，但像IMAP的這種協議，在客戶端和服務器端之間已有一些連接，并且在同時打開的情況下，會使它們在實現上具有顯著的難度。
2.查問/應答鑒別機制Challenge-ResponseAuthenticationMechanism(CRAM)
這個和CRAM有關的鑒別類型是“CRAM-MD5”。
在第一個應答中被編碼的數據，包含一個任意的并由隨機數字組成的字符串，一個時間戳，和這個服務器的完全主機名稱組成。不被編碼形式的語法必須符合一個RFC822的'msg-id'[RFC822]，這在[POP3]有描述。
客戶端處理數據，然后響應一個包含用戶名的字符串，一個空格，和一個“數字”。后者通過應用在[KEYED-MD5]中的鍵入MD5算法來計算，這里，鍵值是一個共享的秘文，摘要文本是一個時間戳（包括尖括號）。
這個共享的秘文是一個只有客戶端和服務器端知道的字符串。這個“數字”參數本身是個16字節的值，以十六進制的形式發送，用小寫的ASCII碼。
當服務器收到客戶端的響應，它驗證所提供的摘要。假如摘要正確，服務器將考慮客戶端已被認證，并正確的響應。
之所以為這個應用選鍵入MD5，是因為它對于短消息認證能有更好的安全性。此外，在[KEYED-MD5]中描述說，使用這個技術進行預計算的中間結果，可以避免共享的秘文在服務器端以顯式的明文保存，這通過保存我們稱之為“上下文”的中間結果來實現。
CRAM不支持保護機制。
例子：
這個文檔的例子顯示通過IMAP4AUTHENTICATE命令來使用CRAM機制。查問和應答的base64編碼是IMAP4AUTHENTICATE命令的一部分，不是CRAM規范本身的一部分。
S:*OKIMAP4Server
C:A0001AUTHENTICATECRAM-MD5
S:+PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UUCmVzdG9uLm1jaS5uZXQ+
C:dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
S:A0001OKCRAMauthenticationsuccessful
在這個例子中，共享的秘文是字符串“tanstaaftanstaaf”，因此，鍵入的MD5摘要通過計算產生：
MD5((tanstaaftanstaafXORopad),
MD5((tanstaaftanstaafXORipad),
<1896.697170952@postOffice.reston.mci.net>))
這里ipad和opad在鍵入MD5的工作過程中定義[KEYED-MD5]，在響應中顯示的字符串是<1896.697170952@postoffice.reston.mci.net>的base64編碼。共享的秘文用null填充到64字節長度。假如共享的秘文長于64字節，共享秘文的MD5摘要以16字節輸入到鍵入MD5進行計算。
這產生一個摘要值（以十六進制形式）
b913a602c7eda7a495b4e6e7334d3890
用戶名加到它的前頭，形成
timb913a602c7eda7a495b4e6e7334d3890
base64編碼滿足了IMAP4AUTHENTICATE命令（或者類似POP3AUTH命令）的需求，產生如下
dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
3.參考
[CHAP]Lloyd，B.和W.Simpson，“PPPAuthenticationPRotocols”，RFC1334，October1992。
[IMAP]Crispin，M.，“InternetMessageaccessProtocol-Version4rev1”，RFC2060，UniversityofWashington，December1996。
[IMAP-AUTH]Myers，J.，“IMAP4AuthenticationMechanisms”，RFC1731，CarnegieMellon，December1994。
[KEYED-MD5]Krawczyk，H.，“HMAC-MD5：Keyed-MD5forMessageAuthentication”，WorkinProgess。
[MD5]Rivest，R.，“TheMD5MessageDigestAlgorithm”，RFC1321，MITLaboratoryforComputerScience，April1992。
[POP3]Myers，J.和M.Rose，“PostOfficeProtocol-Version3”，STD53，RFC1939，CarnegieMellon，May1996。
[POP3-AUTH]Myers，J.，“POP3AUTHenticationcommand”，RFC1734，CarnegieMellon，December，1994。
4.安全事宜
可以說CRAM認證機制的使用，提供了在一個會話中，對鑒別和響應的保護。從而，一個同時實現了明文口令的命令和這種認證類型的服務器，不會答應對一個給定用戶，同時進行這兩種方法的訪問。
雖然在服務器上，保存“上下文”（看第二節）要比以明文方式保存的共享秘文要好，這一點在CHAP[CHAP]和APOP[POP3]是必需的，但假如服務器本身不安全的話，這仍然不足以保護秘密信息。從而，保存著秘密信息或者上下文的服務器，必須在用戶的郵箱和標識符中，同時提供相同水平的保護力度。
隨著共享秘文長度的增加，連帶的復雜性也會增加。
雖然在一些文獻中建議說，MD5和鍵入MD5在認證過程中可能有受限的有效壽命，這個技術現在還是被廣泛的使用和認可。據認為，這種廣泛的認可，有助于通過使用CRAM-MD5，使得對于在IMAP中使用持久的明文口令，進行快速的替換。當考慮這些已被普遍的接受和具有足夠的安全性時，這個文檔故意答應簡單更新到使用SHA（或者任何可替代的）。
盡管使用了CRAM，用戶仍然易受到主動攻擊。常見的主動攻擊的例子是“TCPsessionHijacking”，這在CERTAdvisoryCA-95:01[CERT95]有描述。
小節1有更多的討論
5.致謝
這個備忘錄從[POP3]和[RFC-1731]中借鑒大量的想法和一些文字，應該感謝這些文檔的作者們。RanAtkinson為這個文檔做了大量有價值的技術和編輯方面的貢獻。
6．作者的聯系地址
JohnC.Klensin
MCITelecommunications
800BoylstonSt,7thfloor
Boston,MA02199
USA
EMail:klensin@mci.net
Phone:+16179601011

RandyCatoe
MCITelecommunications
2100RestonParkway
Reston,VA22091
USA
EMail:randy@mci.net
Phone:+17037157366

PaulKrumviede
MCITelecommunications
2100RestonParkway
Reston,VA22091
USA
EMail:paul@mci.net
Phone:+17037157251