draft-ietf-radext-crypto-agility-requirements-03.txt   draft-ietf-radext-crypto-agility-requirements-04.txt 
Network Working Group D. Nelson RADEXT Working Group D. Nelson (Editor)
Internet-Draft Elbrys Networks, Inc. INTERNET-DRAFT Elbrys Networks, Inc.
Intended status: Informational March 3, 2011 Category: Informational
Expires: September 3, 2011 Expires: September 12, 2011
12 March 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-03.txt draft-ietf-radext-crypto-agility-requirements-04.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 to IETF in full conformance with This Internet-Draft is submitted in full conformance with the
the provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
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 3, 2011. This Internet-Draft will expire on September 12, 2011.
Requirements Language
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].
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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the BSD License. described in the BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
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. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 3 1.3. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Current State of RADIUS Security . . . . . . . . . . . . . 4 2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 4
4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Current State of RADIUS Security . . . . . . . . . . . . . 5
4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 4 4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 4 4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 5
4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 6 4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 6
4.4. Interoperability and Change Control . . . . . . . . . . . . 6 4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 7
4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Interoperability and Change Control . . . . . . . . . . . . 8
4.6. Applicability of Automated Key Management Requirements . . 7 4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 4.6. Applicability of Automated Key Management Requirements . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
8. Informative References . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Informative References . . . . . . . . . . . . . . . . . . . 10
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 Working Group of the IETF (RADEXT) 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 previously been expressed The requirements defined in this memo have been developed based on e-
in 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.
1.2. The Charge 1.2. Requirements Language
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].
A RADIUS crypto-agility solution is not compliant with this
specification if it fails to satisfy one or more of the MUST or MUST
NOT statements. A solution 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".
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 requirements.
Specific attention will be paid to RFC 4962 [RFC4962]. Specific attention will be paid to RFC 4962 [RFC4962].
The RADEXT WG will propose one or more Internet Drafts 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 the
RADIUS protocol. The known deficiencies include the issue of 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 function.
Additionally, at least one mandatory to implement algorithm will be Additionally, at least one mandatory to implement cryptographic
defined in each of these areas, as required. algorithm will be defined in each of these areas, as required.
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 for RADEXT WG session during IETF-68. Crypto-Agility is the ability of a
a protocol to adapt to evolving cryptography and security protocol to adapt to evolving cryptography and security requirements.
requirements. This may include the provision of a modular mechanism This may include the provision of a modular mechanism to allow
to allow cryptographic algorithms to be updated without substantial cryptographic algorithms to be updated without substantial disruption
disruption to fielded implementations. It may provide for the to fielded implementations. It may provide for the dynamic
dynamic negotiation and installation of cryptographic algorithms negotiation and installation of cryptographic algorithms within
within protocol implementations (think of Dynamic-Link Libraries protocol implementations (think of Dynamic-Link Libraries (DLL)).
(DLL)).
In the specific context of the RADIUS protocol and RADIUS In the specific context of the RADIUS protocol and RADIUS
implementations, crypto-agility may be better defined as the ability implementations, crypto-agility may be better defined as the ability
of RADIUS implementations to automatically negotiate cryptographic of RADIUS implementations to automatically negotiate cryptographic
algorithms for use in RADIUS exchanges, including the algorithms algorithms for use in RADIUS exchanges, including the algorithms used
used to protect RADIUS packets and to hide RADIUS Attributes. to integrity protect and authenticate RADIUS packets and to hide
This capability covers all RADIUS message types: RADIUS Attributes. This capability covers all RADIUS message types:
Access-Request/Response, Accounting-Request/Response and Access-Request/Response, Accounting-Request/Response, CoA/Disconnect-
and CoA/Disconnect-Request/Response. Request/Response, and Status-Server. Negotiation of cryptographic
algorithms MAY occur within the RADIUS protocol, or within a lower
layer such as the transport layer.
Since RADIUS is a request/response protocol, the ability to negotiate
cryptographic algorithms within a single RADIUS exchange is
inherently limited. While a RADIUS request can provide a list of
supported cryptographic algorithms which can selected for use within
a response, prior to the receipt of a response, the cryptographic
algorithms utilized to provide security services within the request
will need to be determined a-priori.
Proposals MUST NOT introduce new capabilities negotiation features
into the RADIUS protocol and crypto-agility solutions SHOULD NOT
require changes to the RADIUS operational model as defined in "RADIUS
Design Guidelines" [RFC6158] Section 3.1 and Appendix A.4.
Similarly, a proposal SHOULD focus on the crypto-agility problem and
nothing else. For example, proposals SHOULD NOT require new
attribute formats and SHOULD be compatible with the guidance provided
in [RFC6158] Section 2.3.
Acceptable solutions for determining the mechanisms to be used within
a request include manual configuration as well as backward compatible
negotiation techniques such as those described in Section 4.3.
Solutions for determining the mechanisms to be used in a response
include manual configuration and "advertise and select" mechanisms
(e.g. selection within the response from mechanisms advertised in a
request).
3. The Current State of RADIUS Security 3. The Current State of RADIUS Security
RADIUS packets, as defined in [RFC2865], are protected by an MD5 RADIUS packets, as defined in [RFC2865], are protected by an MD5
message integrity check (MIC), within the Authenticator field of message integrity check (MIC), within the Authenticator field of
RADIUS packets other than Access-Request. The Message-Authenticator RADIUS packets other than Access-Request [RFC2865] and Status-Server
Attribute utilizes HMAC-MD5 to authenticate and integrity protect [RFC5997]. The Message-Authenticator Attribute utilizes HMAC-MD5 to
RADIUS packets. Various RADIUS attributes support hidden values, authenticate and integrity protect RADIUS packets.
including: User-Password, Tunnel-Password, and various Vendor-
Specific Attributes. Generally speaking, the hiding mechanism uses a
stream cipher based on a key stream from an MD5 digest.
Recent work on MD5 collisions does not immediately compromise any of While RADIUS does not support confidentiality of entire packets,
these methods, absent knowledge of the RADIUS shared secret. various RADIUS attributes support encrypted (also known as "hidden")
However, the progress toward compromise of MD5's basic cryptographic values, including: User-Password (defined in [RFC2865] Section 5.2),
assumptions has resulted in the deprecation of MD5 usage in a variety Tunnel-Password (defined in [RFC2868] Section 3.5), and various
of applications. Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE-
Recv-Key attributes (defined in [RFC2548] Section 2.4). Generally
speaking, the hiding mechanism uses a stream cipher based on a key
stream from an MD5 digest. Attacks against this mechanism are
described in [RFC3579] Section 4.3.4.
"Updated Security Considerations for the MD5 Message-Digest and the
HMAC-MD5 Algorithms" [RFC6151] discusses security considerations for
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
for the purposes used within RADIUS Eabsent knowledge of the RADIUS
shared secret, the progress toward compromise of MD5's basic
cryptographic assumptions has resulted in the deprecation of MD5
usage in a variety of applications. As noted in [RFC6151] Section 2:
MD5 is no longer acceptable where collision resistance is required
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
for digital signatures, new protocol designs should not employ
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] and [RFC3579], this technique is already described in [RFC3162] Section 5 and [RFC3579] Section 4.2,
already available to those who wish to use it. Therefore, it is this technique is already available to those who wish to use it.
expected that proposals will utilize other techniques.
Therefore, it is expected that proposals will utilize other
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. Support for for per-packet integrity/authentication protection. It is
confidentiality of entire RADIUS packets is OPTIONAL. However, RECOMMENDED that solutions provide support for confidentiality,
proposals MUST support the negotiation of algorithms for encryption either by supporting encryption of entire RADIUS packets or by
(sometimes referred to as "hiding") of RADIUS attributes. It is encrypting individual RADIUS attributes. This includes providing
RECOMMENDED for proposals to provide for the encryption support for improving the confidentiality of existing encrypted
of existing attributes. This includes existing "hidden" attributes (sometimes referred to as "hidden") attributes as well as encrypting
as well as attributes (such as location attributes) that require attributes (such as location attributes) that are currently
confidentiality. transmitted in cleartext. Proposals supporting confidentiality MUST
support the negotiation of cryptographic algorithms for encryption.
Proposals MUST support per-packet replay protection for all Proposals MUST support per-packet replay protection for all RADIUS
RADIUS message types. 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 the RADIUS server can be configured solution, it can be assumed that RADIUS requesters and responders can
to require the use of new secure algorithms in the event of a be configured to require the use of new secure algorithms in the
compromise of existing cryptographic algorithms or the legacy RADIUS event of a compromise of existing cryptographic algorithms or the
shared secret. legacy RADIUS shared secret.
Crypto-agility solutions MUST specify mandatory-to-implement Crypto-agility solutions MUST specify mandatory-to-implement
algorithms for each defined mechanism. cryptographic algorithms for each defined mechanism. Guidance on
acceptable algorithms can be found in [NIST-SP800-131A]. In
particular, it is RECOMMENDED that mandatory-to-implement
cryptographic algorithms be chosen from among those classified as
"Acceptable" with no known deprecation date within [NIST-SP800-131A].
In addition to the above goals, [RFC4962] Section 2 describes In addition to the goals referred to above, [RFC4962] Section 2
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. session keys for use between the RADIUS client and server. In
In order to prevent the disclosure of one session key from order to prevent the disclosure of one session key from aiding an
aiding an attacker in discovering other session keys, RADIUS attacker in discovering other session keys, RADIUS crypto-agility
crypto-agility solutions are RECOMMENDED to support Perfect solutions are RECOMMENDED to support Perfect Forward Secrecy (PFS)
Forward Secrecy (PFS) with respect to session keys negotiated with respect to session keys negotiated between the RADIUS client
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 In order to enable a NAS and RADIUS server to transmit keying
material directly, it is RECOMMENDED that a RADIUS crypto- material directly, it is RECOMMENDED that a RADIUS crypto-agility
agility solution be compatible with NAI-based Dynamic Peer solution be compatible with NAI-based Dynamic Peer Discovery
Discovery [RADYN] as well as that it support the use of public [RADYN] as well as that it support the use of public key
key credentials for authentication between the NAS and RADIUS credentials for authentication between the NAS and RADIUS server.
server. For compatibility with existing operations, RADIUS For compatibility with existing operations, RADIUS crypto-agility
crypto-agility solutions SHOULD also support pre-shared key solutions SHOULD also support pre-shared key credentials.
credentials.
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
supports both the crypto-agility solution and legacy mechanisms MUST supports both the crypto-agility solution and legacy mechanisms MUST
be able to talk with legacy RADIUS clients and servers (using the be able to talk with legacy RADIUS clients and servers (using the
legacy mechanisms). Acceptable solutions to determining which set of legacy mechanisms).
mechanisms is used (with a particular peer) include some kind of
negotiation, and manual configuration.
Proposals MUST NOT introduce new capabilities negotation features While backward compatibility is needed to ease the transition between
into the RADIUS protocol, but rather MUST use the existing legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is
mechanisms. Included in such negotiation techniques are "hint and only appropriate prior to the compromise of those mechanisms. After
accept" and "hint and reject" mechanisms, where the NAS (RADIUS legacy mechanisms have been compromised, secure algorithms MUST be
client) provides a list of supported algorithms and the RADIUS server used, so that backward compatibility is no longer possible.
selects one.
Crypto-agility solutions SHOULD NOT require changes to the RADIUS In order to enable a request to be handled both by legacy as well as
operational model as defined in "RADIUS Design Guidelines" [RFC6158] crypto-agile implementations, a request can be secured with legacy
Section 3.1 and Appendix A.4. Similarly, a proposal SHOULD focus on algorithms as well as more secure algorithms. While this approach
the crypto-agility problem and nothing else. For example, proposals permits the initial use of legacy algorithms between crypto-agile
SHOULD NOT require new attribute formats and SHOULD be compatible implementations, if the responder indicates support for crypto-
with the guidance provided in [RFC6158] Section 2.3. agility, future requests can omit use of legacy algorithms, instead
utilizing mechanisms indicated in the response.
This approach minimizes the response delay from both legacy and
crypto-agile implementations. However, it is viable only where
legacy hidden attributes (e.g. User-Password) are not included within
requests.
Probing techniques can avoid the use of legacy algorithms between
crypto-agile implementations. An initial request can omit use of
legacy mechanisms, and if a response is received, then the recipient
can be assumed to be crypto-agile and future requests to that
recipient can utilize secure mechanisms. Similarly, the responder
can assume that the requester supports crypto-agility and can
prohibit use of legacy mechanisms in future requests.
If a response is not received, in the absence of information
indicating responder support for crypto-agility (such as pre-
configuration or previous receipt of a crypto-agile response), a new
request can be composed utilizing legacy mechanisms.
Since legacy implementations not supporting crypto-agility will
silently discard requests not protected by legacy algorithms rather
than returning an error, repeated requests may be required to
distinguish lack of support for crypto-agility from packet loss or
other failure conditions. As a result, probing techniques can delay
initial communication between crypto-agile requesters and legacy
responders. This can be addressed by upgrading the responders (e.g.
RADIUS servers) first.
4.4. Interoperability and Change Control 4.4. Interoperability and Change Control
Proposals MUST indicate a willingness to cede change control to the Proposals MUST indicate a willingness to cede change control to the
IETF. IETF.
Crypto-agility solutions MUST be interoperable between independent Crypto-agility solutions MUST be interoperable between independent
implementations based purely on the information provided in the implementations based purely on the information provided in the
specification. specification.
4.5. Scope of Work 4.5. Scope of Work
Crypto-agility solutions MUST apply to all RADIUS packet types, Crypto-agility solutions MUST apply to all RADIUS packet types,
including Access-Request, Access-Challenge, Access-Reject, Access- including Access-Request, Access-Challenge, Access-Reject, Access-
Accept, Accounting-Request, Accounting-Response, and CoA/Disconnect Accept, Accounting-Request, Accounting-Response, Status-Server and
messages. CoA/Disconnect messages.
Since it is expected that the work will occur purely within RADIUS Since it is expected that the work will occur purely within RADIUS or
or in the transport, message data exchanged with Diameter SHOULD NOT in the transport, message data exchanged with Diameter SHOULD NOT be
be affected. affected.
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 ciper-suite negotiation, crypto-agile RADIUS. Issues regarding cipher-suite negotiation,
legacy interoperability and the potential for biding 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 [RFC4107] provides guidelines for when automated key management is
necessary. At the IETF-70 meeting, and leading up to that meeting, necessary. At the IETF-70 meeting, and leading up to that meeting,
the RADEXT WG debated whether or not RFC 4107 would require a RADIUS the RADEXT WG debated whether or not RFC 4107 would require a RADIUS
Crypto-Agility solution to feature Automated Key Management (AKM). Crypto-Agility solution to feature Automated Key Management (AKM).
The working group determined that AKM was not inherently required for The working group determined that AKM was not inherently required for
RADIUS based on the following points: 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) keys This does not apply to RADIUS deployments, which require O(n)
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
a short time a short time.
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 However, the same time, it is recognized that features recommended in
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 supporting AKM. As a result, support for Automated Key Management is
is RECOMMENDED within a RADIUS crypto-agility solution. RECOMMENDED within a RADIUS crypto-agility solution.
Also, automated key management is REQUIRED for RADIUS crypto Also, automated key management is REQUIRED for RADIUS crypto-agility
agility solutions that use cryptographic modes of operation that solutions that use cryptographic modes of operation that require
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
3579 [RFC3579] Section 4.1, and details of known exploits as well as
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. Acknowledgements 7. Acknowledgments
Thanks to all the reviewers and contributors, inclding Bernard Aboba, Thanks to all the reviewers and contributors, including Bernard
Joe Salowey and Glen Zorn. Aboba, Joe Salowey and Glen Zorn.
8. Informative References 8. Informative References
[RADYN] Winter, S. and M. McCauley, "NAI-based Dynamic Peer [NIST-SP800-131A]
Discovery for RADIUS over TLS and DTLS", work in Barker, E. and A. Roginsky, "Transitions: Recommendation for
progress, March 2010. Transitioning the Use of Cryptographic Algorithms and Key
Lengths", NIST SP-800-131A, January 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RADYN] Winter, S. and M. McCauley, "NAI-based Dynamic Peer
Requirement Levels", BCP 14, RFC 2119, March 1997. Discovery for RADIUS over TLS and DTLS", Internet draft, work
in progress, March 2010.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
"Remote Authentication Dial In User Service (RADIUS)", Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2865, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
RFC 3162, August 2001. 2548, March 1999.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Dial In User Service) Support For Extensible Authentication Dial In User Service (RADIUS)", RFC 2865, June
Authentication Protocol (EAP)", RFC 3579, September 2003. 2000.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
Key Management", BCP 107, RFC 4107, June 2005. and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC
Authorization, and Accounting (AAA) Key Management", 3162, August 2001.
BCP 132, RFC 4962, July 2007.
[RFC6158] DeKok, A., "RADIUS Design Guidelines", BCP X, RFC 6158, [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
March 2011. In User Service) Support For Extensible Authentication
Protocol (EAP)", RFC 3579, September 2003.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", BCP 132,
RFC 4962, July 2007.
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
Authentication Dialin User Service (RADIUS) Protocol", RFC
5997, August 2010.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for
the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC
6151, March 2011.
[RFC6158] DeKok, A., "RADIUS Design Guidelines", BCP 158, RFC 6158,
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. 51 change blocks. 
168 lines changed or deleted 276 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/