One document matched: draft-zorn-radius-encattr-02.txt
Differences from draft-zorn-radius-encattr-01.txt
Network Working Group G. Zorn
Internet-Draft H. Zhou
Expires: August 20, 2006 J. Salowey
Cisco Systems
February 16, 2006
Transmitting Confidential Data in RADIUS
draft-zorn-radius-encattr-02.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 August 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 20, 2006 [Page 1]
Internet-Draft Encrypted Attributes February 2006
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 Normative References . . . . . . . . . . . . . . . . . . . 8
6.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Zorn, et al. Expires August 20, 2006 [Page 2]
Internet-Draft Encrypted Attributes February 2006
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 20, 2006 [Page 3]
Internet-Draft Encrypted Attributes February 2006
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 20, 2006 [Page 4]
Internet-Draft Encrypted Attributes February 2006
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 NULL
1 AES-CBC-128 [FIPS-197-2001]
2 AES-CBC-192 [FIPS-197-2001]
3 AES-CBC-256 [FIPS-197-2001]
Implementations MUST support Enc Types 0 and 1 (NULL and AES-
CBC-12). 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.
Any packet that contains an Encrypted-Attribute Attribute MUST
Zorn, et al. Expires August 20, 2006 [Page 5]
Internet-Draft Encrypted Attributes February 2006
also include both a Crypto-Params Attribute (section 3.1) and a
Message-Authentication-Code Attribute [KEYWRAP].
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 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).
A subset of the attributes in a message can be authenticated and
integrity-protected by setting the Enc Type field in the Crypto-
Params Attribute (section 3.1) to NULL and concatenating an
instance of the Message-Authentication-Code Attribute [KEYWRAP] to
the set of attributes to be protected. When used in this way,
only the attributes to be protected are to be used as input in the
creation of the Message-Authentication-Code Attribute.
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...
Zorn, et al. Expires August 20, 2006 [Page 6]
Internet-Draft Encrypted Attributes February 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
[TBD2] for Encrypted-Attribute
Length
>3
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
Zorn, et al. Expires August 20, 2006 [Page 7]
Internet-Draft Encrypted Attributes February 2006
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.pdf>.
[KEYWRAP] Zorn, G., Zhang, T., Walker, J., and J. Salowey, "RADIUS
Attributes for Key Delivery",
draft-zorn-radius-keywrap-08.txt (work in progress),
September 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.
Zorn, et al. Expires August 20, 2006 [Page 8]
Internet-Draft Encrypted Attributes February 2006
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
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 20, 2006 [Page 9]
Internet-Draft Encrypted Attributes February 2006
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 (2006). 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 20, 2006 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 02:33:08 |