分享
 
 
 

SMTP服务认证扩展

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

1.简介

本文档定义扩展邮件服务,一个SMTP(简单邮件传输协议)的客户端和服务器之间可以存

在一种认证机制,执行认证协议的交互,并为以后的邮件协议交互进行安全层次的协商。这

个扩展是SASL(简单认证与安全层)的一个方面。

2.本文档中的约定

在示例中,“c:”和“s:”分别代表了客户端和服务器端发送的数据行。

本文中,要害词MUST","MUSTNOT","SHOULD","SHOULDNOT","MAY"和"Key

WordsforuseinRFCstoIndicateRequirementLevels"中的定义一致。

3.验证服务扩展

(1)这种SMTP扩展服务的名称是“认证”。

(2)和本扩展服务关联的EHLO要害字的值是“AUTH”

(3)AUTHEHLO要害字是一个有空格间隔的被SASL机制支持的名字列表的参数。

(4)定义了一个新的SMTP协议的命令词AUTH。

(5)要害词AUTH被用做一个可选的参数被加入MAILFORM命令中并把MAILFROM

命令行的的最大长度扩展到500个ansi字符。

(6)此扩展和委托协议兼容(thesubmissionprotocol[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:220SMTP.example.comESMTPserverready

C:EHLOjgm.example.com

S:250-SMTP.example.com

S:250AUTHCRAM-MD5DIGEST-MD5

C:AUTHFoobar

S:504UnrecognizedAUTHenticationtype.

C:AUTHCRAM-MD5

S:334

PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvBT4=

C:ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==

S:235AuthenticationsUCcessful.

5.对应MAILfrom命令的AUTH参数

AUTH=addr-spec

参数:

一个包含标志的被提交给传送系统的addr-spec,或者是两个字符组成的序列"<>",

表明这个标志是未知的或被验明为不完成的。

为了遵守附加在eSMTP参数上的限制,addr-spec被编码到一个xtext中,关于xtext

语法的描述在[eSMTP-dsn]中的第5节中。

讨论:

对应MAILfrom命令的可选的AUTH参数容许在一个可以信赖的环境中多代理

合作来传送个人消息的认证。

假如服务器信任客户端的被验证的标志(这个标志表明这个消息最初是由给定的

addr-spec提交的),则当需要把消息转发到任何支持AUTH扩展的服务器去的时候,服务器

应该用包含相同的addr-spec参数的AUTH命令往返复。

一个MAILFORM参数AUTH=<>显示最初提交的信息是未知的。服务器端并不把

这个消息作为由客户端的初始提交数据对待。

假如MAILFORM的AUTH参数没有提供,客户端已经被验证,并且服务器端相信

消息

是原始的客户端的提交,则当需要把消息转发到任何支持AUTH扩展的服务器去的

时候,

服务器端应该在AUTH参数的中的add-spe里提供客户端标记。

假如服务器端不是充分信任客户端的认证标志,或者客户端没有通过认证,则服务

器端会表现为似乎由一个AUTH=<>参数被提交一样。服务器端也可以把ahth的参数写入到

一个log文件中去。

假如提交一个AUTH=<>参数,不管是明确提供还是由于在上面段落中的条件隐含

提供,服务器端在转发消息到用AUTH扩展认证的其他任何服务器的时候都必须提供

AUTH=<>的参数。

一个服务器应该把邮件列表扩展作为一个新的子任务来对待,在转发消息到列表订

户的时候,为邮件列表地址或邮件列表治理设置AUTH参数。

一个“硬编码”的实现是把所有客户端都当作不完全信任的。这时,这个实现只是

解析并抛弃语法有效的mialfrom命令的AUTH参数并提供AUTH=<>参数给任何用AUTH

扩展来做认证的服务器。

例如:

C:MAILFROM:<e=mc2@example.com>AUTH=e+3Dmc2@example.com

S:250OK

6.错误代码

以下的错误代码可以被用来显示被描述的几种情况。

432需要一个密码转换

这个对于AUTH命令的响应显示用户需要转换到被选择的认证机制。使用PLAIN认证

机制时会这样做。

534认证机制过于简单

这个对于AUTH命令的响应显示被选择的认证机制比服务器安全政策所许可此用户的等

级要低。

538当前请求的认证机制需要加密

这个对于AUTH命令的响应显示当前的认证机制必须在SMTP连接被加密的情况下才

可以使用。

454临时认证失败

这个对于AUTH命令的响应显示因为临时服务器出错而导致认证失败

530需要认证

这个响应可以被任何命令返回(除了AUTH,EHLO,HELO,NOOP,RSET,或QUIT)。

它表明服务器安全策略要求认证以执行客户端的请求动作。

7.正式的语法

下面的语法定义使用了扩展的Backus-NaurForm(BNF)符号,它的具体说明在[abfn]。

除了有名的另外的方式,所有的字母表字符都是大小写不敏感的。这里使用大写或小

写字符来定义要害字符串只是为了编辑上的清楚。具体实现必须把这些字符串做为大小

写不敏感的方式来接受。

UPALPHA=%x41-5A;;Uppercase:A-Z

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

ALPHA=UPALPHA/LOALPHA;;caseinsensitive

DIGIT=%x30-39;;Digits0-9

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

hexchar="+"HEXDIGITHEXDIGIT

xchar=%x21-2A/%x2C-3C/%x3E-7E

;;US-ASCIIexceptfor"+","=",SPACEandCTL

xtext=*(xchar/hexchar)

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

AUTH_type=1*20AUTH_CHAR

AUTH_command="AUTH"SPACEAUTH_type[SPACE(base64/"=")]

*(CRLF[base64])CRLF

AUTH_param="AUTH="xtext

;;ThedecodedFORMofthextextMUSTbeeither

;;anaddr-specorthetwocharacters"<>"

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;;ASCIICR,carriagereturn

CRLF=CRLF

CTL=%x00-1F/%x7F;;anyASCIIcontrolcharacterandDEL

LF=%x0A;;ASCIILF,linefeed

SPACE=%x20;;ASCIISP,space

8.References

[ABNF]Crocker,D.andP.Overell,"AugmentedBNFforSyntax

Specifications:ABNF",RFC2234,November1997.

[CRAM-MD5]Klensin,J.,Catoe,R.andP.Krumviede,"IMAP/POP

AUTHorizeExtensionforSimpleChallenge/Response",RFC

2195,September1997.

[ESMTP]Klensin,J.,Freed,N.,Rose,M.,Stefferud,E.andD.

Crocker,"SMTPServiceExtensions",RFC1869,November

1995.

[ESMTP-DSN]Moore,K,"SMTPServiceExtensionforDeliveryStatus

Notifications",RFC1891,January1996.

[KEYWORDS]Bradner,S.,"KeywordsforuseinRFCstoIndicate

RequirementLevels",BCP14,RFC2119,March1997.

[SASL]Myers,J.,"SimpleAuthenticationandSecurityLayer

(SASL)",RFC2222,October1997.

[SUBMIT]Gellens,R.andJ.Klensin,"MessageSubmission",RFC

2476,December1998.

[RFC821]Postel,J.,"SimpleMailTransferProtocol",STD10,RFC

821,August1982.

[RFC822]Crocker,D.,"StandardfortheFormatofARPAInternet

TextMessages",STD11,RFC822,August1982.

9.安全上的考虑

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

假如客户端使用这种扩展来得到一个通过一个不安全的网络到达与之合作的服务器

的加密信道,同时连接没有被交互认证和加密,它需要被配置为从没有向这个服务器发送邮

件。否则一个攻击者可以通过截获SMTP连接并假装服务器不能支持认证扩展或让所有

AUTH命令失败的方式偷走用户的邮件。

在SASL协商发生之前,任何协议交互数据都是明文而且可以被一个主动攻击者更改,

因此,客户端和服务器端都应该抛弃在SASL协商开始前的获得的信息。

这种机制不保护tcp端口,所以主动进攻者可以把一个转发连接重定向到委托端口。

AUTH=<>参数防止这种导致转发没有认证消息以恢复转发客户端的认证的攻击。

一个消息托付客户端可以要求用户不管是否被告之一个适当的SASL机制都必须认证。

因此,对一个委托服务器来说,去建议一个SASL机制使不合适的,使用这种机制通过匿名

委托给客户端不会带来任何的益处。

这种扩展不是为了取代类似s/mime或pgp的端到端的消息签名和加密系统。它和端到

端系统要解决的问题不同。有以下主要的区别:

(1)它一般只在被信任的环境中有效。

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

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

(4)它可以给发送者一定的保证:在发送者交互认证并协商了一个合适的安全层的情

况下,这个消息确信被传递到了下一跳。

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

10作者地址

JohnGardinerMyers

NetscapeCommunications

501EastMiddlefieldRoad

MailStopMV-029

MountainView,CA94043

EMail:jgmyers@netscape.com

11.FullCopyrightStatement

Copyright(C)TheInternetSociety(1999).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto

others,andderivativeworksthatcommentonorotherwiseeXPlainit

orassistinitsimplementationmaybeprepared,copied,published

anddistributed,inwholeorinpart,withoutrestrictionofany

kind,providedthattheabovecopyrightnoticeandthisparagraphare

includedonallsuchcopiesandderivativeworks.However,this

documentitselfmaynotbemodifiedinanyway,suchasbyremoving

thecopyrightnoticeorreferencestotheInternetSocietyorother

Internetorganizations,exceptasneededforthepurposeof

developingInternetstandardsinwhichcasetheproceduresfor

copyrightsdefinedintheInternetStandardsprocessmustbe

followed,orasrequiredtotranslateitintolanguagesotherthan

English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe

revokedbytheInternetSocietyoritssuccessorsorassigns.

ThisdocumentandtheinFORMationcontainedhereinisprovidedonan

"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING

TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING

BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION

HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF

MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有