draft-ietf-radext-crypto-agility-requirements-04.txt   draft-ietf-radext-crypto-agility-requirements-05.txt 
RADEXT Working Group D. Nelson (Editor) RADEXT Working Group D. Nelson (Editor)
INTERNET-DRAFT Elbrys Networks, Inc. INTERNET-DRAFT Elbrys Networks, Inc.
Category: Informational Category: Informational
Expires: September 12, 2011 Expires: October 16, 2011
12 March 2011 16 April 2011
Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)
draft-ietf-radext-crypto-agility-requirements-04.txt draft-ietf-radext-crypto-agility-requirements-05.txt
Abstract Abstract
This memo describes the requirements for a crypto-agility solution This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS). for Remote Authentication Dial-In User Service (RADIUS).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 12, 2011. This Internet-Draft will expire on October 16, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Requirements Language . . . . . . . . . . . . . . . . . . . 3 1.2 Requirements Language . . . . . . . . . . . . . . . . . . . 3
1.3. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Publication Process . . . . . . . . . . . . . . . . . . . . 4
2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 4 2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 4
3. The Current State of RADIUS Security . . . . . . . . . . . . . 5 3. The Current State of RADIUS Security . . . . . . . . . . . . . 5
4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 5 4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 6
4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 6 4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 6
4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 7 4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 8
4.4. Interoperability and Change Control . . . . . . . . . . . . 8 4.4. Interoperability and Change Control . . . . . . . . . . . . 9
4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Applicability of Automated Key Management Requirements . . 8 4.6. Applicability of Automated Key Management Requirements . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10
8. Informative References . . . . . . . . . . . . . . . . . . . 10 8. Informative References . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
1.1. General 1.1. General
This memo describes the requirements for a crypto-agility solution This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS). This memo, for Remote Authentication Dial-In User Service (RADIUS). This memo,
when approved, reflects the consensus of the RADIUS Extensions when approved, reflects the consensus of the RADIUS Extensions
Working Group of the IETF (RADEXT) as to the features, properties and (RADEXT) Working Group of the IETF as to the features, properties and
limitations of the crypto-agility work item for RADIUS. It also limitations of the crypto-agility work item for RADIUS. It also
defines the term "crypto-agility" as used in this context, and defines the term "crypto-agility" as used in this context, and
provides the motivations for undertaking and completing this work. provides the motivations for undertaking and completing this work.
The requirements defined in this memo have been developed based on e- The requirements defined in this memo have been developed based on e-
mail messages posted to the RADEXT WG mailing list, which may be mail messages posted to the RADEXT WG mailing list, which may be
found in the archives of that list. The purpose of framing the found in the archives of that list. The purpose of framing the
requirements in this memo is to formalize and memorialize them for requirements in this memo is to formalize and memorialize them for
future reference, and to bring them explicitly to the attention of future reference, and to bring them explicitly to the attention of
the IESG and the IETF Community, as we proceed with this work. the IESG and the IETF Community, as we proceed with this work.
skipping to change at page 3, line 48 skipping to change at page 3, line 48
1.3. The Charge 1.3. The Charge
At the IETF-66 meeting, the RADEXT WG was asked by members of the At the IETF-66 meeting, the RADEXT WG was asked by members of the
Security Area Directorate to undertake the action item to prepare a Security Area Directorate to undertake the action item to prepare a
formal description of a crypto-agility work item, and corresponding formal description of a crypto-agility work item, and corresponding
milestones in the RADEXT Charter. After consultation with one of the milestones in the RADEXT Charter. After consultation with one of the
Security Area Directors, Russ Housley, text was initially proposed on Security Area Directors, Russ Housley, text was initially proposed on
the RADEXT WG mailing list on October 26, 2006. That text reads as the RADEXT WG mailing list on October 26, 2006. That text reads as
follows: follows:
The RADEXT WG will review the security requirements for crypto- The RADEXT WG will review the security requirements for crypto-
agility in IETF protocols, and identify the deficiencies of the agility in IETF protocols, and identify the deficiencies of the
existing RADIUS protocol specifications against these requirements. existing RADIUS protocol specifications against these
Specific attention will be paid to RFC 4962 [RFC4962]. requirements. Specific attention will be paid to RFC 4962
[RFC4962].
The RADEXT WG will propose one or more specifications to remediate The RADEXT WG will propose one or more specifications to remediate
any identified deficiencies in the crypto-agility properties of the any identified deficiencies in the crypto-agility properties of
RADIUS protocol. The known deficiencies include the issue of the RADIUS protocol. The known deficiencies include the issue of
negotiation of substitute algorithms for the message digest negotiation of substitute algorithms for the message digest
functions, the key-wrap functions, and the password-hiding function. functions, the key-wrap functions, and the password-hiding
Additionally, at least one mandatory to implement cryptographic function. Additionally, at least one mandatory to implement
algorithm will be defined in each of these areas, as required. cryptographic algorithm will be defined in each of these areas, as
required.
1.4. Publication Process
RADIUS [RFC2865] is a widely deployed protocol that has attained
Draft Standard status based on multiple independent interoperable
implementations. It is therefore highly desirable that a high level
of interoperability and security be maintained for crypto-agility
solutions.
To ensure that crypto-agility solutions published on the standards
track are well specified, secure and interoperable, the RADEXT WG has
adopted a two phase process for publication of crypto-agility
solutions.
In the initial phase, crypto-agility solutions adopted by the working
group will be published on the Experimental Track. Experimental
Track documents should contain a description of experimental
deployments and implementations in progress, as well as an evaluation
of the proposal against the requirements described in this document.
Based on the proposal evaluations, implementation and deployment
experience, and the results of interoperability tests, initial
proposals will be evaluated for publication on the standards track.
2. A Working Definition of Crypto-Agility 2. A Working Definition of Crypto-Agility
A generalized definition of crypto-agility was offered up at the A generalized definition of crypto-agility was offered up at the
RADEXT WG session during IETF-68. Crypto-Agility is the ability of a RADEXT WG session during IETF-68. Crypto-Agility is the ability of a
protocol to adapt to evolving cryptography and security requirements. protocol to adapt to evolving cryptography and security requirements.
This may include the provision of a modular mechanism to allow This may include the provision of a modular mechanism to allow
cryptographic algorithms to be updated without substantial disruption cryptographic algorithms to be updated without substantial disruption
to fielded implementations. It may provide for the dynamic to fielded implementations. It may provide for the dynamic
negotiation and installation of cryptographic algorithms within negotiation and installation of cryptographic algorithms within
skipping to change at page 5, line 27 skipping to change at page 5, line 51
authenticate and integrity protect RADIUS packets. authenticate and integrity protect RADIUS packets.
While RADIUS does not support confidentiality of entire packets, While RADIUS does not support confidentiality of entire packets,
various RADIUS attributes support encrypted (also known as "hidden") various RADIUS attributes support encrypted (also known as "hidden")
values, including: User-Password (defined in [RFC2865] Section 5.2), values, including: User-Password (defined in [RFC2865] Section 5.2),
Tunnel-Password (defined in [RFC2868] Section 3.5), and various Tunnel-Password (defined in [RFC2868] Section 3.5), and various
Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE- Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE-
Recv-Key attributes (defined in [RFC2548] Section 2.4). Generally Recv-Key attributes (defined in [RFC2548] Section 2.4). Generally
speaking, the hiding mechanism uses a stream cipher based on a key speaking, the hiding mechanism uses a stream cipher based on a key
stream from an MD5 digest. Attacks against this mechanism are stream from an MD5 digest. Attacks against this mechanism are
described in [RFC3579] Section 4.3.4. described in "RADIUS Support for EAP" [RFC3579] Section 4.3.4.
"Updated Security Considerations for the MD5 Message-Digest and the "Updated Security Considerations for the MD5 Message-Digest and the
HMAC-MD5 Algorithms" [RFC6151] discusses security considerations for HMAC-MD5 Algorithms" [RFC6151] discusses security considerations for
use of the MD5 and HMAC-MD5 algorithms. While the advances in MD5 use of the MD5 and HMAC-MD5 algorithms. While the advances in MD5
collisions do not immediately compromise the use of MD5 or HMAC-MD5 collisions do not immediately compromise the use of MD5 or HMAC-MD5
for the purposes used within RADIUS Eabsent knowledge of the RADIUS for the purposes used within RADIUS absent knowledge of the RADIUS
shared secret, the progress toward compromise of MD5's basic shared secret, the progress toward compromise of MD5's basic
cryptographic assumptions has resulted in the deprecation of MD5 cryptographic assumptions has resulted in the deprecation of MD5
usage in a variety of applications. As noted in [RFC6151] Section 2: usage in a variety of applications. As noted in [RFC6151] Section 2:
MD5 is no longer acceptable where collision resistance is required MD5 is no longer acceptable where collision resistance is required
such as digital signatures. It is not urgent to stop using MD5 in such as digital signatures. It is not urgent to stop using MD5 in
other ways, such as HMAC-MD5; however, since MD5 must not be used other ways, such as HMAC-MD5; however, since MD5 must not be used
for digital signatures, new protocol designs should not employ for digital signatures, new protocol designs should not employ
HMAC-MD5. HMAC-MD5.
4. The Requirements 4. The Requirements
4.1. Overall Solution Approach 4.1. Overall Solution Approach
RADIUS crypto-agility solutions are not restricted to utilizing RADIUS crypto-agility solutions are not restricted to utilizing
technology described in existing RFCs. Since RADIUS over IPsec is technology described in existing RFCs. Since RADIUS over IPsec is
already described in [RFC3162] Section 5 and [RFC3579] Section 4.2, already described in "RADIUS and IPv6" [RFC3162] Section 5 and
this technique is already available to those who wish to use it. [RFC3579] Section 4.2, this technique is already available to those
who wish to use it. Therefore, it is expected that proposals will
Therefore, it is expected that proposals will utilize other utilize other techniques.
techniques.
4.2. Security Services 4.2. Security Services
Proposals MUST support the negotiation of cryptographic algorithms Proposals MUST support the negotiation of cryptographic algorithms
for per-packet integrity/authentication protection. It is for per-packet integrity/authentication protection. Proposals also
RECOMMENDED that solutions provide support for confidentiality, MUST support per-packet replay protection for all RADIUS message
either by supporting encryption of entire RADIUS packets or by types. Crypto-agility solutions MUST specify mandatory-to-implement
encrypting individual RADIUS attributes. This includes providing cryptographic algorithms for each defined mechanism.
support for improving the confidentiality of existing encrypted
(sometimes referred to as "hidden") attributes as well as encrypting
attributes (such as location attributes) that are currently
transmitted in cleartext. Proposals supporting confidentiality MUST
support the negotiation of cryptographic algorithms for encryption.
Proposals MUST support per-packet replay protection for all RADIUS
message types.
Crypto-agility solutions MUST avoid security compromise, even in Crypto-agility solutions MUST avoid security compromise, even in
situations where the existing cryptographic algorithms utilized by situations where the existing cryptographic algorithms utilized by
RADIUS implementations are shown to be weak enough to provide little RADIUS implementations are shown to be weak enough to provide little
or no security (e.g. in event of compromise of the legacy RADIUS or no security (e.g. in event of compromise of the legacy RADIUS
shared secret). Included in this would be protection against bidding shared secret). Included in this would be protection against bidding
down attacks. In analyzing the resilience of a crypto-agility down attacks. In analyzing the resilience of a crypto-agility
solution, it can be assumed that RADIUS requesters and responders can solution, it can be assumed that RADIUS requesters and responders can
be configured to require the use of new secure algorithms in the be configured to require the use of new secure algorithms in the
event of a compromise of existing cryptographic algorithms or the event of a compromise of existing cryptographic algorithms or the
legacy RADIUS shared secret. legacy RADIUS shared secret.
Crypto-agility solutions MUST specify mandatory-to-implement Guidance on acceptable algorithms can be found in [NIST-SP800-131A];
cryptographic algorithms for each defined mechanism. Guidance on it is RECOMMENDED that mandatory-to-implement cryptographic
acceptable algorithms can be found in [NIST-SP800-131A]. In algorithms be chosen from among those classified as "Acceptable" with
particular, it is RECOMMENDED that mandatory-to-implement no known deprecation date.
cryptographic algorithms be chosen from among those classified as
"Acceptable" with no known deprecation date within [NIST-SP800-131A]. It is RECOMMENDED that solutions provide support for confidentiality,
either by supporting encryption of entire RADIUS packets or by
encrypting individual RADIUS attributes. Proposals supporting
confidentiality MUST support the negotiation of cryptographic
algorithms for encryption.
Solutions providing for encryption of entire RADIUS packets need not
also provide support for encryption of individual RADIUS attributes.
Solutions providing for encryption of individual RADIUS attributes
are REQUIRED to provide support for improving the confidentiality of
existing encrypted (sometimes referred to as "hidden") attributes as
well as encrypting attributes (such as location attributes) that are
currently transmitted in cleartext.
In addition to the goals referred to above, [RFC4962] Section 2 In addition to the goals referred to above, [RFC4962] Section 2
describes additional security requirements, which translate into the describes additional security requirements, which translate into the
following requirements for RADIUS crypto-agility solutions: following requirements for RADIUS crypto-agility solutions:
Strong, fresh session keys Strong, fresh session keys
RADIUS crypto-agility solutions are REQUIRED to generate fresh RADIUS crypto-agility solutions are REQUIRED to generate fresh
session keys for use between the RADIUS client and server. In session keys for use between the RADIUS client and server. In
order to prevent the disclosure of one session key from aiding an order to prevent the disclosure of one session key from aiding an
attacker in discovering other session keys, RADIUS crypto-agility attacker in discovering other session keys, RADIUS crypto-agility
solutions are RECOMMENDED to support Perfect Forward Secrecy (PFS) solutions are RECOMMENDED to support Perfect Forward Secrecy (PFS)
with respect to session keys negotiated between the RADIUS client with respect to session keys negotiated between the RADIUS client
and server. and server.
Limit key scope Limit key scope
In order to enable a NAS and RADIUS server to transmit keying It is RECOMMENDED that solutions enable a NAS and RADIUS server to
material directly, it is RECOMMENDED that a RADIUS crypto-agility exchange confidential information such as keying material without
solution be compatible with NAI-based Dynamic Peer Discovery disclosure to third parties. In order to accomplish this, it is
[RADYN] as well as that it support the use of public key RECOMMENDED that a RADIUS crypto-agility solution be compatible
credentials for authentication between the NAS and RADIUS server. with NAI-based Dynamic Peer Discovery [RADYN] as well as that it
support the use of public key credentials for authentication
between the NAS and RADIUS server.
For compatibility with existing operations, RADIUS crypto-agility For compatibility with existing operations, RADIUS crypto-agility
solutions SHOULD also support pre-shared key credentials. solutions SHOULD also support pre-shared key credentials. However,
support for end-to-end confidentiality of attributes or direct
communications between the NAS and RADIUS server is not required
when pre-shared key credentials are used.
Prevent the Domino effect Prevent the Domino effect
In order to prevent the domino effect, RADIUS crypto-agility In order to prevent the domino effect, RADIUS crypto-agility
solutions MUST enable each RADIUS client and server pair to solutions MUST enable each RADIUS client and server pair to
authenticate utilizing unique credentials. authenticate utilizing unique credentials.
4.3. Backwards Compatibility 4.3. Backwards Compatibility
Solutions to the problem MUST demonstrate backward compatibility with Solutions to the problem MUST demonstrate backward compatibility with
existing RADIUS implementations. That is, an implementation that existing RADIUS implementations. That is, an implementation that
skipping to change at page 7, line 36 skipping to change at page 8, line 21
legacy mechanisms). legacy mechanisms).
While backward compatibility is needed to ease the transition between While backward compatibility is needed to ease the transition between
legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is
only appropriate prior to the compromise of those mechanisms. After only appropriate prior to the compromise of those mechanisms. After
legacy mechanisms have been compromised, secure algorithms MUST be legacy mechanisms have been compromised, secure algorithms MUST be
used, so that backward compatibility is no longer possible. used, so that backward compatibility is no longer possible.
In order to enable a request to be handled both by legacy as well as In order to enable a request to be handled both by legacy as well as
crypto-agile implementations, a request can be secured with legacy crypto-agile implementations, a request can be secured with legacy
algorithms as well as more secure algorithms. While this approach algorithms and in addition attributes providing security services
permits the initial use of legacy algorithms between crypto-agile using more secure algorithms can be included. This approach allows a
implementations, if the responder indicates support for crypto- RADIUS packet to be processed by legacy implementations as well as by
agility, future requests can omit use of legacy algorithms, instead crypto-agile implementations, and does not result in additional
utilizing mechanisms indicated in the response. response delays.
This approach minimizes the response delay from both legacy and In this approach to backward compatibility, legacy mechanisms are
crypto-agile implementations. However, it is viable only where initially used between crypto-agile implementations. However, if the
legacy hidden attributes (e.g. User-Password) are not included within responder indicates support for crypto-agility, future requests can
requests. omit use of legacy mechanisms.
Probing techniques can avoid the use of legacy algorithms between Probing techniques can be used avoid the use of legacy algorithms
crypto-agile implementations. An initial request can omit use of between crypto-agile implementations. An initial request can omit
legacy mechanisms, and if a response is received, then the recipient use of legacy mechanisms, and if a response is received, then the
can be assumed to be crypto-agile and future requests to that recipient can be assumed to be crypto-agile and future requests to
recipient can utilize secure mechanisms. Similarly, the responder that recipient can utilize secure mechanisms. Similarly, the
can assume that the requester supports crypto-agility and can responder can assume that the requester supports crypto-agility and
prohibit use of legacy mechanisms in future requests. can prohibit use of legacy mechanisms in future requests.
If a response is not received, in the absence of information If a response is not received, in the absence of information
indicating responder support for crypto-agility (such as pre- indicating responder support for crypto-agility (such as pre-
configuration or previous receipt of a crypto-agile response), a new configuration or previous receipt of a crypto-agile response), a new
request can be composed utilizing legacy mechanisms. request can be composed utilizing legacy mechanisms.
Since legacy implementations not supporting crypto-agility will Since legacy implementations not supporting crypto-agility will
silently discard requests not protected by legacy algorithms rather silently discard requests not protected by legacy algorithms rather
than returning an error, repeated requests may be required to than returning an error, repeated requests may be required to
distinguish lack of support for crypto-agility from packet loss or distinguish lack of support for crypto-agility from packet loss or
skipping to change at page 8, line 50 skipping to change at page 9, line 34
Proposals MUST discuss any inherent assumptions about, or limitations Proposals MUST discuss any inherent assumptions about, or limitations
on, client/server operations or deployment and SHOULD provide on, client/server operations or deployment and SHOULD provide
recommendations for transition of deployments from legacy RADIUS to recommendations for transition of deployments from legacy RADIUS to
crypto-agile RADIUS. Issues regarding cipher-suite negotiation, crypto-agile RADIUS. Issues regarding cipher-suite negotiation,
legacy interoperability and the potential for bidding down attacks, legacy interoperability and the potential for bidding down attacks,
SHOULD be among these discussions. SHOULD be among these discussions.
4.6. Applicability of Automated Key Management Requirements 4.6. Applicability of Automated Key Management Requirements
[RFC4107] provides guidelines for when automated key management is "Guidelines for Cryptographic Key Management" [RFC4107] provides
necessary. At the IETF-70 meeting, and leading up to that meeting, guidelines for when automated key management is necessary. At the
the RADEXT WG debated whether or not RFC 4107 would require a RADIUS IETF-70 meeting, and leading up to that meeting, the RADEXT WG
Crypto-Agility solution to feature Automated Key Management (AKM). debated whether or not RFC 4107 would require a RADIUS Crypto-Agility
The working group determined that AKM was not inherently required for solution to feature Automated Key Management (AKM). The working
RADIUS based on the following points: group determined that AKM was not inherently required for RADIUS
based on the following points:
o RFC 4107 requires AKM for protocols that involve O(n^2) keys. o RFC 4107 requires AKM for protocols that involve O(n^2) keys.
This does not apply to RADIUS deployments, which require O(n) This does not apply to RADIUS deployments, which require O(n)
keys. keys.
o Requirements for session key freshness can be met without AKM, o Requirements for session key freshness can be met without AKM,
for example, by utilizing a pre-shared key along with an exchange for example, by utilizing a pre-shared key along with an exchange
of nonces. of nonces.
o RADIUS does not require the encryption of large amounts of data in o RADIUS does not require the encryption of large amounts of data in
skipping to change at page 9, line 30 skipping to change at page 10, line 15
o Organizations already have operational practices to manage o Organizations already have operational practices to manage
existing RADIUS shared secrets to address key changes required existing RADIUS shared secrets to address key changes required
as a result of personnel changes. as a result of personnel changes.
o The crypto-agility solution can avoid use cryptographic modes of o The crypto-agility solution can avoid use cryptographic modes of
operation such as a counter mode cipher that require frequent key operation such as a counter mode cipher that require frequent key
changes. changes.
However, the same time, it is recognized that features recommended in However, the same time, it is recognized that features recommended in
Section 4.2 such as support for PFS and direct transport of keys Section 4.2 such as support for PFS and direct transport of keys
between a NAS and RADIUS server, can only be provided by a solution between a NAS and RADIUS server can only be provided by a solution
supporting AKM. As a result, support for Automated Key Management is supporting AKM. As a result, support for Automated Key Management is
RECOMMENDED within a RADIUS crypto-agility solution. RECOMMENDED within a RADIUS crypto-agility solution.
Also, automated key management is REQUIRED for RADIUS crypto-agility Also, automated key management is REQUIRED for RADIUS crypto-agility
solutions that use cryptographic modes of operation that require solutions that use cryptographic modes of operation that require
frequent key changes. frequent key changes.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
6. Security Considerations 6. Security Considerations
Potential attacks against the RADIUS protocol are described in RFC Potential attacks against the RADIUS protocol are described in
3579 [RFC3579] Section 4.1, and details of known exploits as well as [RFC3579] Section 4.1, and details of known exploits as well as
potential mitigations are discussed in [RFC3579] Section 4.3. potential mitigations are discussed in [RFC3579] Section 4.3.
This specification describes the requirements for new cryptographic This specification describes the requirements for new cryptographic
protection mechanisms, including the modular selection of algorithms protection mechanisms, including the modular selection of algorithms
and modes. Therefore, the subject matter of this memo is all about and modes. Therefore, the subject matter of this memo is all about
security. security.
7. Acknowledgments 7. Acknowledgments
Thanks to all the reviewers and contributors, including Bernard Thanks to all the reviewers and contributors, including Bernard
Aboba, Joe Salowey and Glen Zorn. Aboba, Joe Salowey and Glen Zorn.
8. Informative References 8. Informative References
[NIST-SP800-131A] [NIST-SP800-131A]
Barker, E. and A. Roginsky, "Transitions: Recommendation for Barker, E. and A. Roginsky, "Transitions: Recommendation for
Transitioning the Use of Cryptographic Algorithms and Key Transitioning the Use of Cryptographic Algorithms and Key
Lengths", NIST SP-800-131A, January 2011. Lengths", NIST SP-800-131A, January 2011.
[RADYN] Winter, S. and M. McCauley, "NAI-based Dynamic Peer [RADYN] Winter, S. and M. McCauley, "NAI-based Dynamic Peer Discovery
Discovery for RADIUS over TLS and DTLS", Internet draft, work for RADIUS over TLS and DTLS", Internet draft (work in
in progress, March 2010. progress), draft-ietf-radext-dynamic-discovery-02, March 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
2548, March 1999. 2548, March 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000. 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
and I. Goyret, "RADIUS Attributes for Tunnel Protocol and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000. Support", RFC 2868, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001. 3162, August 2001.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
In User Service) Support For Extensible Authentication In User Service) Support For Extensible Authentication
Protocol (EAP)", RFC 3579, September 2003. Protocol (EAP)", RFC 3579, September 2003.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key
Key Management", BCP 107, RFC 4107, June 2005. Management", BCP 107, RFC 4107, June 2005.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", BCP 132, Authorization, and Accounting (AAA) Key Management", BCP 132,
RFC 4962, July 2007. RFC 4962, July 2007.
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
Authentication Dialin User Service (RADIUS) Protocol", RFC Authentication Dialin User Service (RADIUS) Protocol", RFC
5997, August 2010. 5997, August 2010.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for
the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151,
6151, March 2011. March 2011.
[RFC6158] DeKok, A., "RADIUS Design Guidelines", BCP 158, RFC 6158, [RFC6158] DeKok, A., "RADIUS Design Guidelines", BCP 158, RFC 6158,
March 2011. March 2011.
Author's Address Author's Address
David B. Nelson David B. Nelson
Elbrys Networks, Inc. Elbrys Networks, Inc.
282 Corporate Drive, Unit 1 282 Corporate Drive, Unit 1
Portsmouth, NH 03801 Portsmouth, NH 03801
USA USA
Email: d.b.nelson@comcast.net Email: d.b.nelson@comcast.net
 End of changes. 35 change blocks. 
114 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/