draft-ietf-radext-crypto-agility-requirements-05.txt   draft-ietf-radext-crypto-agility-requirements-06.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: October 16, 2011 Expires: November 2, 2011
16 April 2011 1 May 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-05.txt draft-ietf-radext-crypto-agility-requirements-06.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 October 16, 2011. This Internet-Draft will expire on November 2, 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 51 skipping to change at page 2, line 39
4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 6 4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 6
4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 6 4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 6
4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 8 4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 8
4.4. Interoperability and Change Control . . . . . . . . . . . . 9 4.4. Interoperability and Change Control . . . . . . . . . . . . 9
4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Applicability of Automated Key Management Requirements . . 9 4.6. Applicability of Automated Key Management Requirements . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10
8. Informative References . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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
(RADEXT) Working Group of the IETF 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
skipping to change at page 4, line 18 skipping to change at page 4, line 18
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 functions, the key-wrap functions, and the password-hiding
function. Additionally, at least one mandatory to implement function. Additionally, at least one mandatory to implement
cryptographic algorithm will be defined in each of these areas, as cryptographic algorithm will be defined in each of these areas, as
required. required.
1.4. Publication Process 1.4. Publication Process
RADIUS [RFC2865] is a widely deployed protocol that has attained RADIUS [RFC2865] is a widely deployed protocol that has attained
Draft Standard status based on multiple independent interoperable Draft Standard status based on multiple independent interoperable
implementations. It is therefore highly desirable that a high level implementations. Therefore it is desirable that a high level of
of interoperability and security be maintained for crypto-agility interoperability be maintained for crypto-agility solutions.
solutions.
To ensure that crypto-agility solutions published on the standards To ensure that crypto-agility solutions published on the standards
track are well specified, secure and interoperable, the RADEXT WG has track are well specified and interoperable, the RADEXT WG has adopted
adopted a two phase process for publication of crypto-agility a two phase process for standards-track publication of crypto-agility
solutions. solutions.
In the initial phase, crypto-agility solutions adopted by the working In the initial phase, crypto-agility solutions adopted by the working
group will be published on the Experimental Track. Experimental group will be published as Experimental. These documents should
Track documents should contain a description of experimental contain a description of the implementations and experimental
deployments and implementations in progress, as well as an evaluation deployments in progress, as well as an evaluation of the proposal
of the proposal against the requirements described in this document. against the requirements described in this document.
Based on the proposal evaluations, implementation and deployment The working group will then select proposals to advance on the
experience, and the results of interoperability tests, initial standards track. Criteria to be used include evaluation of the
proposals will be evaluated for publication on the standards track. proposal against the requirements, summary of the experimental
deployment experience and evidence of multiple interoperable
implementations.
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 7, line 34 skipping to change at page 7, line 36
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
It is RECOMMENDED that solutions enable a NAS and RADIUS server to In order to enable a NAS and RADIUS server to exchange confidential
exchange confidential information such as keying material without information such as keying material without disclosure to third
disclosure to third parties. In order to accomplish this, it is parties, it is RECOMMENDED that a RADIUS crypto-agility solution
RECOMMENDED that a RADIUS crypto-agility solution be compatible support X.509 certificates for authentication between the NAS and
with NAI-based Dynamic Peer Discovery [RADYN] as well as that it RADIUS server. Manual configuration as well as automated discovery
support the use of public key credentials for authentication mechanisms such as NAI-based Dynamic Peer Discovery [RADYN] can be
between the NAS and RADIUS server. used to enable direct NAS-RADIUS server communications. Support
for end-to-end confidentiality of RADIUS attributes is not
required.
For compatibility with existing operations, RADIUS crypto-agility For compatibility with existing operations, RADIUS crypto-agility
solutions SHOULD also support pre-shared key credentials. However, solutions SHOULD also support pre-shared key credentials. However,
support for end-to-end confidentiality of attributes or direct support for direct communications between the NAS and RADIUS server
communications between the NAS and RADIUS server is not required is not required when pre-shared key credentials are used.
when pre-shared key credentials are used.
Prevent the Domino effect
In order to prevent the domino effect, RADIUS crypto-agility
solutions MUST enable each RADIUS client and server pair to
authenticate utilizing unique credentials.
4.3. Backwards Compatibility 4.3. Backwards Compatibility
Solutions to the problem MUST demonstrate backward compatibility with Solutions MUST demonstrate backward compatibility with existing
existing RADIUS implementations. That is, an implementation that RADIUS implementations. That is, an implementation that supports
supports both the crypto-agility solution and legacy mechanisms MUST both crypto-agility and legacy mechanisms MUST be able to talk with
be able to talk with legacy RADIUS clients and servers (using the legacy RADIUS clients and servers (using the 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 and in addition attributes providing security services algorithms and in addition attributes providing security services
skipping to change at page 10, line 14 skipping to change at page 10, line 14
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 perfect forward secrecy and direct
between a NAS and RADIUS server can only be provided by a solution transport of keys between a NAS and RADIUS server can only be
supporting AKM. As a result, support for Automated Key Management is provided by a solution supporting AKM. As a result, support for
RECOMMENDED within a RADIUS crypto-agility solution. Automated Key Management is 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
skipping to change at page 10, line 41 skipping to change at page 10, line 42
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, Pasi Eronen, Joe Salowey and Glen Zorn.
8. Informative References 8. References
8.1. Normative 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 Discovery
for RADIUS over TLS and DTLS", Internet draft (work in
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
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.
[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.
[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.
8.2. Informative References
[RADYN] Winter, S. and M. McCauley, "NAI-based Dynamic Peer Discovery
for RADIUS over TLS and DTLS", Internet draft (work in
progress), draft-ietf-radext-dynamic-discovery-02, March 2010.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
2548, March 1999.
[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 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 [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
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. 19 change blocks. 
65 lines changed or deleted 68 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/