Network Working Group G. Zorn
Internet-Draft Cisco Systems
Expires: December 15, 2004 T. Zhang
3e Technologies International
J. Walker
Intel Corporation
J. Salowey
Cisco Systems
June 16, 2004
RADIUS Attributes for Key Delivery
draft-zorn-radius-keywrap-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 December 15, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines a pair of RADIUS Attributes designed to allow
the secure transmission of encryption keys.
Zorn, et al. Expires December 15, 2004 [Page 1]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Message-Authentication-Code . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
4.1 Attribute Types . . . . . . . . . . . . . . . . . . . . . 10
4.2 Attribute Values . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 14
Zorn, et al. Expires December 15, 2004 [Page 2]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
1. Introduction
Many remote access deployments (for example, deployments utilizing
wireless LAN technology) require the secure transmission of session
keys from an authentication server to a network access point.
Currently, this transfer is most often accomplished using
vendor-specific RADIUS attributes [RFC2548], with the integrity of
the message protected by the RADIUS Response Authenticator [RFC2865].
However, there are several problems with this technique:
o The attributes in question were designed for use with a specific,
proprietary protocol [RFC3078] and may be inappropriate for other
uses
o The "encryption" method used to hide the keys has unknown security
properties and is of questionable strength
o The hash function (MD5, [RFC1321]) used in the construction of the
Response Authenticator is proprietary and the construct itself is
weaker than more modern methods (e.g., HMAC [RFC2104])
This document defines a set of RADIUS Attributes that can be used to
securely transfer encryption keys using non-proprietary techniques
with well understood security properties.
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. Attributes
The following subsections describe the Attributes defined by this
document. This specification concerns the following values:
[TBD1] Key
[TBD2] Message-Authentication-Code
Zorn, et al. Expires December 15, 2004 [Page 3]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
3.1 Key
Description
This Attribute MAY be used in an Access-Accept or Access-Challenge
message to carry an encryption key from a RADIUS server to a
client.
It MAY be sent in Access-Request messages, as well; if the Key
Attribute is present in an Access-Request message, it SHOULD be
taken as a hint by the server that the client prefers this method
of key delivery over others, the server is not obligated to honor
the hint, however. When the Key Attribute is included in an
Access-Request message the Key ID, Lifetime, IV and Key fields MAY
be omitted
Any packet that contains a Key Attribute MUST also include a
Message-Authentication-Code Attribute. If the client requires the
use of the Key Attribute for key delivery and it is not present in
the Access-Accept or Access-Challenge message, the client MAY
ignore the message in question and end the user session.
The Key Attribute MUST NOT be used to transfer long-lived keys
(i.e., passwords) between RADIUS servers and clients.
A summary of the Key attribute format is shown below. The fields
are transmitted from left to right.
Zorn, et al. Expires December 15, 2004 [Page 4]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
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 | Reserved | Enc Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| App ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEK ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
[TBD1] for Key
Length
>= 3
Reserved
This field is reserved for future usage and MUST be
zero-filled.
Enc Type
The Enc Type field indicates the method used to encrypt the key
that is carried in the Key field. This document defines only
one value (decimal) for this field:
0 AES Key Wrap with 128-bit KEK [RFC3394]
Zorn, et al. Expires December 15, 2004 [Page 5]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
Other values are to be assigned by IANA.
Implementation Note
A shared secret is used as the key-encrypting-key (KEK) for
the AES key wrap algorithm. Implementations SHOULD provide
a means to provision a key (cryptographically separate from
the normal RADIUS shared secret) to be used exclusively as a
KEK.
App ID
The App ID field is 4 octets in length and identifies the type
of application for which the key is to be used. Further
specification of the content of this field is outside the scope
of this document.
KEK ID
The KEK ID field is 16 octets in length and contains an
identifier for the KEK. Further specification of the content
of this field is outside the scope of this document.
Key ID
The Key ID field is 16 octets in length and contains an
identifier for the key. Further specification of the content
of this field is outside the scope of this document.
Lifetime
The Lifetime field is an integer [RFC2865] representing the
period of time (in seconds) for which the IV and keying
material are valid.
Note: Applications using this value SHOULD consider the
beginning of the key lifetime to be the point in time when the
key is first used for either encryption or decryption.
IV
The length of the IV field depends upon the value of the Enc
Type field, but is fixed for any given value thereof. When the
value of the Enc Type field is 0 (decimal), the IV field MUST
be 8 octets in length (as illustrated above) and the default
value for the IV field is as specified in [RFC3575].
Zorn, et al. Expires December 15, 2004 [Page 6]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
Key
The Key field is variable length and contains the actual
encrypted keying material.
3.2 Message-Authentication-Code
Description
This Attribute MAY be used to sign Access-Requests to prevent
spoofing Access-Requests using CHAP, ARAP or EAP authentication
methods. It MAY be used in any Access-Request. It MUST be
included in any Access-Request, Access-Accept or Access-Challenge
that contains a Key attribute.
A RADIUS Server receiving an Access-Request containing a
Message-Authentication-Code Attribute present MUST calculate the
correct value of the Message-Authentication-Code and silently
discard the packet if it does not match the value received.
A RADIUS Client receiving an Access-Accept, Access-Reject or
Access-Challenge message containing a Message-Authentication-Code
Attribute MUST calculate the correct value of the
Message-Authentication-Code and silently discard the packet if the
computed value does not match the received value.
A summary of the Message-Authentication-Code 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 | Reserved | MAC Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Key ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC...
Type
[TBD2] for Message-Authentication-Code
Zorn, et al. Expires December 15, 2004 [Page 7]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
Length
>3
MAC Type
The MAC Type field specifies the algorithm used to create the
value in the MAC field. This document defines two values for
the MAC Type field:
0 HMAC-MD5 [RFC1321][RFC2104]
1 HMAC-SHA-1 [FIPS.180-1.1995][RFC2104]
MAC Key ID
The MAC Key ID field is 16 octets in length and contains an
identifier for the key. Further specification of the content
of this field is outside the scope of this document.
MAC
The value of the MAC field depends upon the algorithm specified
by the value of the MAC Type field. The derivation of the MAC
field value for HMAC-MD5 and HMAC-SHA-1 are described below.
HMAC-MD5
When present in an Access-Request packet, the value of the
MAC field is a hash of the entire Access-Request packet,
including Type, ID, Length and Request Authenticator, using
a shared secret as the key, as follows.
MAC = HMAC-MD5(Type, Identifier, Length, Request
Authenticator, Attributes)
Implementation Note
When the hash is calculated the value of the MAC field
MUST be considered to be 16 octets of zero.
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.
For Access-Challenge, Access-Accept, and Access-Reject
packets, the value of the MAC field is calculated as
Zorn, et al. Expires December 15, 2004 [Page 8]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
follows, using the Request-Authenticator from the
Access-Request being responded to:
MAC = HMAC-MD5(Type, Identifier, Length, Request
Authenticator, Attributes)
Implementation Note
When the hash is calculated the value of the MAC field
MUST be considered to be 16 octets of zero.
The Message-Authentication-Code Attribute 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.
HMAC-SHA-1
When present in an Access-Request packet, the value of the
MAC field is a hash of the entire Access-Request packet,
including Type, ID, Length and Request Authenticator, using
a shared secret as the key, as follows.
MAC = HMAC-SHA-1(Type, Identifier, Length, Request
Authenticator, Attributes)
Implementation Note
When the hash is calculated the value of the MAC field
MUST be considered to be 20 octets of zero.
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.
For Access-Challenge, Access-Accept, and Access-Reject
packets, the value of the MAC field is calculated as
follows, using the Request-Authenticator from the
Access-Request being responded to:
MAC = HMAC-SHA-1(Type, Identifier, Length, Request
Authenticator, Attributes)
Zorn, et al. Expires December 15, 2004 [Page 9]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
Implementation Note
When the hash is calculated the value of the MAC field
MUST be considered to be 20 octets of zero.
The Message-Authentication-Code Attribute 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.
4. 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 [RFC2434].
4.1 Attribute Types
Upon publication of this document as an RFC, IANA must assign
numbers to the Key and Message-Authentication-Code Attributes.
4.2 Attribute Values
As defined in Section 3.1, numbers may need to be assigned for future
values of the Enc Type field of the Key attribute. These numbers may
be assigned by applying the "Specification Required" policy. In
particular, specifications MUST define the length of the IV field for
the algorithm used.
As defined in Section 3.2, numbers may need to be assigned for future
values of the MAC Type field of the Message-Authentication-Code
attribute. These numbers may be assigned by applying the
"Specification Required" policy.
5. Security Considerations
It is RECOMMENDED in this memo that two new keys be shared by the
RADIUS client and server. These two keys MUST be different from each
other and SHOULD NOT be based on a password. These two keys SHOULD
be cryptographically independent of the RADIUS shared secret used in
calculating the Response Authenticator [RFC2865].
Zorn, et al. Expires December 15, 2004 [Page 10]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
If more than one Key Attribute is included in a single RADIUS packet,
the IV field of each Key Attribute SHOULD be unique.
6. Contributors
Hao Zhou, Nancy Cam-Winget, Jesse Walker, Tiebing Zhang and John
Fossaceca all contributed to this document.
7. Acknowledgements
Thanks (in no particular order) to Keith McCloghrie and Greg Weber
for useful feedback.
8. References
8.1 Normative References
[FIPS.180-1.1995]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, July
2003.
Zorn, et al. Expires December 15, 2004 [Page 11]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
8.2 Informative References
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
(MPPE) Protocol", RFC 3078, March 2001.
Authors' Addresses
Glen Zorn
Cisco Systems
2901 Third Avenue, Suite 600
SEA1/5/
Seattle, WA 98121
US
Phone: +1 (425) 344 8113
EMail: gwz@cisco.com
Tiebing Zhang
3e Technologies International
700 King Farm Blvd.
Rockville, MD 20850
US
Phone: +1 (301) 944-1322
EMail: tzhang@3eti.com
Jesse Walker
Intel Corporation
JF3-206
2111 N.E. 25th Ave
Hillsboro, OR 97214-5961
US
Phone: +1 (503) 712-1849
EMail: jesse.walker@intel.com
Zorn, et al. Expires December 15, 2004 [Page 12]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
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 December 15, 2004 [Page 13]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
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 (2004). 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 implementation 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 in the 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 assignees.
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
Zorn, et al. Expires December 15, 2004 [Page 14]
Internet-Draft RADIUS Attributes for Key Delivery June 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zorn, et al. Expires December 15, 2004 [Page 15]