RFC2945 SRP身份验证和键交换系统

1772次阅读  |  发布于5年以前

组织:中国互动出版网(http://www.china-pub.com/) RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm) E-mail:ouyang@china-pub.com 译者:王利明(walimis walimis@163.com) 译文发布时间:2002-6-1 版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。

Network Working Group                                                      T. Wu Request for Comments: 2945                                    Stanford University Category: Standards Track                                         September 2000

SRP鉴别和秘钥交换系统 (The SRP Authentication and Key Exchange System) 本备忘录的状态 本文档讲述了一种Internet社区的Internet标准跟踪协议,它需要进一步进行讨论和建议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度和状态。本备忘录的发布不受任何限制。 版权声明 Copyright (C) The Internet Society (2001). 摘要 本文档描述了一个用密码来加强的网络鉴别机制,即我们所知的安全远程口令(SRP)的协议,这种机制适合于如下情况,即需要用户提供口令来协商安全的连接,同时须消除在传统中因重新使用口令而带来的安全问题。这个系统同时能在鉴别过程中提供一个安全的秘钥交换,并可在会话时使用安全的访问层(秘密性和/或者完整性保护)。它不需要可信的秘钥服务器和证书基础结构,同时客户也不需要储存和管理任何长的秘钥。SRP同时提供了在安全和部署等方面,比现有的查问/应答技术要好的优势。另外,它还是一个,在需要安全口令鉴别的地方可被使用的理想的替代方案。 1.简介 缺乏一个安全的并且易于使用的鉴别机制,对于正在使用的绝大多数的Internet协议来说,是一个长期的固有的问题。问题就在于这两点缺陷:用户喜欢使用他们容易记住的口令,但是大多数基于口令的鉴别系统只提供很少的保护,甚至对于被动攻击者,尤其是如果一个弱的和易于猜测的口令被使用的话。对于使用明显的方式来传输口令的协议,要在一个TCP/IP网络上实施窃听,非常容易和有效。甚至对所谓的“查问/应答”技术,如在[RFC 2095]和[RFC 1760]中描述的被设计用来防范简单的窃听攻击,也可以被著名的“字典攻击”所攻破。这种攻击就是,攻击者在协议合法运行时,捕获交互的消息,并利用这些信息验证从一个预编译好的口令字典中提取的一系列的口令。这之所以有效,就是因为用户经常选择简单的、易于记忆的口令,导致其总是被轻易的猜中。 现存的多数机制都需要主机中的口令数据库保持秘密状态,因为口令P或者某些秘密的散列值h(P)被保存在其中,如果被泄漏的话就会危及安全。这种方法经常退化为“模糊的安全”。这种方法反对在UNIX传统中保存一个“公共”口令文件,这个文件的内容会在不破坏系统安全的情况下被泄漏。 对于一个不能泄漏的鉴别协议来说,SRP满足了严格的,并在[RFC 1704]中被定义的需求。它提供了全面的保护,来防范被动和主动的攻击者,并使用了一个类似于Diffie-Hellman样式的单轮计算来有效的实现,使它对于大多数的Internet协议,都可以在交互或者非交互的鉴别中使用。既然它能在带有低熵的口令的情况下使用的同时,保持其安全性,它就可以被无缝集成在现有的用户应用中。 2.约定和术语 这个文档中所描述的协议,由于一些历史原因,某些时候是指“SRP-3”。这个特定的协议在[SRP]中描述,被认为有非常好的合理性和加密性,能同时抵抗窃听和主动的攻击。  这个文档不会试图在特定的Internet协议的上下文中描述SRP。相反,它只是描述一个抽象的协议,其可以容易的适应于特定的应用。比如,特定的消息格式(包括填充)不会详细说明。这些问题留给协议实现者去决定。 这里,一个需要值得详细说明的有关实现的问题,是关于字符串和整数之间的映射。Internet协议是面向字节的,但是SRP在它的消息中要执行代数操作。因此,要合乎逻辑的话,至少要定义一种方法,它能把整数转换成一个字节串,或者相反。 一个n字节的字符串S可以用如下方法转换成一个整数。    i = S[n-1] + 256  S[n-2] + 256^2  S[n-3] + ... + 256^(n-1)  S[0] 这里i是一个整数,S[x]是S的第x个字节的值。在人们的术语中,由字节组成的字符串是以256为基来表示的整数,并且是最高有效位优先。当转换成为一个字符串时,S[0]必须是一个非零值(填充考虑作为一个分离的,独立的过程)。这种转换方法适合于文件存储、内存内部表示和大整数值的网络传输中。除非另外的说明,就将假设为这种映射。 如果实现需要填充一个代表整数值的字符串,建议用值为零的字节加到字符串的开头。反过来,将其转换为整数将自动丢弃前导为零的字节,这种填充模式倾向于产生更少的错误。 在这个文档中使用的SHA散列函数,指的是在[SHA1]中描述的SHA-1消息摘要算法 3.SRP-SHA1机制 这一节描述一个SRP鉴别和秘钥交换系统的实现,它使用了SHA散列函数来产生会话密钥和鉴别证明。 主机用三元组的形式保存用户的口令         { , <password verifier>,  } 口令实体由如下方法来产生:          = random()         x = SHA( | SHA( | ":" | <raw password>))         <password verifier> = v = g^x % N “|”符号代表字符串连接,^操作符代表求幂运算,%操作符代表整数求余运算。大多数的实现在一个单独的阶段执行求幂和求余运算,以避免产生难以处理的中间结果。注意,SHA的160位的输出在被操作前要被明确转换成一个整数。 鉴别通常由客户端发起。       Client                             Host      --------                           ------       U =               -->                                      <--    s = <salt from passwd file> 在给主机鉴定它自身的时候,客户会收到保存在主机中,并且在它的用户名下的salt。       a = random()       A = g^a % N                 -->                                          v = <stored password verifier>                                          b = random()                                   <--    B = (v + g^b) % N       p = <raw password>       x = SHA(s | SHA(U | ":" | p))       S = (B - g^x) ^ (a + u  x) % N    S = (A * v^u) ^ b % N       K = SHA_Interleave(S)              K = SHA_Interleave(S)       (这个函数会在下节中描述) 客户端产生一个随机数,生成以g为底的幂,再以一个素数为模取余,把结果发送给主机。主机做同样的事情,但要加上公共验证符,然后发给客户端。这样,两端就共享了基于各自因子的会话密钥。 参数u是一个32位的无符号整数,它的值来自于B的SHA1散列的第一个32位,这里最高有效位优先。 如果B % N结果为零,客户端必须中断鉴别过程。 如果B % N结果为零,主机必须中断鉴别企图。主机必须在从客户端收到A之后,发送B,千万不要在这之前。 在这一点上,客户端和服务器端将有一个安全的公用会话密钥(比如不会被外界的一方知道)。为了完成鉴别,他们必须互相证明他们的密钥是同样的。         M = H(H(N) XOR H(g) | H(U) | s | A | B | K)                                     -->                                     <--    H(A | M | K) 服务器端用它自己的K计算M并且和客户端的回应进行比较。如果它们不匹配,在它尝试回答客户端的查问前,服务器必须中断并发出一个错误信号。这样任何事情都不会危及用户密码的安全性。 如果服务器收到正确的响应,它就发出自己的证明给客户端。客户端用它自己的K计算预期的响应,来验证服务器的真实性。如果客户端响应正确,服务器必须用它自己的散列值作为响应。 在这个协议的描述中,处理过程不必和实际的协议消息一对一的对应。这里的描述仅仅是为了阐明不同参数的关系和它们如何计算。比如,有可能一个SRP-SHA1机制的实现,可以加固某些流程,如下所示:         Client                             Host        --------                           ------         U, A                        -->                                     <--    s, B         H(H(N) XOR H(g) | H(U) | s | A | B | K)                                     -->                                     <--    H(A | M | K) 在这个协议的使用中,N和g的值必须由双方讨论来达成一致。它们可以被提前设置好,或者主机把它们发送给客户端。在后一种方式中,主机将在第一个消息中连带salt把参数发送出去。为了最大化安全性,N可以是一个安全的素数(也就是,一个类似于N=2q + 1形式的数,同时q是个素数)。而且,g将是一个以N为模的生成元,意味着,对任何X,有0 < X < N,存在一个值x,使得g^x % N == X。 3.1交叉存取的SHA 在SRP-SHA1中使用的SHA_Interleave函数,用来产生一个会话密钥,它的长度是SHA1的160位的输出的两倍长。为了执行这个函数,需要移去输入值的前导是零的字节。如果字符串的结果长度是奇数,也要移去第一个字节。我们称结果的字符串为T。提取T的偶数位的字节到字符串E,奇数位的字节到F,即:      E = T[0] | T[2] | T[4] | ...      F = T[1] | T[3] | T[5] | ... E和F都严格为T的长度的一半。用标准的SHA1对它们分别散列,即:      G = SHA(E)      H = SHA(F) 两个散列交叉连接在一起,组成输出,即:      result = G[0] | H[0] | G[1] | H[1] | ... | G[19] | H[19] 结果将有40字节(320位)长。 3.2其它的散列算法 SRP可以不使用SHA而使用其它的散列函数。如果散列函数产生输出的长度不同于SHA(20字节),它可能改变协议中的某些消息的长度,但是基本的操作将不受影响。 早期版本的SRP机制使用MD5散列函数,其在[RFC 1321]中描述。键入式散列变换也可以在SRP中使用。一种可能的结构是使用HMAC [RFC 2104],即用K去键入散列的每个方向,而不是使K和其它的参数连接起来。 任何同SRP使用的散列函数应该至少产生16字节的输出,并且应具有这样的属性,即输入的微小变化会引起输出的重大的非线性的改变。[SRP]进一步的讨论了这个问题。 4.安全事宜 整个备忘录就讨论了一个鉴别和密钥交换系统,它用来在不可靠的网络中保护口令和交换密钥。这个系统,通过消除了在网络上发送明文口令的需要,并且通过安全的密钥交换机制来使用加密,改进了安全性。 a和b的密值大约和在Diffie-Hellman 交换中的密值相一致,并且在长度和熵上有着相似的约束。实现上可以选择增加参数u的长度,只要客户端和服务器达成一致就行,但并不建议使用短于32位的参数。 SRP被设计用来,不仅可以抵抗偶然的密码窃听,也可以防范顽固的攻击者,通过捕获网络的数据流,并使用一个口令字典来猜测口令。SRP协议本身也能抵抗主动的网络攻击,并且实现中,可以使用安全的交换密钥来保护会话被劫取,同时提供机密性。 SRP也增加了如下的优势,即允许主机,用一种对攻击者来说并不直接有用的形式,来保存口令。甚至于如果主机的口令数据库被公之于众,攻击者仍然需要一个庞大的字典去搜索来获得口令。在这种情况下,要验证一次猜测,所需要的指数级的计算,比现在大多数UNIX系统使用的散列函数,要耗费更多的时间。尽管如此,建议主机仍然应该尽力来保持它们的口令文件的安全性。 5.参考 [RFC 1321]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC 1704]Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994. [RFC 1760]Haller, N., "The S/Key One-Time Password System", RFC 1760, Feburary 1995. [RFC 2095]Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2095, January 1997. [RFC 2104]Krawczyk, H., Bellare, M. and  R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [SHA1]National Institute of Standards and Technology (NIST), "Announcing the Secure Hash Standard", FIPS 180-1, U.S. Department of Commerce, April 1995. [SRP]T. Wu, "The Secure Remote Password Protocol", In Proceedings of the 1998 Internet Society Symposium on Network and Distributed Systems Security, San Diego, CA, pp. 97-111. 6.作者的联系地址 Thomas Wu Stanford University Stanford, CA 94305 EMail: tjw@cs.Stanford.EDU 7.版权声明 Copyright (C) The Internet Society (2000)。版权所有。 本文档及其译文可以拷贝和提供给他人,且其衍生物,如评论、解释或帮助实施的作品可以全部或部分地定制、拷贝、出版和发布,对此我们不加任何限制,前提是上述版权声明,及本段内容包含在所有的拷贝和派生作品中。然而,本文档本身不允许以任何方式修改,例如删除Internet社团或其他Internet组织的版权声明或参考,除非是为了开发Internet标准的需要。即便在这种情况下,也需要添加Internet标准中定义的版权声明,或者根据需要把他翻译成英语以外的其他语言。 上述准许的有限许可是永久性的, 无论是Internet社团以及其继承者或代理者都将不会废止这些许可。 本文档及其中包含的信息基于“AS IS”提供,而且INTERNET社团和IETF拒绝所有授权、表达或影射,包括但不限于任何这里使用的消息的授权将不会违背任何版权或者隐含的商业性授权或对特定的合理目的。 致谢 目前,RFC编者活动的基金由Internet社团提供。 RFC2945――The SRP Authentication and Key Exchange System  SRP鉴别和秘钥交换系统

RFC文档中文翻译计划

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8