Network Working Group G. Zorn Internet-Draft NetCube Technologies Intended status: Standards Track H. Zhou Expires: March 3, 2009 J. Salowey Cisco Systems August 30, 2008 Transmitting Confidential Data in RADIUS draft-zorn-radius-encattr-14.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on March 3, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines a set of Type-Length-Value (TLV) tuples which, when encapsulated in RADIUS Extended Attributes, are designed to allow the secure transmission of sensitive or confidential data (including encryption keys) between RADIUS clients and servers. Zorn, et al. Expires March 3, 2009 [Page 1] Internet-Draft Encrypted Attributes August 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 3. Type-Length-Value Definitions . . . . . . . . . . . . . . . . 4 3.1. Encryption-Type . . . . . . . . . . . . . . . . . . . . . 5 3.2. Application-Id . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Encrypting-Key-Id . . . . . . . . . . . . . . . . . . . . 7 3.4. Key-Id . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Key-Lifetime . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Initialization-Vector . . . . . . . . . . . . . . . . . . 10 3.7. Encrypted-Data . . . . . . . . . . . . . . . . . . . . . . 11 3.8. Message-Authentication-Code . . . . . . . . . . . . . . . 12 3.8.1. Protecting Entire RADIUS Messages . . . . . . . . . . 13 3.8.2. Protecting a Subset of the Attributes in a Message . . 15 3.9. MAC-Randomizer . . . . . . . . . . . . . . . . . . . . . . 16 3.10. MAC-Key-Id . . . . . . . . . . . . . . . . . . . . . . . . 17 3.11. MAC-Type . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Diameter Considerations . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5.1. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Zorn, et al. Expires March 3, 2009 [Page 2] Internet-Draft Encrypted Attributes August 2008 1. Introduction Certain applications of the RADIUS protocol [RFC2865] require that the content (at least, if not the type and length) of one or more Attributes in a message be encrypted. For example, an application enabling the interception of certain packets by law enforcement agencies might require that it be impossible for an observer to distinguish between sessions which are under surveillance and those that are not. If packet interception is enabled and disabled using RADIUS (via the Access-Accept [RFC2865] or CoA-Request [RFC5176] messages, for example) then the Attributes used to signal this must be encrypted; however, it might be acceptable for the remainder of the Attributes to be sent in cleartext. Currently, this type of transfer is usually accomplished using either the Tunnel-Password Attribute [RFC2868] or vendor-specific RADIUS attributes. However, there are several issues with these techniques: o The Tunnel-Password Attribute was not designed to carry entire RADIUS Attributes and it is not large enough to hold an Attribute of the maximum size o The security properties and strength of the encryption method used to hide the contents of the Tunnel-Password Attribute are unknown o Due to its dependency upon the random Request Authenticator in the Access-Request message [RFC2865], the Tunnel-Password Attribute cannot be used in messages other than Access-Accept o Although vendor-specific Attributes may not share the problems outlined above, a profusion of different attributes used for the same purpose entails considerable multiplication of effort and makes interoperability difficult to achieve Similarly, encryption keys such as those derived as a side-effect of some EAP [RFC3748] authentication methods are often transported using RADIUS. These keys must be kept confidential, as well, though the protection of keys may demand different cryptographic qualities then that of other data. This document defines a set of Type-Length-Value (TLV) tuples which, when encapsulated in RADIUS Extended Attributes [I-D.ietf-radext-extended-attributes], are designed to allow the secure transmission of sensitive or confidential data (including encryption keys) between RADIUS clients and servers using non- proprietary techniques with well-understood security properties. In addition, the Message-Authentication-Code TLV may be used by itself to provide strong, algorithically agile authentication for any RADIUS Zorn, et al. Expires March 3, 2009 [Page 3] Internet-Draft Encrypted Attributes August 2008 message, including those used for accounting and dynamic authorization. Discussion of this draft may be directed to the authors. 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Type-Length-Value Definitions The following subsections describe the TLVs defined by this document. This specification concerns the following values: Encryption-Type Application-Id Encrypting-Key-Id Key-Id Key-Lifetime Initialization-Vector Encrypted-Data Message-Authentication-Code MAC-Randomizer MAC-Key-Id MAC-Type NOTE: These values do not represent traditional RADIUS Attributes: in order to be included in a RADIUS message, TLVs MUST be encapsulated in one or more Extended RADIUS Attributes [I-D.ietf-radext-extended-attributes]. Zorn, et al. Expires March 3, 2009 [Page 4] Internet-Draft Encrypted Attributes August 2008 3.1. Encryption-Type Description The Encryption-Type TLV is used to specify the cryptographic algorithm used to protect the Encrypted-Data TLV (Section 3.7) Any packet that contains an Extended Attribute encapsulating an instance of the Encryption-Type TLV MUST also contain one or more associated instances of the Encrypted-Data TLV (Section 3.7). The TLVs may be associated in two ways: if all of the TLVs can fit into a single Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method [I-D.ietf-radext-extended-attributes]. A summary of the Encryption-Type TLV format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ext-Type for Encryption-Type Ext-Len 4 Value The Value field is 1 octet in length and serves to identify the encryption algorithm in use. This document defines the following decimal values for this field: 0 NULL 1 AES-CBC-128 [FIPS-197-2001] 2 AES-CBC-192 [FIPS-197-2001] Zorn, et al. Expires March 3, 2009 [Page 5] Internet-Draft Encrypted Attributes August 2008 3 AES-CBC-256 [FIPS-197-2001] 4 AES Key Wrap with 128-bit KEK [RFC3394] 5 AEAD_AES_SIV_CMAC_256 [I-D.dharkins-siv-aes] 6 AEAD_AES_SIV_CMAC_384 [I-D.dharkins-siv-aes] 7 AEAD_AES_SIV_CMAC_512 [I-D.dharkins-siv-aes] 8 RSAES-OAEP [PKCS.1.1998] Implementations MUST support encryption types 0 (NULL), 1 (AES- CBC-128) and 4 (AES Key Wrap). Other values are to be assigned by IANA. 3.2. Application-Id Description The Application-Id TLV is 7 octets in length. If the Encrypted- Data TLV (Section 3.7) contains a cryptographic key, the Application-Id TLV MAY be used to identify the type of application for which the key material is to be used. This allows for multiple keys for different purposes to be present in the same message. Any packet that contains an Extended Attribute encapsulating an instance of the Application-Id TLV MUST also contain one or more associated instances of the Encrypted-Data TLV (Section 3.7). The TLVs may be associated in two ways: if all of the TLVs can fit into a single Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method [I-D.ietf-radext-extended-attributes]. A summary of the Application-Id TLV format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zorn, et al. Expires March 3, 2009 [Page 6] Internet-Draft Encrypted Attributes August 2008 Ext-Type for Application-Id Ext-Len 7 Value The Value field is 4 octets in length and identifies the type of application for which the key encapsulated in the associated Encrypted-Data TLV is to be used. This document defines the following decimal values for this field: 0 Unspecified 1 EAP MSK [RFC3748] Other values are to be assigned by IANA. 3.3. Encrypting-Key-Id Description The Encrypting-Key-Id TLV is variable length and MAY be used to identify the shared cryptographic key used to protect the Encrypted-Data TLV (Section 3.7). If present, the Encrypting-Key-Id TLV MUST refer to an encryption key of a type and length appropriate for use with the algorithm specified by the Encryption-Type TLV (Section 3.1). Further specification of the content of this TLV is outside the scope of this document. Any packet that contains an Extended Attribute encapsulating an instance of the Encrypting-Key-Id TLV MUST also contain one or more associated instances of the Encrypted-Data TLV (Section 3.7). The TLVs may be associated in two ways: if all of the TLVs can fit into a single Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method [I-D.ietf-radext-extended-attributes]. A summary of the Encrypting-Key-Id TLV format is shown below. The fields are transmitted from left to right. Zorn, et al. Expires March 3, 2009 [Page 7] Internet-Draft Encrypted Attributes August 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ext-Type for Encrypting-Key-Id Ext-Len >= 4 Value The Value field is variable length and MAY be used to identify the shared cryptographic key used to protect the Encrypted-Data TLV. 3.4. Key-Id Description The Key-Id TLV is variable length. If the Encrypted-Data TLV (Section 3.7) contains cryptographic keying material, the Key-Id TLV MAY be used by the communicating parties to identify the material being transmitted. The Key-Id is assumed to be known to the parties that derived the keying material. Further specification of the content of this TLV is outside the scope of this document. Any packet that contains an Extended Attribute encapsulating an instance of the Key-Id TLV MUST also contain one or more associated instances of the Encrypted-Data TLV (Section 3.7). The TLVs may be associated in two ways: if all of the TLVs can fit into a single Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method [I-D.ietf-radext-extended-attributes]. A summary of the Key-Id TLV format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zorn, et al. Expires March 3, 2009 [Page 8] Internet-Draft Encrypted Attributes August 2008 Ext-Type for Key-Id Ext-Len >= 4 Value The Value field is variable length and MAY be used to identify the key encapsulated in the Encrypted-Data TLV. 3.5. Key-Lifetime Description If the data encapsulated in the Encrypted-Data TLV is a cryptographic key, the value of the Key-Lifetime TLV represents the period of time (in seconds) for which the key is valid. NOTE: Applications using this value SHOULD consider the beginning of the lifetime to be the point in time when the key is first used. Any packet that contains an Extended Attribute encapsulating an instance of the Key-Lifetime TLV MUST also contain one or more associated instances of the Encrypted-Data TLV (Section 3.7). The TLVs may be associated in two ways: if all of the TLVs can fit into a single Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method [I-D.ietf-radext-extended-attributes]. A summary of the Key-Lifetime TLV format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zorn, et al. Expires March 3, 2009 [Page 9] Internet-Draft Encrypted Attributes August 2008 Ext-Type for Key-Lifetime Ext-Len 7 Value The Value field is a 32-bit integer [RFC2865] and MAY be used to specify the length of time (in seconds) that the key is valid. 3.6. Initialization-Vector Description If the data encapsulated in the Encrypted-Data TLV represents a cryptographic key and the algorithm specified by the Encryption- Type TLV requires the use of an initialization vector (IV), this TLV may be used to communicate the IV from the RADIUS server to its client. Any packet that contains an Extended Attribute encapsulating an instance of the Initialization-Vector TLV MUST also contain one or more associated instances of the Encrypted-Data TLV (Section 3.7). The TLVs may be associated in two ways: if all of the TLVs can fit into a single Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method [I-D.ietf-radext-extended-attributes]. A summary of the Initialization-Vector TLV format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ext-Type for Initialization-Vector Zorn, et al. Expires March 3, 2009 [Page 10] Internet-Draft Encrypted Attributes August 2008 Ext-Len >= 4 Value The length of the Value field depends upon the value of the Encryption-Type TLV, but is fixed for any given value thereof. 3.7. Encrypted-Data Description This TLV MAY be used to carry one or more encrypted TLVs or Attributes (traditional, extended or a mixture thereof) in a RADIUS message. Any packet that contains an Encrypted-Data TLV MUST also include an associated instance of the Encryption-Type TLV and SHOULD include associated instances of the Message-Authentication-Code (Section 3.8) and MAC-Type (Section 3.11) TLVs. The TLVs may be associated in two ways: if all of the TLVs can fit into a single Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method [I-D.ietf-radext-extended-attributes]. The encryption of the Attribute(s) MUST be performed by the sender according to the following algorithm: Concatenate the Attributes to be encrypted. If the algorithm specified by the associated Encryption-Type TLV (Section 3.1) is a block cipher and the length in octets of the result is not an even multiple of the algorithm's block size, pad the result of the concatenation on the right with enough zero-value octets to make the resulting string an even multiple of the block size in length. Encrypt the result using the algorithm specified by the Encryption-Type and, if necessary, an initialization vector. If an IV is used, store it in an associated Initialization-Vector TLV (Section 3.6). Split the resulting ciphertext into one or more chunks, each <= 243 octets in length. Encapsulate each chunk in a separate instance of the Encrypted-Data TLV. The receiver MUST recover the plaintext Attribute(s) using the following algorithm: Zorn, et al. Expires March 3, 2009 [Page 11] Internet-Draft Encrypted Attributes August 2008 Concatenate the String fields of the received Encrypted-Data TLVs in order of reception. Decrypt the result using the algorithm specified in the associated Encryption-Type TLV and (if necessary) the IV contained in the associated Initialization-Vector TLV. Split the resulting cleartext in to Attributes, discarding the padding (if any). Type-Length-Value tuples may be encrypted using the same algorithm as Attributes. A summary of the Encrypted-Data TLV format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ext-Type for Encrypted-Data Ext-Length >= 4 String The String field is variable length and contains the actual encrypted data (see above). 3.8. Message-Authentication-Code Description This TLV MAY be used to "sign" groups of Attributes or TLVs or whole RADIUS messages to prevent spoofing. If it is present in a request, the receiver should take this a hint that the sender prefers the use of this Attribute for message authentication; the receiver is not obligated to do so, however. Zorn, et al. Expires March 3, 2009 [Page 12] Internet-Draft Encrypted Attributes August 2008 3.8.1. Protecting Entire RADIUS Messages If the Message-Authentication-Code TLV is used to protect an entire RADIUS message, the Extended Attribute in which it is encapsulated MUST NOT contain any TLVs that are not MAC-related; i.e., only the Message-Authentication-Code, MAC-Type (Section 3.11), MAC-Randomizer (Section 3.9) and MAC-Key-Id (Section 3.10) may be present in the Extended Attribute. Since in this case the Message-Authentication-Code TLV is not associated with any particular subset of Attributes in the message, the Tag field of the encapsulating Extended Attribute MUST be set to 0 (zero). In addition, the message SHOULD NOT also contain an instance of the Message-Authenticator Attribute [RFC3579]. If both the Message-Authentication-Code TLV and the Message-Authenticator Attribute are to be used to protect a message (e.g., for backward compatibility in a network containing both old and new clients), the value of the Message-Authentication-Code TLV MUST be computed before that of the Message-Authenticator Attribute. If any message is received that has been protected with the Message-Authentication-Code TLV, the receiver MUST calculate the correct value of the Message-Authentication-Code and silently discard the packet if the computed value does not match the value received. If a received message contains an instance of the MAC-Randomizer TLV (Section 3.9), the received MAC-Randomizer TLV SHOULD be included in the computation of the Message-Authentication-Code TLV sent in the response, as described below. When an entire message is being protected, the derivation of the MAC field value of the Message-Authentication-Code TLV (below) is identical for all the algorithms specified in this document, with the exception of the algorithm used. There are differences, however, depending upon whether the MAC is being computed for a request message or a response. These differences are detailed below, with the free variable HASH-ALG representing the actual algorithm used. 3.8.1.1. Request Messages For requests (e.g., CoA-Request [RFC5176], Accounting-Request [RFC2866], etc.), the value of the MAC field is a hash of the entire packet except the Request Authenticator in the header of the RADIUS Zorn, et al. Expires March 3, 2009 [Page 13] Internet-Draft Encrypted Attributes August 2008 packet, using a shared secret as the key, as follows. MAC = MAC-ALG(Key, Type + Identifier + Length + Attributes) where '+' represents concatenation The MAC-Randomizer TLV (Section 3.9) MUST be included in any request in which the Message-Authentication-Code TLV is used. The Random field of the MAC-Randomizer TLV MUST be filled in before the value of the MAC field is computed. If the Message-Authenticator-Code TLV is included in a client request, the server SHOULD ignore the contents of the Request Authenticator. Implementation Notes When the hash is calculated, both the MAC field of the Message- Authenticator-Code TLV and the String field of the Message- Authenticator Attribute (if any) MUST be considered to be zero- filled. Implementations SHOULD provide a means to provision a key (cryptographically separate from the normal RADIUS shared secret) to be used exclusively in the generation of the Message- Authentication-Code. 3.8.1.2. Response Messages For responses (e.g., CoA-ACK [RFC5176], Accounting-Response [RFC2866], etc.), the value of the MAC field is a hash of the entire packet except the Response Authenticator in the header of the RADIUS packet using a shared secret as the key, as follows. MAC = HASH-ALG(Key, Type + Identifier + Length + Attributes) where '+' represents concatenation If the request contained an instance of the MAC-Randomizer TLV and the responder wishes to include an instance of the Message- Authentication-Code TLV in the corresponding response, then the MAC- Randomizer TLV from the request MUST be included in the response. If the Message-Authenticator-Code TLV is included in a server response, the client SHOULD ignore the contents of the Response Authenticator. Zorn, et al. Expires March 3, 2009 [Page 14] Internet-Draft Encrypted Attributes August 2008 Implementation Notes When the hash is calculated, both the MAC field of the Message- Authenticator-Code TLV and the String field of the Message- Authenticator Attribute (if any) MUST be considered to be zero- filled. The Message-Authentication-Code TLV MUST be created and inserted in the packet before the Response Authenticator is calculated. Implementations SHOULD provide a means to provision a key (cryptographically separate from the normal RADIUS shared secret) to be used exclusively in the generation of the Message- Authentication-Code. 3.8.2. Protecting a Subset of the Attributes in a Message Authenticating and protecting the integrity of a set of Extended RADIUS Attributes is simple: simply assemble the Attributes to be protected, choose an appropriate algorithm and run it over the assembled Attributes. If all the TLVs to be protected will fit in a single Extended Attribute along with the associated MAC-related TLVs then this is sufficient to associate the protected TLVs with the MAC; otherwise, the MAC-related TLVs can be place in a separate TLV and the TAG method used to associate the Extended Attributes. If any traditional RADIUS Attributes are in the set of Attributes to be protected, however, the above technique cannot be used. In this case, it is necessary to concatenate the Attributes into one or more Encrypted-Data TLVs, setting the associated Encryption-Type TLV to 0 (zero) for the Null algorithm), the run the selected MAC algorithm over that set of TLVs. If all the TLVs to be protected will fit in a single Extended Attribute along with the associated MAC-related TLVs then this is sufficient to associate the protected TLVs with the MAC; otherwise, the MAC-related TLVs can be place in a separate TLV and the TAG method used to associate the Extended Attributes. A summary of the Message-Authentication-Code TLV format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | MAC... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zorn, et al. Expires March 3, 2009 [Page 15] Internet-Draft Encrypted Attributes August 2008 Ext-Type for Message-Authentication-Code Ext-Length >4 MAC Both the length and value of the MAC field depend upon the algorithm specified by the value of the MAC-Type TLV (Section 3.11) If the algorithm specified is HMAC-SHA-1, HMAC- SHA-256 or HMAC-SHA-512, the MAC field MUST be 20, 32 or 64 octets in length, respectively. If the algorithm specified is CMAC-AES-128, CMAC-AES-192 or CMAC-AES-256, the MAC field SHOULD be 64 octets in length. 3.9. MAC-Randomizer Description The MAC-Randomizer TLV MUST be present in any message that includes an instance of the Message-Authentication-Code TLV. The Random field MUST contain a 32 octet random number which SHOULD satisfy the requirements of [RFC4086]. Implementation Note The Random field MUST be filled in before the MAC is computed. The MAC-Randomizer TLV SHOULD be placed at the beginning of the RADIUS message if possible. A summary of the MAC-Randomizer attribute format is shown below. The fields are transmitted from left to right. Zorn, et al. Expires March 3, 2009 [Page 16] Internet-Draft Encrypted Attributes August 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | Random... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Random (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Random (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Random (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Random (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Random (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Random (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Random (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Random (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type >TBD9< for MAC-Randomizer Length 35 Random This field MUST contain a 32 octet random number which SHOULD satisfy the requirements of [RFC4086]. 3.10. MAC-Key-Id Description The MAC-Key-Id TLV is variable length and MAY be used to encapsulate an identifier for the key used in the calculation of the Message-Authentication-Code TLV. If present, the MAC-Key-Id TLV MUST refer to a key of a type and length appropriate for use with the algorithm specified by the MAC-Type TLV (Section 3.11). Further specification of the content of this field is outside the Zorn, et al. Expires March 3, 2009 [Page 17] Internet-Draft Encrypted Attributes August 2008 scope of this document. A summary of the MAC-Key-Id TLV format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ext-Type for MAC-Key-Id Ext-Len >= 4 Value The Value field contains an identifier for the key used in the calculation of the Message-Authentication-Code TLV 3.11. MAC-Type Description The MAC-Type TLV is 4 octets in length and MUST be used to specify the algorithm used in the calculation of the Message- Authentication-Code TLV. A summary of the MAC-Type TLV format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ext-Type for MAC-Type Zorn, et al. Expires March 3, 2009 [Page 18] Internet-Draft Encrypted Attributes August 2008 Ext-Len 4 Value The Value field is 1 octet in length and serves to identify the MAC algorithm in use. This document defines six values for the Value field: 0 HMAC-SHA-1 [FIPS.180-2.2002] [RFC2104] 1 HMAC-SHA-256 [FIPS.180-2.2002] [RFC4231] 2 HMAC-SHA-512 [FIPS.180-2.2002] [RFC4231] 3 CMAC-AES-128 [NIST.SP800-38B] 4 CMAC-AES-192 [NIST.SP800-38B] 5 CMAC-AES-256 [NIST.SP800-38B] Implementations MUST support MAC Type 0 (HMAC-SHA-1); other values are to be assigned by IANA. 4. Diameter Considerations > Since the TLVs defined in this document are designed to be carried by Extended Attributes [I-D.ietf-radext-extended-attributes], there are no special considerations for interoperation with Diameter. 5. IANA Considerations This section explains the criteria to be used by the IANA for assignment of numbers within namespaces defined within this document. The "Specification Required" policy is used here with the meaning defined in BCP 26 [RFC5226]. 5.1. TLV Types Upon publication of this document as an RFC, IANA must assign RADIUS Extended Type numbers [I-D.ietf-radext-extended-attributes] to the following TLVS: Encryption-Type Zorn, et al. Expires March 3, 2009 [Page 19] Internet-Draft Encrypted Attributes August 2008 Application-Id Encrypting-Key-Id Key-Id Key-Lifetime Initialization-Vector Encrypted-Data Message-Authentication-Code MAC-Randomizer MAC-Key-Id MAC-Type 5.2. TLV Values As defined in Section 3.1, numbers may need to be assigned for future values of the Encryption-Type TLV. These numbers may be assigned by applying the "Specification Required" policy. As defined in Section 3.11, numbers may need to be assigned for future values of the MAC-Type TLV. These numbers may be assigned by applying the "Specification Required" policy. As defined in Section 3.2, numbers may need to be assigned for future values of the Application-Id TLV. These numbers may be assigned by applying the "Specification Required" policy. 6. Security Considerations Although the encryption algorithms specified in this document are believed to be strong, ultimately the confidentiality of the encrypted attributes depends upon the strength of the keys used to encrypt them. For this reason, implementations SHOULD use keys with entropy equal to or greater than the strength of the algorithm used (e.g., 128 bits of entropy for AES-CBC-128, etc.). Given that the secret shared between RADIUS clients and servers typically has relatively weak entropy, it is NOT RECOMMENDED that implementations use the shared secret (or a derivative thereof) as a key for attribute encryption. Zorn, et al. Expires March 3, 2009 [Page 20] Internet-Draft Encrypted Attributes August 2008 To avoid the possibility of collisions, the same MAC key SHOULD NOT be used with more than 2^(n/2) messages, where 'n' is the length of the MAC value in octets. Since the successful application of the AES Key Wrap with 128-bit KEK (Section 3.1) requires randomness in the quantity to be wrapped, this algorithm MUST NOT be used to encrypt non-random data. 7. Contributors Nancy Cam-Winget, Paul Funk and John Fossaceca all contributed to this document. 8. Acknowledgements Thanks (in no particular order) to Keith McCloghrie, Kaushik Narayan, Murtaza Chiba, Bill Burr, Russ Housley, David McGrew, Pat Calhoun, Joel Halpern, Jim Schaad, Dan Harkins and Greg Weber for review and useful feedback. 9. References 9.1. Normative References [FIPS-197-2001] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, < http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>. [FIPS.180-2.2002] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, . [I-D.dharkins-siv-aes] Harkins, D., "SIV Authenticated Encryption using AES", draft-dharkins-siv-aes-05 (work in progress), June 2008. [I-D.ietf-radext-extended-attributes] Li, Y., Lior, A., and G. Zorn, "Extended Remote Authentication Dial In User Service (RADIUS) Attributes", draft-ietf-radext-extended-attributes-04 (work in progress), July 2008. Zorn, et al. Expires March 3, 2009 [Page 21] Internet-Draft Encrypted Attributes August 2008 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, December 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 9.2. Informative References [NIST.SP800-38B] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", May 2005, . [PKCS.1.1998] Kaliski, BK. and JS. Staddon, "RSA Encryption Standard, Version 2.0", PKCS 1, October 1998, . [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. Zorn, et al. Expires March 3, 2009 [Page 22] Internet-Draft Encrypted Attributes August 2008 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. Authors' Addresses Glen Zorn NetCube Technologies 77/440 Soi Phoomjit Rama IV Road Phrakanong Klongtoie Bangkok 10110 Thailand Phone: +66 (0) 6600 6480 Email: gwz@netcube.com Hao Zhou Cisco Systems 4125 Highlander Parkway REQ01/3/ Richfield, OH 44286 US Phone: +1 (330) 523-2132 Email: hzhou@cisco.com Joseph Salowey Cisco Systems 2901 Third Avenue SEA1/6/ Seattle, WA 98121 US Phone: +1 (206) 256-3380 Email: jsalowey@cisco.com Zorn, et al. Expires March 3, 2009 [Page 23] Internet-Draft Encrypted Attributes August 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Zorn, et al. Expires March 3, 2009 [Page 24]