电子邮件传输协议鉴权机制

上传人:hs****ma 文档编号:497005440 上传时间:2022-09-12 格式:DOCX 页数:4 大小:15.74KB
返回 下载 相关 举报
电子邮件传输协议鉴权机制_第1页
第1页 / 共4页
电子邮件传输协议鉴权机制_第2页
第2页 / 共4页
电子邮件传输协议鉴权机制_第3页
第3页 / 共4页
电子邮件传输协议鉴权机制_第4页
第4页 / 共4页
亲,该文档总共4页,全部预览完了,如果喜欢就下载吧!
资源描述

《电子邮件传输协议鉴权机制》由会员分享,可在线阅读,更多相关《电子邮件传输协议鉴权机制(4页珍藏版)》请在金锄头文库上搜索。

1、邮件传输协议鉴权(SMTP Authentication)SMTP鉴权设计是由netscape公司的J. Meyers于1999年提出的,并最终发布到 RFC2554(SMTP Service Extension for Authentication),其中一部分是基于 RFC 1869 规范中的 SMTP Service Extensions。大多数现有的SMTP实现都支持SMTP鉴权,尽管Qmail 1.03不支 持(没有补丁),另一方面多数带有SMTP客户端功能的邮件用户代理(Mail User Agents or MUA) 都具备鉴权功能。SMTP Authentication是由鉴权

2、服务器发起通知,SMTP Authentication要求客户端被鉴权, 且双方最终必须互相接受对方访问,且支持可选的鉴权流程。由于原始的SMTP协议设计初 衷是主机对主机协议,SMTP Authentication机制下,用户必须标示自己并且在成功鉴权后给 邮件收发方授权。除了用于子协议交互的可选安全层被提及外,RFC 2554没有明确说明对于一个用户而言 鉴权有什么好处,SMTP鉴权采用一种简单的鉴权和安全协议层概念,但并没有加入到SMTP规范中,在本文 中将简述该鉴权机制。需求说明(Request for Comments):*RFC 1869为SMTP协议对话定义了扩展协议(ESMTP

3、),用户说明被SMTP服务器扩展的能 力同时或者由客户端传递额外的协议信息。支持ESMTP的smtp服务器必须在SMTP问候对 话信息中使用关键字EHLO,客户端可能仅仅使用服务器提供的这种扩展功能,通过构造对话 消息,在一个SMTP对话中,服务器可以发送扩展信息(其作为ESMTP对话协议中的谓词(译 者:是协议双方识别的关键字)或者作为MAIL FROM: or RCPT TO:命令的一部分),一个典 型的用法是MAIL FROM: SIZE=1512。这个例子中SIZE是一个扩展协 议(ESMTP)关键字,1512是扩展协议(ESMTP)值,而整个术语SIZE=1512是扩展协议参数(RF

4、C 1870规范中,用于声明扩展协议下的消息字节数),在RFC 1869利用两种不同的设计来改 进ESMTP值的使用方式:1, 作为ESMTP动词,使用方式如SIZE xxxxx2, 在命令MAIL FROM: SIZE=1512 中通过“关键字=值”方式*在本文中,RFC 2554描述带有一个扩展协议关键字AUTH的SMTP鉴权,在传递的文本和 RFC 2554 的例子中,ESMTP Auth 提到的值有CRAM-MD5, DIGEST-MD5和 PLAIN每个值对应一个鉴权方法或机制,但是却没有提供任何这方面的参考。* 在 rfc 2222Simple Authentication and

5、 Security Layer (SASL)中几乎找不到以上描述的 ESMTP AUTH鉴权机制。在本文中(also published by John Myers)只概括了 SASL机制,和如何 注册一个新的SASL机制名称,但SASL的机制KERBEROS_V4, GSSAPI, and SKEY是定义了的。* 为保证成功,必须深入分析 RFC 1731 IMAP4 Authentication Mechanisms和 RFC 2195 IMAP/POP Authorize Extension for Simple Challenge/Response,这里将个别给出基于 POP3 和 I

6、MAP4协议上的鉴权例子,这些文档均出自于John Myers,RFC 2060 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1(John Myers),说明了 IMAP4 LOGIN命令的用法,但公众 却不知道关于扩展邮件协议(ESMTP)的AUTH LOGIN方法。*基于base64字符编码对ESMTP Auth值进行编码/解码的方法是第一次在RFC 1113文件的Privacy Enhancement for Internet Electronic Mail: Part I - Message Encipherment and Authe

