Network Working Group Dan Simon INTERNET-DRAFT Ashwin Palekar Category: Informational Microsoft 16 January 2002 RADIUS Master Session Key Attribute This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies the RADIUS Master-Session-Key attribute, an attribute used to key ciphersuites used with PPP and IEEE 802.11. Simon & Palekar Informational [Page 1] INTERNET-DRAFT RADIUS Key Attribute 16 January 2002 Table of Contents 1. Introduction .......................................... 3 1.1 Requirements language ........................... 3 2. Attributes ............................................ 3 2.1 Master-Session-Key .............................. 3 3. Table of Attributes ................................... 6 4. Security considerations ............................... 6 5. IANA considerations ................................... 7 6. Normative references .................................. 7 7. Informative references ................................ 7 Acknowledgments .............................................. 8 Author's Addresses ........................................... 8 Intellectual Property Statement .............................. 9 Full Copyright Statement ..................................... 9 Simon & Palekar Informational [Page 2] INTERNET-DRAFT RADIUS Key Attribute 16 January 2002 1. Introduction This document specifies the RADIUS Master-Session-Key attribute, an attribute from which keys can be derived for a wide variety of ciphersuites, including those used with PPP [RFC1661] and IEEE 802.11 [IEEE80211]. The Master-Session-Key attribute can be used to key a wide variety of ciphersuites, and is compatible with any EAP method. As a result, it avoids the proliferation of EAP method-specific master session key algorithms, as well as ciphersuite-specific transient session key algorithms. This is accomplished by the adoption of two separate algorithms: [1] An algorithm for the derivation of "master session keys" from the negotiated master secret. The "master session keys" are derived from the master secret derived by the EAP method, but are never directly used by ciphersuites; they are only used in the derivation of transient session keys. These "master session keys" are derived on the client and the backend authentication server. The backend authentication server then transmits the "master session keys" to the NAS. The algorithm by which the master session keys are derived from a master secret is described in section 3.5 of [RFC2716]. [2] An algorithm for the derivation of "transient session keys" from the "master session keys". The "transient session keys" are used for encryption, authentication and IV-generation in each direction, and are derived by the NAS and client, based on the negotiated ciphersuite. Examples of such algorithms are provided in section 4 of [RFC3079]. 1.1. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 2. Attributes 2.1. Master-Session-Key Description This Attribute indicates master session key material used to derive ciphersuite-specific keys. This Attribute MAY only be present in an Access-Accept packet. Simon & Palekar Informational [Page 3] INTERNET-DRAFT RADIUS Key Attribute 16 January 2002 A summary of the Master-Session-Key Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Salt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD for Master-Session-Key Length 224 Salt The Salt field is two octets in length and is used to ensure the uniqueness of the keys used to encrypt each of the encrypted attributes occurring in a given Access-Accept packet. The most significant bit (leftmost) of the Salt field MUST be set (1). The contents of each Salt field in a given Access-Accept packet MUST be unique. String The plaintext String field is 192 octets in length and consists of 6 logical subfields, each of which are 32 octets in length: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAEncKey | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | APEncKey | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAAuthKey | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | APAuthKey | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAIV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | APIV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Simon & Palekar Informational [Page 4] INTERNET-DRAFT RADIUS Key Attribute 16 January 2002 Here PAEncKey is the peer to authenticator encryption key; APEncKey is the authenticator to peer encryption key; PAAuthKey is the peer to authenticator authentication key; APAuthkey is the authenticator to peer authentication key; PAIV is the peer to authenticator initialization vector; and APIV the authenticator to peer initialization vector. Further description is available in section 3.5 of [RFC2716]. The String field MUST be encrypted as follows, prior to transmission: [1] Construct a plaintext version of the String field by concatenating PAEncKey, APEncKey, PAAuthKey, APAuthKey, PAIV and APIV fields. Call this plaintext P. [2] Call the shared secret S, the pseudo-random 128-bit Request Authenticator (from the corresponding Access-Request packet) R, and the contents of the Salt field A. Break P into 16 octet chunks p(1), p(2)...p(i), where i = len(P)/16. Call the ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. Intermediate values b(1), b(2)...c(i) are required. Encryption is performed in the following manner ('+' indicates concatenation): b(1) = HMAC-MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) b(2) = HMAC-MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) . . . . b(i) = HMAC-MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) The resulting encrypted String field will contain c(1)+c(2)+...+c(i). [3] On receipt, the process is reversed to yield the plaintext String. Implementation Notes It is possible that the length of the key returned may be larger than needed for the encryption scheme in use. In this case, the RADIUS client is responsible for performing any necessary truncation. The truncation process is described in [SESS]. This attribute MAY be used to pass a key from an external (e.g., EAP [RFC2284]) server to the RADIUS server. In this case, it may be impossible for the external server to correctly encrypt the key, since the RADIUS shared secret might be unavailable. The external Simon & Palekar Informational [Page 5] INTERNET-DRAFT RADIUS Key Attribute 16 January 2002 server SHOULD, however, return the attribute as defined above; the Salt field SHOULD be zero-filled. When the RADIUS server receives the attribute from the external server, it MUST correctly set the Salt field and encrypt the String field before transmitting it to the RADIUS client. If the channel used is not secure from eavesdropping, the attribute MUST be cryptographically protected. 3. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge Accounting # Attribute Request 0 0-1 0 0 0 TBD Master-Session-Key Request Accept Reject Challenge # Attribute 4. Security Considerations This specification utilizes an attribute-hiding mechanism similar to that originally introduced in [RFC2865]. As noted in [RFC2865], there are known weaknesses in this algorithm, some of which are noted in [MD5Attack]. Since the algorithm involves use of a stream cipher for RADIUS attribute hiding, the security of the scheme depends on the global and temporal uniqueness of the Request Authenticator from which the key stream is determined. If the Request Authenticator is repeated on any NAS using the same RADIUS shared secret, then the key stream corresponding to that Request Authenticator should be considered compromised. In an attempt to add additional protection, the algorithm was extended with a salt in [RFC2868] and [RFC2548]. Unfortunately those documents continued to use MD5 [RFC1321] as opposed to HMAC-MD5. Therefore no additional protection was conferred by the salt, since it is passed in the clear, and if the original key stream were to be compromised, then the attacker could immediately calculate the salt-modified keystream from it. It should also be noted that the RADIUS Response Authenticator and Message-Authenticator attributes are vulnerable to dictionary attack, so that if the RADIUS shared secret is chosen carelessly or used on many NASen, then it can be compromised, in which case the attribute hiding scheme described in this specification has no value. These deficiencies can be remedied by running RADIUS over IPsec ESP with a non-null transform, as described in [RFC3162]. Simon & Palekar Informational [Page 6] INTERNET-DRAFT RADIUS Key Attribute 16 January 2002 Note also that RADIUS provides no protection against rogue proxies. Since RADIUS proxies will decrypt and re-encrypt the key field for forwarding, this attribute SHOULD NOT be used on networks where untrusted RADIUS proxies reside. 5. IANA Considerations This draft requires the assignment of a new RADIUS attribute number for the Master-Session-Key attribute. 6. Normative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2104] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] 10 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC3162] Aboba, B., Zorn, G., Mitton, D., "RADIUS and IPv6", RFC 3162, August 2001. 7. Informative References [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC3078] Pall, G. and Zorn, G. "Microsoft Point-to-Point Encryption (MPPE) RFC 3078, March 2001. Simon & Palekar Informational [Page 7] INTERNET-DRAFT RADIUS Key Attribute 16 January 2002 [RFC3079] Zorn, G. "Deriving Keys for use with Microsoft Point-to- Point Encryption (MPPE)," RFC 3079, March 2001. [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996. [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001. [IEEE80211] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1997, 1997. [EAPAPI] Microsoft Developer Network, "Windows 2000 EAP API", August 2000, http://msdn.microsoft.com/library/ default.asp?url=/library/en-us/eap/eapport_0fj9.asp Acknowledgments The authors would like to acknowledge Bernard Aboba and Arun Ayyagari of Microsoft for contributions to this document. Author Addresses Dan Simon Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: dansimon@microsoft.com Phone: +1 425 706 6711 Fax: +1 425 706 7329 Ashwin Palekar Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: ashwinp@microsoft.com Phone: +1 425 882 8080 Fax: +1 425 706 7329 Simon & Palekar Informational [Page 8] INTERNET-DRAFT RADIUS Key Attribute 16 January 2002 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined inthe Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Simon & Palekar Informational [Page 9] INTERNET-DRAFT RADIUS Key Attribute 16 January 2002 Expiration Date This memo is filed as , and expires June 22, 2002. Simon & Palekar Informational [Page 10]