One document matched: draft-zorn-radius-keywrap-08.txt
Differences from draft-zorn-radius-keywrap-07.txt
Network Working Group G. Zorn
Internet-Draft Cisco Systems
Updates: 2865, 2866, 3576, 3579 T. Zhang
(if approved) 3e Technologies International
Expires: March 20, 2006 J. Walker
Intel Corporation
J. Salowey
Cisco Systems
September 16, 2005
RADIUS Attributes for Key Delivery
draft-zorn-radius-keywrap-08.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 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a set of RADIUS Attributes designed to allow
both the secure transmission of encryption keys and strong
authentication of any RADIUS message.
Zorn, et al. Expires March 20, 2006 [Page 1]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . 3
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Random-Nonce . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Message-Authentication-Code . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
5. Attribute Types . . . . . . . . . . . . . . . . . . . . . . 12
6. Attribute Values . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . 12
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1 Normative References . . . . . . . . . . . . . . . . . . 13
10.2 Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . 16
Zorn, et al. Expires March 20, 2006 [Page 2]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
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], the
Request and Response Authenticators (in the cases of RADIUS
Accounting [RFC2866] and Dynamic Authorization [RFC3576]) or the
Message-Authenticator Attribute [RFC3579]. However, there are
several issues with these techniques:
o The key transport attributes were designed for use with a
specific, proprietary protocol [RFC3078] and may be inappropriate
for other uses
o The security properties and strength of the encryption method used
to hide the keys are unknown
o The hash function ([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])
o The Message-Authenticator Attribute is unusable in some situations
where strong message authentication might be required
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. In addition, the Message-
Authentication-Code Attribute may be used to provide strong
authentication for any RADIUS 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. Attributes
The following subsections describe the Attributes defined by this
document. This specification concerns the following values:
Zorn, et al. Expires March 20, 2006 [Page 3]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
[TBD1] Key
[TBD2] Random-Nonce
[TBD3] Message-Authentication-Code
3.1 Key
Description
This Attribute MAY be used to carry an encryption key from a
RADIUS server to a client.
It MAY be sent in request messages (e.g., Access-Request, etc.),
as well; if the Key Attribute is present in a request, 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 a
request message the Key ID, Lifetime, IV and Key Data fields MAY
be omitted.
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.
Any packet that contains a Key Attribute MUST also include the
Message-Authentication-Code Attribute.
Any packet that contains an instance of the Key Attribute MUST NOT
contain an instance of any other key transport attribute (e.g.,
MS-CHAP-MPPE-Keys [RFC2548], Tunnel-Password [RFC2868], etc.)
encapsulating identical keying material.
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 March 20, 2006 [Page 4]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IV (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
[TBD1] for Key
Length
>= 3
Reserved
This field is reserved for future usage and MUST be zero-
filled.
Zorn, et al. Expires March 20, 2006 [Page 5]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
Enc Type
The Enc Type field indicates the method used to encrypt the key
that is carried in the Key Data field. This document defines
only one value (decimal) for this field:
0 AES Key Wrap with 128-bit KEK [RFC3394]
Implementations MUST support Enc Type 0 (AES Key Wrap with 128-
bit KEK); 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. This allows
for multiple keys for different purposes to be present in the
same message. This document defines two values for the App ID:
0 Unspecified
1 EAP MSK
Other values are to be assigned by IANA; 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. The KEK ID MUST refer to a encryption
key of a type and length appropriate for use with the algorithm
specified by the Enc Type field (see above). This key is used
to protect the contents of the Key Data field (below). 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. The Key ID MAY be used by
Zorn, et al. Expires March 20, 2006 [Page 6]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
communicating parties to identify the key that is being
transmitted. The combination of App ID and Key ID MUST
uniquely identify the key between the parties utilizing the
key. The Key ID is assumed to be known to the parties that
derived 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 keying material is
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 value of
the IV field MUST be as specified in [RFC3394].
Key Data
The Key Data field is variable length and contains the actual
encrypted keying material.
3.2 Random-Nonce
Description
The Random-Nonce Attribute MUST be present in any message that
includes an instance of the Message-Authentication-Code Attribute.
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.
A summary of the Random-Nonce attribute format is shown below.
The fields are transmitted from left to right.
Zorn, et al. Expires March 20, 2006 [Page 7]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
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 | Random...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
[TBD2] for Random-Nonce
Length
34
Random
This field MUST contain a 32 octet random number which SHOULD
satisfy the requirements of [RFC4086].
3.3 Message-Authentication-Code
Description
This Attribute MAY be used to "sign" 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.
The Message-Authentication-Code Attribute MUST be included in any
message that contains a Key attribute.
Any packet that contains an instance of the Message-
Authentication-Code Attribute SHOULD NOT contain an instance of
the Message-Authenticator Attribute [RFC3579]. If both attributes
are to be included in a message (e.g., for backward compatibility
in a network containing both old and new clients), the value of
the Message-Authentication-Code Attribute MUST be computed as
follows: when sending a message, the value of the Message-
Authentication-Code Attribute MUST be computed first and that
value used to compute the value of the Message-Authenticator
Attribute.
If any message is received containing an instance of the Message-
Authentication-Code Attribute, the receiver MUST calculate the
correct value of the Message-Authentication-Code and silently
Zorn, et al. Expires March 20, 2006 [Page 8]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
discard the packet if the computed value does not match the value
received.
If a received message contains an instance of the Random-Nonce
Attribute (Section 3.2), the received Random-Nonce Attribute
SHOULD be included in the computation of the Message-
Authentication-Code Attribute sent in the response, as described
below.
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 Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
[TBD3] for Message-Authentication-Code
Length
>3
Reserved
This field is reserved for future usage and MUST be zero-
filled.
MAC Type
The MAC Type field specifies the algorithm used to create the
value in the MAC field. This document defines six values for
Zorn, et al. Expires March 20, 2006 [Page 9]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
the MAC Type field:
0 HMAC-SHA-1 [FIPS.180-2.2002] [RFC2104]
1 HMAC-SHA-256 [FIPS.180-2.2002] [RFC2104]
2 HMAC-SHA-512 [FIPS.180-2.2002] [RFC2104]
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.
MAC Key ID
The MAC Key ID field is 16 octets in length and contains an
identifier for the key. The MAC Key ID MUST refer to a key of
a type and length appropriate for use with the algorithm
specified by the MAC Type field (see above). Further
specification of the content of this field is outside the scope
of this document.
MAC
Both the length and value of the MAC field depend upon the
algorithm specified by the value of the MAC Type field. 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. The derivation of the MAC field value for all the
algorithms specified in this document is identical, except for
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.
Request Messages
For requests (e.g., CoA-Request [RFC3576], Accounting-
Request [RFC2866], etc.), the value of the MAC field is a
hash of the entire packet except the Request Authenticator,
using a shared secret as the key, as follows.
Zorn, et al. Expires March 20, 2006 [Page 10]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
MAC = HASH-ALG(Type, Identifier, Length, Attributes)
The Random-Nonce Attribute (Section 3.2) MUST be included in
any request in which the Message-Authentication-Code
Attribute is used. The Random field of the Random-Nonce
Attribute MUST be filled in before the value of the MAC
field is computed.
If the Message-Authenticator-Code Attribute 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 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.
Response Messages
For responses (e.g., CoA-ACK [RFC3576], Accounting-Response
[RFC2866], etc.), the value of the MAC field is a hash of
the entire packet except the Response Authenticator using a
shared secret as the key, as follows.
MAC = HASH-ALG(Type, Identifier, Length, Attributes)
If the request contained an instance of the Random-Nonce
Attribute and the responder wishes to include an instance of
the Message-Authentication-Code Attribute in the
corresponding response, then the Random-Nonce Attribute from
the request MUST be included in the response.
If the Message-Authenticator-Code Attribute is included in a
server response, the client SHOULD ignore the contents of
the Response Authenticator.
Implementation Notes
When the hash is calculated, both the MAC field and the
String field of the Message-Authenticator Attribute (if
any) MUST be considered to be zero-filled.
Zorn, et al. Expires March 20, 2006 [Page 11]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
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].
5. Attribute Types
Upon publication of this document as an RFC, IANA must assign
numbers to the Key [TBD1], Random-Nonce [TBD2] and Message-
Authentication-Code [TBD3] Attributes.
6. 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.
As defined in Section 3.2, numbers may need to be assigned for future
values of the App Type field of the Message-Authentication-Code
attribute. These numbers may be assigned by applying the "First Come
First Served" policy.
7. Security Considerations
It is RECOMMENDED in this memo that two new keys be shared by the
RADIUS client and server. If implemented, 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
Zorn, et al. Expires March 20, 2006 [Page 12]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
[RFC2865], Request Authenticator [RFC2866] [RFC3576] and Message-
Authenticator Attribute [RFC3579]; otherwise if the shared secret is
broken, all is lost.
To avoid the possibility of collisions, the MAC key SHOULD NOT be
used with more than 2^64 messages.
If a packet that contains an instance of the Key Attribute also
contains an instance of another, weaker key transport attribute
(e.g., MS-MPPE-Recv-Key [RFC2548]) encapsulating identical keying
material, then breaking the weaker attribute might facilitate a
known-plaintext attack against the KEK.
8. Contributors
Hao Zhou, Nancy Cam-Winget, Paul Funk and John Fossaceca all
contributed to this document.
9. Acknowledgements
Thanks (in no particular order) to Keith McCloghrie, Kaushik Narayan,
Murtaza Chiba, Bill Burr, Russ Housley, David McGrew, Pat Calhoun and
Greg Weber for useful feedback.
10. References
10.1 Normative References
[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>.
[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>.
[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
Zorn, et al. Expires March 20, 2006 [Page 13]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
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.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, 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.
[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.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
10.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.
Zorn, et al. Expires March 20, 2006 [Page 14]
Internet-Draft RADIUS Attributes for Key Delivery September 2005
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
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 20, 2006 [Page 15]
Internet-Draft RADIUS Attributes for Key Delivery September 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 March 20, 2006 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 02:28:19 |