云南龙网

  1. 首页 > 云知道 > >

简单查问/应答的IMAP/POP授权扩展

云知道

【简单查问/应答的IMAP/POP授权扩展】本备忘录的状态
本文档讲述了一种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不支持保护机制 。
例子：

推荐阅读


上一篇：饮水机的用法

下一篇：社保卡丢失怎么看病