7、ntication Procedures中描述,尽管没有明确声明成BASE64.在文档RFC 2045的section 6.8 中Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,给出了同样的base64字符描述.*如果使用一种额外的挑战/相应鉴权机制(或者叫协商机制),则你必须非常熟悉成为HMAC 的流程,该流程出自于 RFC 2104 文档的HMAC: Keyed-Hashing for Message Authentication部分(一种带key的哈希鉴权算法

8、),并另遵循RFC 1321文档中的The MD5 Message-Digest Algorithm消息摘要算法,HMAC简单的说就是一种加密/解密设计。*直至今日仍没有一种公共的标准,即怎样在邮件的消息头中拓展smtp鉴权信息。不过 在文档RFC3848中有种最小设计以避免SMTP鉴权会话,其中包括一个上次消息头中带有 Received:的 ESMTPA关键字.从已知的情况来看似乎问题很清楚,即SMTP Authentication鉴权机制依赖于拼凑那些广泛 分散在rfc文档中的机制、方法、流程。现在我们必须继续讨论SMTP的鉴权框架并将实现 那些更复杂的事情.鉴权框架服务器通知,我们采用一

9、个RFC 2554中的例子,S:表示SMTP服务器,C:表示客户端S: 220 ESMTP server readyC: EHLO S: 250-S: 250 AUTH CRAM-MD5 DIGEST-MD5C: AUTH FOOBARS: 504 Unrecognized authentication type.C: AUTH CRAM-MD5S: 334PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ=S: 23

10、5 Authentication successful.这里RFC 2554用多各关键字AUTH的值作为ESMTP命令,该方式遵循RFC 1869,我们将分解 分析ESMTP的客户端实现,一个相关是在AUTH关键字和值之间手工增加一个=,如: AUTH=LOGIN。这里有三种鉴权机制被广泛的使用.来自Krzysztof Dabrowski的包qmail-smtp-auth-patch的文 档中,有一个MUAs概览及其AUTH机制提供了如下几种鉴权方式:* AUTH_LOGIN* PLAIN* CRAM-MD5最通用的AUTH LOGIN 机制类似如下:S: 220 ESMTPC: ehlo

11、S: 250-S: 250-PIPELININGS: 250-8BITMIMES: 250-SIZE 255555555S: 250 AUTH LOGIN PLAIN CRAM-MD5C: auth loginS: 334 VXNlcm5hbWU6C: avlsdkfjS: 334 UGFzc3dvcmQ6C: lkajsdfvljS: 535 authentication failed从所有的提供的鉴权机制中,客户端选择了 authlogin,ESMTP server于是发送了一串334 VXNlcm5hbWU6字符,该字符是基于base64编码对字符串Username:编码的,客户端提供一

12、 个base64编码的用户名称给服务器,服务器响应一个带有Password:字符串的消息334 UGFzc3dvcmQ6给客户端。在上面的例子中随机给定的用户名称和密码最后被服务器的鉴权 请求给拒绝了。2)AUTH PLAIN按照IANA的文档,PLAIN鉴权机制定义在RFC 2245的Anonymous SASL Mechanism1部分,而更 好的PLAIN鉴权机制说明可以在文档RFC 2595 Using TLS with IMAP, POP3 and ACAP(第六章) 中找到,内容:该机制由一个从客户到服务器的的消息组成,客户断发送一个鉴权标识(登陆标 识),其后是一个ASICC码N

13、ULL字符,再接一个鉴权标识(用户标识)后代ASICC码NULL字符, 再接明文密码.客户端可以使鉴权标识为空,作为鉴权标记.简而言之,正确的AUTH PLAIN值 的组织形式是:authid/0userid/0passwd,其中/0标示空字节.一些AUTH PLAIN的SMTP扩展鉴权机制没有完全遵循流程,我们如下看到通过Netscape4.8 MUA连接到一个修改过的Qmail 1.03上来执行的PLAIN鉴权流程C: ehlo S: 220-C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3RwYXNzS: 235 ok, go ahead (#2.0.0)C: RCPT

14、TO:在这个例子中,用户名称是test,用户密码是testpass.这里的Netscape客户端立即推送一个 带有随意输入的鉴权标识test的鉴权信息到服务器端,而没有等待服务器告知其SMTP具备 的鉴权机制.3)AUTH CRAM-MD5AUTH PLAIN和LOGIN的鉴权方式都是传送明文的用户名称和密码,但重要信息还是需要更 安全的CRAM-MD5鉴权机制来保证,我们已经提到CRAM-MD5合并了一个挑战/响应机制方 式信息(用于和服务器交换信息)和一个被Digest5加密算法加密过的信息(Digest 5算法用 于加密重要信息),这里用到了一个Markus Stumpf (SpaceN

15、et)发布的一个例子,是一个典型的 ESMTP AUTH CRAM-MD5 鉴权对话,如下:S: 220 ESMTPC: ehlo S: 250-S: 250-PIPELININGS: 250-8BITMIMES: 250-SIZE 0S: 250 AUTH CRAM-MD5C: auth cram-md5S: 334 PDI0NjA5LjEwNDc5MTQwNDZAcG9wbWFpbC5TcGFjZS5OZXQ+与AUTH LOGIN鉴权机制不同,服务器的响应现在是一次性的BASE64编码的挑战机制,这个 挑战信息、PDI0NjA5LjEwNDc5MTQwNDZAcG9wbWFpbC5TcGFjZS5OZXQ+翻译成24609.10479140

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 学术论文 > 其它学术论文

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号