Network Working Group R. Housley
Internet Draft Vigil Security
June 2005 Bernard Aboba
Expires in six months Microsoft
AAA Key Management
<draft-housley-aaa-key-mgmt-00.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.
Abstract
This document provides guidance to designers of AAA key management
protocols. Given the complexity and difficulty in designing secure,
long-lasting key management algorithms and protocols by experts in
the field, it is almost certainly inappropriate for IETF working
groups without deep expertise in the area to be designing their own
key management algorithms and protocols based on Authentication,
Authorization and Accounting (AAA) protocols. The guidelines in this
document apply to documents requesting publication as RFCs, as well
as to use of AAA key management by any other standards development
organizations (SDOs).
Housley & Aboba [Page 1]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
Table of Contents
{{{ Fill in later. }}}
1. Introduction
This document provides architectural guidance to designers of AAA key
management protocols.
Given the complexity and difficulty in designing secure, long-lasting
key management algorithms and protocols by experts in the field, it
is almost certainly inappropriate for IETF working groups without
deep expertise in the area to be designing their own key management
algorithms and protocols based on Authentication, Authorization and
Accounting (AAA) protocols. These guidelines apply to documents
requesting publication as RFCs as well as to use of AAA key
management by any standards development organization (SDO) that
depend on IETF specifications for protocols such as EAP [RFC3748],
RADIUS [RFC2865] and Diameter [RFC3588].
In March 2003, at the IETF 56 AAA Working Group Session, Russ Housley
gave a presentation on "Key Management in AAA" [H]. That
presentation established the vast majority of the requirements
contained in this document.
1.1. Requirements Specification
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [RFC2119].
An AAA key management proposal is not compliant with this
specification if it fails to satisfy one or more of the MUST or MUST
NOT statements. An AAA key management proposal that satisfies all
the MUST, MUST NOT, SHOULD and SHOULD NOT statements is said to be
"unconditionally compliant"; one that satisfies all the MUST and MUST
NOT statements but not all the SHOULD or SHOULD NOT requirements is
said to be "conditionally compliant".
Housley & Aboba [Page 2]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
1.2. Terminology
This section defines terms that are used in this document.
AAA
Authentication, Authorization and Accounting (AAA). AAA
protocols include RADIUS [RFC2865] and Diameter [RFC3588].
Authenticator
The end of the link initiating EAP authentication. The term
authenticator is used in [IEEE-802.1X], and authenticator has
the same meaning in this document.
Backend authentication server
A backend authentication server is an entity that provides an
authentication service to an authenticator. This terminology
is also used in [802.1X].
CHAP
Challenge Handshake Authentication Protocol; a one-way
challenge/response authentication protocol defined in
[RFC1994].
EAP
Extensible Authentication Protocol, defined in [RFC3748].
EAP server
The entity that terminates the EAP authentication method with
the peer. In the case where no backend authentication server
is used, the EAP server is part of the authenticator. In the
case where the authenticator operates in pass-through mode, the
EAP server is located on the backend authentication server.
PAP
Password Authentication Protocol; a deprecated cleartext
password PPP authentication protocol, originally defined in
[RFC1334].
Housley & Aboba [Page 3]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
Party
A party is a processing entity which can be identified as a
single role in a protocol.
Peer
The end of the link that responds to the authenticator. In
[802.1X], this end is known as the supplicant.
PPP
Point-to-Point Protocol, defined in [RFC1661], provides support
for multiprotocol serial datalinks. PPP is the primary IP
datalink used for dial-in NAS connection service.
Secure Association Protocol
A protocol for managing security associations derived from EAP
and/or AAA exchanges. An example of a Secure Association
Protocols is the 4-way handshake defined within [802.11i].
Supplicant
The end of the link that responds to the authenticator in
[802.1X].
Network Access Server
A device which provides an access service for a user to a
network. The service may be a network connection, or a value
added service such as terminal emulation, as described in
[RFC2881].
4-Way Handshake
A pairwise Authentication and Key Management Protocol (AKMP)
defined in [802.11i], which confirms mutual possession of a
Pairwise Master Key by two parties and distributes a Group Key.
Housley & Aboba [Page 4]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
2. AAA Key Management History
Protocols for Authentication, Authorization and Accounting (AAA) were
originally developed to support deployments of Network Access Servers
(NASes) providing access to the Internet via PPP [RFC1661]. In
deployments supporting more than a modest number of users, it became
impractical for each NAS to contain its own list of users and
associated credentials. As a result, protocols for AAA were
developed, including TACACS [RFC1492], RADIUS [RFC2865] and Diameter
[RFC3588]. These protocols enabled a central AAA server to
authenticate users requesting network access, as well as providing
authorization and accounting.
While PPP [RFC1661] originally supported only PAP [RFC1334] and CHAP
[RFC1661] authentication, the limitations of these authentication
mechanisms became apparent. For example, both PAP and CHAP are
unilateral authentication schemes supporting only authentication of
the PPP peer to the NAS. Since PAP is a cleartext password scheme,
it is vulnerable to snooping by an attacker with access to the
conversation between the PPP peer and NAS. In addition, the use of
PAP creates vulnerabilities within RADIUS as described in Section 4.3
of [RFC3579]. As a result, use of PAP is deprecated. While CHAP, a
challenge-response scheme based on MD5, offers better security than
cleartext passwords, it does not provide for mutual authentication,
and CHAP is vulnerable to dictionary attack.
With the addition of the Encryption Control Protocol (ECP) to PPP
[RFC1968] as well as the definition of PPP ciphersuites in [RFC2419]
[RFC2420][RFC3078] the need arose to provide keying material for use
with link layer ciphersuites. As with user authentication,
provisioning of static keys on each NAS did not scale well.
Additional vendor-specific PPP authentication protocols such as MS-
CHAP [RFC2433] and MS-CHAPv2 [RFC2759] were developed to provide
mutual authentication as well as key derivation [RFC3079] for use
with negotiated ciphersuites, and they were subsequently adapted for
use with PPP-based VPNs [RFC2637]. As with PAP and CHAP, flaws were
subsequently found in these new mechanisms [SM1][SM2].
Even though PPP provided for negotiation of authentication
algorithms, addressing the vulnerabilities found in authentication
mechanisms still proved painful, since new code needed to be deployed
on PPP peers as well as on the AAA server. In order to enable more
rapid deployment of new authentication mechanisms, as well as fixes
for vulnerabilities found in existing methods, the Extensible
Authentication Protocol (EAP) [RFC3748] was developed, along with
support for centralized authentication via RADIUS/EAP [RFC3579].
Housley & Aboba [Page 5]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
By enabling "pass through" authentication on the NAS, EAP enabled
deployment of new authentication methods or updates to existing
methods by revising code only on the EAP peer and AAA server. The
initial authentication mechanisms defined in [RFC2284]
(MD5-Challenge, One-Time Password (OTP), and Generic Token Card
(GTC)) only supported unilateral authentication, and these mechanisms
do not support key derivation. Subsequent authentication methods
such as EAP-TLS [RFC2716] supported mutual authentication and key
derivation.
In order to support the provisioning of dynamic keying material for
link layer ciphersuites in an environment supporting centralized
authentication, a mechanism was needed for the transport of keying
material between the AAA server and NAS. Vendor-specific RADIUS
attributes were developed for this purpose [RFC2548].
Vulnerabilities were subsequently found in the key wrap technique, as
described in Section 4.3 of [RFC3579].
In theory, public key authentication mechanisms such as EAP-TLS are
capable of supporting mutual authentication and key derivation
between the EAP peer and NAS without requiring AAA key distribution,
as described in [A]. However, in practice such pure two-party
schemes are rarely deployed. Operation of a centralized AAA server
significantly reduces the effort required to deploy certificates to
NASes, and even though a AAA server may not be required for key
derivation and possibly authentication, its participation is required
for service authorization and accounting.
"Pass-through" authentication and AAA key distribution has retained
popularity even in the face of rapid improvements in processor and
memory capabilities. In addition to producing NAS devices of
increased capability for enterprise and carrier customers,
implementers have also produced low cost/high volume NAS devices such
as 802.11 Access Points, causing the resources available on an
average NAS to increase more slowly than Moore's law. Despite
widespread support for certificate handling and sophisticated key
derivation mechanisms such as IKEv1 [RFC2409] within host operating
systems, these security capabilities are rarely deployed on low-end
NASes and clients.
Even on more capable NASes, such as VPN servers, centralized
authentication and AAA key management has proven popular. For
example, one of the major limitations of IKEv1 [RFC2409] was the lack
of integration with EAP and AAA, requiring proprietary extensions to
enable use of IPsec VPNs by organizations deploying password or
authentication tokens. These limitations were addressed in IKEv2
[RFCxxxx], which while handling key derivation solely between the VPN
client and server, supports EAP methods for user authentication. In
Housley & Aboba [Page 6]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
order to enable cryptographic binding of EAP user authentication to
keys derived within the IKEv2 exchange, the transport of EAP-derived
keys within AAA is required where the selected EAP method supports
key derivation.
3. AAA Environment Concerns
EAP is being used in new ways. The inclusion of support for EAP
within IKEv2 and the standardization of robust Wireless LAN security
[802.11i] based on EAP are two examples. EAP has also been proposed
within IEEE 802.16e [802.16e]. AAA-based key management is being
incorporated into standards developed by the IETF and other standards
development organizations (SDOs), such as IEEE 802. However, due to
ad hoc development of AAA-based key management, AAA-based key
distribution schemes have poorly understood security properties, even
when well- studied cryptographic algorithms are employed. More
academic research is needed to fully understand the security
properties of AAA-based key management in the diverse protocol
environments where it is being employed today. In the absence of
research results, pragmatic guidance based on sound security
engineering principles is needed.
EAP selects one end-to-end authentication mechanism. The mechanisms
defined in [RFC3748] only support unilateral authentication, and they
do not support mutual authentication or key derivation. As a result,
these mechanisms do not fulfill the security requirements for many
deployment scenarios, including Wireless LAN authentication
[RFC4017].
To ensure adequate security and interoperability, EAP applications
need to specify mandatory-to-implement algorithms. As described in
[RFC3748], EAP methods seeking publication as an RFC need to document
their security claims; however, since the authentication algorithms
are not based on well-studied models, the validity of these security
claims may be very difficult to determine.
In addition to the need for interoperability, cryptographic algorithm
independent solutions are greatly preferable. Without algorithm
independence, the protocol must be changed whenever a problem is
discovered with the selected algorithm. As the AAA history shows,
problems are inevitable. Problems can surface due to age or design
failure.
DES [FIPS46] was a well designed encryption algorithm, and it
provided protection for many years. Yet, the 56-bit key size was
eventually overcome by Moore's Law. No cryptographic deficiencies
have been discovered in DES.
Housley & Aboba [Page 7]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
Examples of serious flaws plague the history of key management
protocol development, starting with the very first attempt to define
a key management protocol in the open literature, which was published
in 1978 [NS]. A flaw and a fix were published in 1981 [DS], and the
fix was broken in 1994 [AN]. In 1995 [L], a new flaw was found in
the original 1978 version, in an area not affected by the 1981/1994
issue. All of these flaws were blindingly obvious once described,
yet no one spotted them earlier. Note that the original protocol, if
it were revised to employ certificates, which of course had yet to be
invented, was only three messages. Many proposed AAA key management
schemes are significantly more complicated.
This bit of history shows that key management protocols are subtle.
Experts can easily miss a flaw. As a result, peer review by multiple
experts is essential.
The history of AAA underlines the importance of algorithm
independence as flaws have been found in authentication mechanisms
such as CHAP, MS-CHAPv1 [SM1], MS-CHAPv2 [SM2], Kerberos
[W][BM][DLS], and LEAP [B]. Unfortunately, RADIUS [RFC2865] mandates
use of the MD5 algorithm for integrity protection, which has known
deficiencies, and RADIUS has no provisions to negotiate substitute
algorithms. Similarly, the vendor-specific key wrap mechanism
defined in [RFC2548] has no provisions to negotiate substitute
algorithms.
The principle of least privilege is an important design guideline.
AAA key management schemes need to be designed in a manner where each
party has only the privileges necessary to perform their role. That
is, no party should have access to any keying material that is not
needed to perform their own role. A party has access to a particular
key if it has access to all of the secret information needed to
derive it.
In the context of EAP, the EAP peer and server are the parties
involved in the EAP method conversation, and they gain access to key
material when the conversation completes successfully. However, the
lower layer needs keying material to be provided to the peer and
authenticator. As a result, a "pass-through" mode is used to provide
the keying material, and the lower layer keying material is
replicated from the AAA server to the authenticator. The only
parties authorized to obtain all of the keying material are the EAP
peer and server; the authenticator obtains only the keying material
necessary for its specific role. No other party can obtain access to
any of the keying material.
Housley & Aboba [Page 8]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
4. AAA Key Management Requirements
This section provides guidance to AAA protocol designers and EAP
method designers. Acceptable solutions MUST meet all of these
requirements.
Cryptographic algorithm independent
The AAA key management protocol MUST be cryptographic algorithm
independent. However, an EAP method MAY depend on a specific
cryptographic algorithm. The ability to negotiate the use of a
particular cryptographic algorithm provides resilience against
compromise of a particular cryptographic algorithm. The AAA
protocol MUST be algorithm independent, both in terms of its
own security mechanisms as well as mechanisms supported for
user authentication. Algorithm independence is also REQUIRED
with a Secure Association Protocol if one is defined. This is
usually accomplished by including an algorithm identifier in
the protocol, and by specifying the algorithm requirements in
the protocol specification. For interoperability, at least one
suite of mandatory-to-implement algorithms MUST be selected.
Note that without protection by IPsec as described in [RFC3579]
Section 4.2, RADIUS [RFC2865] does not meet this requirement,
since the integrity protection algorithm can not be negotiated.
This requirement does not mean that a protocol must support
both public-key and symmetric-key cryptographic algorithms. It
means that the protocol needs to be structured in such a way
that multiple public-key algorithms can be used whenever a
public-key algorithm is employed. Likewise, it means that the
protocol needs to be structured in such a way that multiple
symmetric-key algorithms can be used whenever a symmetric-key
algorithm is employed.
Strong, fresh session keys
While preserving algorithm independence, session keys MUST be
strong and fresh. Each session deserves an independent session
key. Fresh keys are required even when a long replay counter
(that is, one that "will never wrap") is used to ensure that
loss of state does not cause the same counter value to be used
more than once with the same session key.
Some EAP methods are capable of deriving keys of varying
strength, and these EAP methods MUST permit the generation of
keys meeting a minimum equivalent key strength as defined in
[RFC3766].
Housley & Aboba [Page 9]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
A fresh cryptographic key is one that is generated specifically
for the intended use. In this situation, a post-EAP handshake
is used to establish session keys. Thus, the AAA protocol and
EAP method MUST ensure that the keying material supplied as an
input to session key derivation is fresh, and the post-EAP
handshake MUST generate a separate session key for each
session, even if the keying material provided by EAP is cached.
Further, the keys MUST NOT be dependent on one another. That
is, disclosure of one session key does not aid the attacker in
discovering any other session keys.
Limit key scope
Follow the principle of least privilege. Parties MUST NOT have
access to keying material that is not needed to perform their
own role. A party has access to a particular key if it has
access to all of the secret information needed to derive it.
A post-EAP handshake is used to establish session keys, and the
post-EAP handshake MUST specify the scope for session keys.
Replay detection mechanism
The AAA key management protocol exchanges MUST MUST be replay
protected, including AAA, EAP and Secure Association Protocol
exchanges. Replay protection allows a protocol message
recipient to discard any message that was recorded during a
previous legitimate dialogue and presented as though it
belonged to the current dialogue.
Authenticate all parties
Each party in the AAA key management protocol MUST be
authenticated to the other parties with whom it communicates.
Authentication mechanisms MUST maintain the confidentiality of
any secret values used in the authentication process.
A post-EAP handshake is used to establish session keys, and the
parties involved in the post-EAP handshake MUST identify
themselves using identities that are meaninful in the lower
layer protocol environment that will employ the session keys.
Authentication mechanisms MUST NOT employ plaintext passwords.
Peer and authenticator authorization
Peer and authenticator authorization MUST be performed.
Authorization is REQUIRED whenever a peer associates with a new
Housley & Aboba [Page 10]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
authenticator. The authorization checking prevents an
elevation of privilege attack, and it ensures that an
unauthorized authenticator is detected.
Authorizations SHOULD be synchronized between the EAP peer,
server, authenticator. Once the AAA key management protocol
exchanges are complete, all of these parties should hold view
of the authorizations associated the other parties.
Keying material confidentiality
While preserving algorithm independence, confidentiality of all
keying material MUST be maintained.
Confirm ciphersuite selection
The selection of the "best" ciphersuite MUST be securely
confirmed. The mechanism MUST detect attempted roll back
attacks.
Uniquely name keys
AAA key management proposals require a robust key naming
scheme, particularly where key caching is supported. Objects
that cannot be named cannot be managed. All keys MUST be
uniquely named, and the key name MUST NOT be based on the
keying material itself.
Prevent the Domino effect
Compromise of a single authenticator MUST NOT compromise any
other part of the system, especially session keys and long-term
keys. There are many implications of this requirement;
however, two implication deserves highlighting. First, an
authenticator MUST NOT share any keying material with another
authenticator. Second, the scope of the authenticator needs to
be defined and understood by all parties that communicate with
it.
Housley & Aboba [Page 11]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
Bind key to its context
Keying material MUST be bound to the appropriate context, which
includes:
o The manner in which the keying material is expected to
be used;
o The other parties that are expected to have access to
the keying material; and
o The expected lifetime of the keying material.
Any party with legitimate access to keying material can
determine its context. In addition, the protocol MUST ensure
that all parties with legitimate access to keying material have
the same context for the keying material. This requires that
the parties are properly identified and authenticated, so that
all of the parties that have access to the keying material can
be determined.
The context will include the EAP peer and authenticator
identities in more than one form. One (or more) name form is
needed to identify these parties in the AAA protocol and EAP
menthod. Another name form is needed to identify these parties
within lower layer that will employ the session key.
5. AAA Key Management Recommendations
Acceptable solutions SHOULD meet all of these requirements.
Confidentiality of Identity
In many environments it is important to provide confidentiality
protection for identities. However, this is not important in
other environments. For this reason, EAP methods SHOULD
provide a mechanism for identity protection of EAP peers, but
such protection is not a requirement.
Housley & Aboba [Page 12]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
Authorization restriction
If peer authorization is restricted, then the peer SHOULD be
made aware of the restriction. Otherwise, the peer may
inadvertently attempt to circumvent the restriction.
Authorization restrictions include:
o Key lifetimes, where the keying material can only be used
for a certain period of time;
o SSID restrictions, where the keying material can only be
used with a specific IEEE 802.11 SSID;
o Called-Station-ID restrictions, where the keying material
can only be used with a single IEEE 802.11 BSSID; and
o Calling-Staton-ID restrictions, where the keying material
can only be used with a single peer IEEE 802 MAC address.
6. Security Considerations
{{{ To be provided. }}}
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.
8. Informative References
[802.1X] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2004,
December 2004.
[802.11i] Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and
Information Exchange Between Systems -- LAN/MAN Specific
Requirements - Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications:
Specification for Enhanced Security", IEEE 802.11i, July
2004.
Housley & Aboba [Page 13]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
[802.16e] Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and
Information Exchange Between Systems -- LAN/MAN Specific
Requirements - Part 16: Air Interface for Fixed and
Mobile Broadband Wireless Access Systems -- Amendment for
Physical and Medium Access Control Layers for Combined
Fixed and Mobile Operation in Licensed Bands", Draft,
IEEE 802.16e/D8, May 2005.
[A] Aboba, B., "Certificate-Based Roaming", Internet-Draft,
draft-ietf-roamops-cert-02 (work in progress), April
1999.
[AN] M. Abadi and R. Needham, "Prudent Engineering Practice
for Cryptographic Protocols", Proc. IEEE Computer Society
Symposium on Research in Security and Privacy, May 1994.
[B] Brewin, B., "LEAP attack tool author says he wants to
alert users to risks", Computerworld, October 17, 2003.
[BM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos
authentication system", Proceedings of the 1991 Winter
USENIX Conference, pp. 253-267, 1991.
[DLS] Dole, B., Lodin, S. and E. Spafford, "Misplaced trust:
Kerberos 4 session keys", Proceedings of the Internet
Society Network and Distributed System Security
Symposium, pp. 60-70, March 1997.
[DS] D. Denning and G. Sacco. "Timestamps in key distributed
protocols", Communication of the ACM, 24(8):533--535,
1981.
[FIPS46] Federal Information Processing Standards Publication
(FIPS PUB) 46, Data Encryption Standard, 1977 January 15.
[H] Housley, R., "Key Management in AAA", Presentation to the
AAA WG at IETF 56, March 2003,
http://www.ietf.org/proceedings/03mar/slides/aaa-5/
index.html.
[L] G. Lowe. "An attack on the Needham-Schroeder public key
authentication protocol", Information Processing Letters,
56(3):131--136, November 1995.
[NS] R. Needham and M. Schroeder. "Using encryption for
authentication in large networks of computers",
Communications of the ACM, 21(12), December 1978.
Housley & Aboba [Page 14]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
[RFC1334] Lloyd, B. and B. Simpson, "PPP Authentication Protocols"
RFC 1334, October 1992, Obsoleted by RFC 1994.
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes
Called TACACS", RFC 1492, July 1993.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC
1661, July 1994.
[RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968,
June 1996.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption
Protocol, Version 2 (DESE-bis)", RFC 2419, September
1998.
[RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol
(3DESE)", RFC 2420, September 1998.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W. and G. Zorn, "Point-to-Point Tunneling Protocol
(PPTP)", RFC 2637, July 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC
2759, January 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2881] D. Mitton, M. Beadles, "Network Access Server
Requirements Next Generation (NASREQNG) NAS Model", RFC
2881, July 2000.
Housley & Aboba [Page 15]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point
Encryption (MPPE) Protocol", RFC 3078, March 2001.
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-
Point Encryption (MPPE)", RFC 3079, March 2001.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September
2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strength for
Public Keys Used For Exchanging Symmetric Keys", RFC
3766, April 2004.
[RFC4017] Stanley, D., Walker, J. and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFCxxxx] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Internet-Draft, draft-ietf-ipsec-ikev2-17 (work in
progress; in RFC Editor queue), September 2004.
[SM1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's
Point-to-Point Tunneling Protocol", Proceedings of the
5th ACM Conference on Communications and Computer
Security, ACM Press, November 1998.
[SM2] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's
PPTP Authentication Extensions (MS-CHAPv2)", CQRE 99,
Springer-Verlag, 1999, pp. 192-203.
[W] Wu, T., "A Real-World Analysis of Kerberos Password
Security", Proceedings of the 1999 ISOC Network and
Distributed System Security Symposium,
http://www.isoc.org/isoc/conferences/ndss/99/
proceedings/papers/wu.pdf.
Housley & Aboba [Page 16]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
Acknowledgments
Many thanks to James Kempf for his quality review and encouragement.
Authors' Address
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
Email: housley@vigilsec.com
Phone: +1 703-435-1775
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Intellectual Property Statement
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
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.
Housley & Aboba [Page 17]
Internet Draft draft-housley-aaa-key-mgmt-00.txt June 2005
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.
Housley & Aboba [Page 18]
