📄 rfc4590.txt
字号:
A->B GET /index.html HTTP/1.1 Authorization: Digest algorithm=MD5,nonce="a3086ac8" ,realm="example.com" ,response="f052b68058b2987aba493857ae1ab002" ,uri="/index.html",username="12345678" ,qop=auth,algorithm=MD5 B->C Code = 1 (Access-Request) Attributes: NAS-IP-Address = c0 0 2 26 (192.0.2.38) NAS-Port-Type = 5 (Virtual) User-Name = 12345678 Digest-Response = f052b68058b2987aba493857ae1ab002 Digest-Realm = example.com Digest-Nonce = a3086ac8 Digest-Method = GET Digest-URI = /index.html Digest-Username = 12345678 Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = 06 e1 65 23 57 94 e6 de 87 5a e8 ce a2 7d 43 6b C->B Code = 2 (Access-Accept) Attributes: Digest-Response-Auth = e644aa513effbfe1caff67103ff6433c Message-Authenticator = 7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7 B->A HTTP/1.1 200 OK ... <html> ...Sterman, et al. Standards Track [Page 26] RFC 4590 RADIUS Digest Authentication July 20067. IANA Considerations This document serves as an IANA registration request for a number of values from the RADIUS attribute type number space. The IANA has assigned the following: +-------------------------+------------------------+ | placeholder | value assigned by IANA | +-------------------------+------------------------+ | Digest-Response | 103 | | Digest-Realm | 104 | | Digest-Nonce | 105 | | Digest-Nextnonce | 106 | | Digest-Response-Auth | 107 | | Digest-Method | 108 | | Digest-URI | 109 | | Digest-Qop | 110 | | Digest-Algorithm | 111 | | Digest-Entity-Body-Hash | 112 | | Digest-CNonce | 113 | | Digest-Nonce-Count | 114 | | Digest-Username | 115 | | Digest-Opaque | 116 | | Digest-Auth-Param | 117 | | Digest-AKA-Auts | 118 | | Digest-Domain | 119 | | Digest-Stale | 120 | | Digest-HA1 | 121 | | SIP-AOR | 122 | +-------------------------+------------------------+ Table 28. Security Considerations The RADIUS extensions described in this document enable RADIUS to transport the data that is required to perform a digest calculation. As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see [RFC2617], section 4) in addition to RADIUS security vulnerabilities described in [RFC2865], section 8, and [RFC3579], section 4. An attacker compromising a RADIUS client or proxy can carry out man-in-the-middle attacks even if the paths between A, B and B, C (Figure 2) have been secured with TLS or IPsec. The RADIUS server MUST check the Digest-Realm attribute it has received from a client. If the RADIUS client is not authorized to serve HTTP-style clients of that realm, it might be compromised.Sterman, et al. Standards Track [Page 27] RFC 4590 RADIUS Digest Authentication July 20068.1. Denial of Service RADIUS clients implementing the extension described in this document may authenticate HTTP-style requests received over the Internet. As compared with the use of RADIUS to authenticate link-layer network access, attackers may find it easier to cover their tracks in such a scenario. An attacker can attempt a denial-of-service attack on one or more RADIUS servers by sending a large number of HTTP-style requests. To make simple denial-of-service attacks more difficult, the RADIUS server MUST check whether it has generated the nonce received from an HTTP-style client. This SHOULD be done statelessly. For example, a nonce could consist of a cryptographically random part and some kind of signature provided by the RADIUS client, as described in [RFC2617], section 3.2.1.8.2. Confidentiality and Data Integrity The attributes described in this document are sent in cleartext. RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm attributes in Access-Challenge messages. A man in the middle can modify or remove those attributes in a bidding down attack, causing the RADIUS client to use a weaker authentication scheme than intended. The Message-Authenticator attribute, described in [RFC3579], section 3.2 MUST be included in Access-Request, Access-Challenge, Access-Reject, and Access-Accept messages that contain attributes described in this specification. The Digest-HA1 attribute contains no random components if the algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary attacks easier and enables replay attacks. Some parameter combinations require the protection of RADIUS packets against eavesdropping and tampering. Implementations SHOULD try to determine automatically whether IPsec is configured to protect traffic between the RADIUS client and the RADIUS server. If this is not possible, the implementation checks a configuration parameter telling it whether IPsec will protect RADIUS traffic. The default value of this configuration parameter tells the implementation that RADIUS packets will not be protected. HTTP-style clients can use TLS with server side certificates together with HTTP-Digest Authentication. Instead of TLS, IPsec can be used, too. TLS or IPsec secure the connection while Digest Authentication authenticates the user. The RADIUS transaction can be regarded asSterman, et al. Standards Track [Page 28] RFC 4590 RADIUS Digest Authentication July 2006 one leg on the path between the HTTP-style client and the HTTP-style server. To prevent RADIUS from representing the weak link, a RADIUS client receiving an HTTP-style request via TLS or IPsec could use an equally secure connection to the RADIUS server. There are several ways to achieve this, for example: o The RADIUS client may reject HTTP-style requests received over TLS or IPsec. o The RADIUS client may require that traffic be sent and received over IPsec. RADIUS over IPsec, if used, MUST conform to the requirements described in [RFC3579], section 4.2.9. Acknowledgements We would like to acknowledge Kevin McDermott (Cisco Systems) for providing comments and experimental implementation. Many thanks to all reviewers, especially to Miguel Garcia, Jari Arkko, Avi Lior, and Jun Wang.10. References10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.Sterman, et al. Standards Track [Page 29] RFC 4590 RADIUS Digest Authentication July 2006 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.10.2. Informative References [SIP-APP] Garcia-Martin, M., "Diameter Session Initiation Protocol (SIP) Application", Work in Progress), April 2006. [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.Sterman, et al. Standards Track [Page 30] RFC 4590 RADIUS Digest Authentication July 2006Authors' Addresses Baruch Sterman Kayote Networks P.O. Box 1373 Efrat 90435 Israel EMail: baruch@kayote.com Daniel Sadolevsky SecureOL, Inc. Jerusalem Technology Park P.O. Box 16120 Jerusalem 91160 Israel EMail: dscreat@dscreat.com David Schwartz Kayote Networks P.O. Box 1373 Efrat 90435 Israel EMail: david@kayote.com David Williams Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park NC 27709 USA EMail: dwilli@cisco.com Wolfgang Beck Deutsche Telekom AG Deutsche Telekom Allee 7 Darmstadt 64295 Germany EMail: beckw@t-systems.comSterman, et al. Standards Track [Page 31] RFC 4590 RADIUS Digest Authentication July 2006Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTI⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -