One document matched: draft-zorn-radius-encattr-13.txt
Differences from draft-zorn-radius-encattr-12.txt
Network Working Group G. Zorn
Internet-Draft NetCube Technologies
Intended status: Standards Track H. Zhou
Expires: February 16, 2009 J. Salowey
Cisco Systems
August 15, 2008
Transmitting Confential Data in RADIUS
draft-zorn-radius-encattr-13.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 February 16, 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 February 16, 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 February 16, 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 February 16, 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:
<TBD1> Encryption-Type
<TBD2> Application-Id
<TBD3> Encrypting-Key-Id
<TBD4> Key-Id
<TBD5> Key-Lifetime
<TBD6> Initialization-Vector
<TBD7> Encrypted-Data
<TBD8> Message-Authentication-Code
<TBD9> MAC-Randomizer
<TBD10> MAC-Key-Id
<TBD11> 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 February 16, 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
<TBD1> 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 February 16, 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 February 16, 2009 [Page 6]
Internet-Draft Encrypted Attributes August 2008
Ext-Type
<TBD2> 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 February 16, 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
<TBD3> 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 February 16, 2009 [Page 8]
Internet-Draft Encrypted Attributes August 2008
Ext-Type
<TBD4> 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 February 16, 2009 [Page 9]
Internet-Draft Encrypted Attributes August 2008
Ext-Type
<TBD5> 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
<TBD6> for Initialization-Vector
Zorn, et al. Expires February 16, 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 February 16, 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
<TBD7> 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 February 16, 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 February 16, 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 February 16, 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 February 16, 2009 [Page 15]
Internet-Draft Encrypted Attributes August 2008
Ext-Type
<TBD8> 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 February 16, 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 February 16, 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
<TBD10> 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
<TBD11> for MAC-Type
Zorn, et al. Expires February 16, 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:
<TBD1> Encryption-Type
Zorn, et al. Expires February 16, 2009 [Page 19]
Internet-Draft Encrypted Attributes August 2008
<TBD2> Application-Id
<TBD3> Encrypting-Key-Id
<TBD4> Key-Id
<TBD5> Key-Lifetime
<TBD6> Initialization-Vector
<TBD7> Encrypted-Data
<TBD8> Message-Authentication-Code
<TBD9> MAC-Randomizer
<TBD10> MAC-Key-Id
<TBD11> 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 February 16, 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, <http://
.nist.gov/publications/fips/fips180-2/
fips180-2withchangenotice.pdf>.
[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 February 16, 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, <h
ttp://csrc.nist.gov/CryptoToolkit/modes/
800-38_Series_Publications/SP800-38B.pdf>.
[PKCS.1.1998]
Kaliski, BK. and JS. Staddon, "RSA Encryption Standard,
Version 2.0", PKCS 1, October 1998,
<ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-1v2.asc>.
[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 February 16, 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 February 16, 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 February 16, 2009 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-23 02:36:07 |