One document matched: draft-zorn-radius-encattr-00.txt
Network Working Group G. Zorn
Internet-Draft H. Zhou
Expires: August 15, 2005 J. Salowey
Cisco Systems
February 11, 2005
Transmitting Confidential Data in RADIUS
draft-zorn-radius-encattr-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a pair of RADIUS Attributes designed to allow
the secure transmission of sensitive or confidential data between
RADIUS clients and servers.
Zorn, et al. Expires August 15, 2005 [Page 1]
Internet-Draft Transmitting Confidential Data in RADIUS February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Crypto-Params . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Encrypted-Attribute . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1 Attribute Types . . . . . . . . . . . . . . . . . . . . . 7
4.2 Attribute Values . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1 Normative References . . . . . . . . . . . . . . . . . . . 7
6.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 10
Zorn, et al. Expires August 15, 2005 [Page 2]
Internet-Draft Transmitting Confidential Data in RADIUS February 2005
1. Introduction
Certain applications of the RADIUS protocol [RFC2865] require the
content (at least, if not the type and length) of one or more
Attributes in a message to 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 [RFC3576]
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
This document defines RADIUS Attributes that can be used to
encapsulate and confidentially transfer one or more RADIUS Attributes
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].
Zorn, et al. Expires August 15, 2005 [Page 3]
Internet-Draft Transmitting Confidential Data in RADIUS February 2005
3. Attributes
The following subsections describe the Attributes defined by this
document. This specification concerns the following values:
[TBD1] Crypto-Params
[TBD2] Encrypted-Attribute
3.1 Crypto-Params
Description
This Attribute is used to carry data used during the encryption
and decryption of the Attribute(s) encapsulated in the
Encrypted-Attribute Attribute, specifically the initialization
vector and algorithm identifier.
Any packet that contains an Crypto-Params Attribute MUST also
contain a Message-Authentication-Code Attribute [KEYWRAP] and
SHOULD contain one or more instances of the Encrypted-Attribute
Attribute.
A summary of the Crypto-Params 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 | Enc Type | Key ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key ID (cont'd) | IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
[TBD2] for Crypto-Params
Zorn, et al. Expires August 15, 2005 [Page 4]
Internet-Draft Transmitting Confidential Data in RADIUS February 2005
Length
>=19
Enc Type
The Enc Type 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 AES-CBC-128 [FIPS-197-2001]
1 AES-CBC-192 [FIPS-197-2001]
2 AES-CBC-256 [FIPS-197-2001]
Other values are to be assigned by IANA.
Key ID
The Key ID field is 16 octets in length and contains an
identifier for the key used to encrypt and decrypt the String
field of the Encrypted-Attribute Attribute (section 3.2).
Further specification of the content of this field is outside
the scope of this document.
IV
The IV field is variable length and contains the initialization
vector. The length of the IV field depends upon the algorithm
specified in the Enc Type field (above); for the algorithms
defined in this document, the length of the IV field is 16
octets. If no initialization vector is required by the
algorithm specified by the Enc Type field, this field MAY be
omitted.
3.2 Encrypted-Attribute
Description
This Attribute MAY be used to carry one or more encrypted
Attributes in a RADIUS message.
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
Zorn, et al. Expires August 15, 2005 [Page 5]
Internet-Draft Transmitting Confidential Data in RADIUS February 2005
specified by the Enc Type field of the Crypto-Params Attribute
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 Enc Type field and the initialization vector contained in
the IV field of the Crypto-Params Attribute (section 3.1).
Split the resulting ciphertext into one or more chunks, each <=
253 octets in length. Encapsulate each chunk in a separate
instance of the Encrypted-Attribute Attribute.
The receiver MUST recover the plaintext Attribute(s) using the
following algorithm:
Concatenate the String fields of the received
Encrypted-Attribute Attributes in order of reception. Decrypt
the result using the algorithm specified in the Enc Type field
and the initialization vector contained in the IV field of the
Crypto-Params Attribute (section 3.1). Split the resulting
cleartext in to Attributes, discarding the padding (if any).
Any packet that contains an Encrypted-Attribute Attribute MUST
also include both a Crypto-Params Attribute (section 3.1) and a
Message-Authentication-Code Attribute [KEYWRAP].
The Encrypted-Attribute Attribute MUST NOT be used to transfer
keys between RADIUS servers and clients.
A summary of the Encrypted-Attribute 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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
[TBD2] for Encrypted-Attribute
Length
>3
Zorn, et al. Expires August 15, 2005 [Page 6]
Internet-Draft Transmitting Confidential Data in RADIUS February 2005
String
The String field is variable length and contains the actual
encrypted Attributes (see above).
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 Crypto-Params and Encrypted-Attribute 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 Crypto-Params attribute. These
numbers may be assigned by applying the "Specification Required"
policy.
5. 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.
6. References
6.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.p
Zorn, et al. Expires August 15, 2005 [Page 7]
Internet-Draft Transmitting Confidential Data in RADIUS February 2005
df>.
[KEYWRAP] Zorn, G., Zhang, T., Walker, J. and J. Salowey, "RADIUS
Attributes for Key Delivery",
Internet-Draft draft-zorn-radius-keywrap-03.txt, February
2005.
[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.
6.2 Informative References
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003.
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
Zorn, et al. Expires August 15, 2005 [Page 8]
Internet-Draft Transmitting Confidential Data in RADIUS February 2005
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 August 15, 2005 [Page 9]
Internet-Draft Transmitting Confidential Data in RADIUS February 2005
Intellectual Property Statement
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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zorn, et al. Expires August 15, 2005 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 02:36:06 |