One document matched: draft-ietf-radext-crypto-agility-requirements-01.txt
Differences from draft-ietf-radext-crypto-agility-requirements-00.txt
Network Working Group D. Nelson
Internet-Draft Elbrys Networks, Inc.
Intended status: Informational November 19, 2008
Expires: May 23, 2009
Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)
draft-ietf-radext-crypto-agility-requirements-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 23, 2009.
Abstract
This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS).
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].
Nelson Expires May 23, 2009 [Page 1]
Internet-Draft RADIUS Crypto-Agility Requirements November 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 3
3. The Current State of RADIUS Encryption . . . . . . . . . . . . 4
4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 4
4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 4
4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 5
4.4. Interoperability and Change Control . . . . . . . . . . . . 6
4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 6
4.6. Applicability of Automated Key Management Requirements . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Nelson Expires May 23, 2009 [Page 2]
Internet-Draft RADIUS Crypto-Agility Requirements November 2008
1. Introduction
1.1. General
This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS). This memo,
when approved, reflects the consensus of the RADIUS Extensions
Working Group of the IETF (RADEXT) as to the features, properties and
limitations of the crypto-agility work item for RADIUS. It also
defines the term "crypto-agility" as used in this context, and
provides the motivations for undertaking and completing this work.
The requirements defined in this memo have previously been expressed
in e-mail messages posted to the RADEXT WG mailing list, which may be
found in the archives of that list. The purpose of framing the
requirements in this memo is to formalize and memorialize them for
future reference, and to bring them explicitly to the attention of
the IESG and the IETF Community, as we proceed with this work.
1.2. The Charge
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
formal description of a crypto-agility work item, and corresponding
milestones in the RADEXT Charter. After consultation with one of the
Security Area Directors, Russ Housley, text was initially proposed on
the RADEXT WG mailing list on October 26, 2006. That text reads as
follows:
The RADEXT WG will review the security requirements for crypto-
agility in IETF protocols, and identify the deficiencies of the
existing RADIUS protocol specifications against these requirements.
Specific attention will be paid to RFC 4962.
The RADEXT WG will propose one or more Internet Drafts to remediate
any identified deficiencies in the crypto-agility properties of the
RADIUS protocol. The known deficiencies include the issue of
negotiation of substitute algorithms for the message digest
functions, the key-wrap functions, and the password-hiding function.
Additionally, at least one mandatory to implement algorithm will be
defined in each of these areas, as required.
2. A Working Definition of Crypto-Agility
A generalized definition of crypto-agility was offered up at the
RADEXT WG session during IETF-68. Crypto-Agility is the ability for
a protocol to adapt to evolving cryptography and security
Nelson Expires May 23, 2009 [Page 3]
Internet-Draft RADIUS Crypto-Agility Requirements November 2008
requirements. This may include the provision of a modular mechanism
to allow cryptographic algorithms to be updated without substantial
disruption to fielded implementations. It may provide for the
dynamic negotiation and installation of cryptographic algorithms
within protocol implementations (think of Dynamic-Link Libraries
(DLL)).
In the specific context of the RADIUS protocol and RADIUS
implementations, crypto-agility may be better defined as the ability
of RADIUS implementations to negotiate cryptographic algorithms for
use in RADIUS exchanges, including the cryptographic algorithms used
to protect RADIUS packets and to hide RADIUS Attributes. This
capability covers all RADIUS message types: Access-Request/Response,
Accounting-Request/Response, and CoA/Disconnect-Request/Response.
3. The Current State of RADIUS Encryption
RADIUS packets, as defined in RFC 2865, are protected by an MD5-baed
message integrity check (MIC), within the Authenticator field of
RADIUS packets other than Access-Request. The Message-Authenticator
Attribute utilizes HMAC-MD5 to authenticate and integrity protect
RADIUS packets. Various RADIUS attributes support hidden values,
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
these methods, absent knowledge of the RADIUS shared secret.
However, the progress toward compromise of MD5's basic cryptographic
assumptions has resulted in the deprecation of MD5 usage in a variety
of applications.
4. The Requirements
4.1. Overall Solution Approach
RADIUS crypto-agility solutions are not restricted to utilizing
technology described in existing RFCs. Since RADIUS over IPsec is
already described in RFC 3162 and RFC 3579, this technique is already
available to those who wish to use it. Therefore, it is expected
that proposals will utilize other techniques.
4.2. Security Services
Proposals MUST support the negotiation of cryptographic algorithms
for per-packet integrity/authentication protection. Support for
Nelson Expires May 23, 2009 [Page 4]
Internet-Draft RADIUS Crypto-Agility Requirements November 2008
confidentiality of entire RADIUS packets is OPTIONAL. However,
proposals MUST support the negotiation of algorithms for encryption
(sometimes referred to as "hiding") of RADIUS attributes. If
possible, it is desirable for proposals to provide for the encryption
of existing attributes. This includes existing "hidden" attributes
as well as attributes (such as location attributes) that require
confidentiality.
Proposals MUST support replay protection. The existing mechanisms
for replay protection are considered adequate and should be
maintained.
Crypto-agility solutions MUST avoid security compromise, even in
situations where the existing cryptographic algorithms utilized by
RADIUS implementations are shown to be weak enough to provide little
or no security (e.g. in event of compromise of the legacy RADIUS
shared secret). Included in this would be protection against bidding
down attacks.
Crypto-agility solutions MUST specify mandatory-to-implement
algorithms for each defined mechanism.
4.3. Backwards Compatibility
Solutions to the problem MUST demonstrate backward compatibility with
existing RADIUS implementations. That is, a crypto-agility solution
needs to be able to send packets that a legacy RADIUS client or
server will receive and process successfully. Similarly, a crypto-
agility solution needs to be capable of receiving and processing
packets from a legacy RADIUS client or server.
Proposals MUST NOT introduce new capabilities negotation features
into the RADIUS protocol, but rather MUST use the existing
mechanisms. Included in such negotiation techniques are "hint and
accept" and "hint and reject" mechanisms, where the NAS (RADIUS
client) provides a list of supported algorithms and the RADIUS server
selects one.
Crypto-agility solutions SHOULD NOT require changes to the RADIUS
operational model, such as the introduction of new commands or
maintenance of [additional] state on the RADIUS server. Similarly, a
proposal SHOULD focus on the crypto-agility problem and nothing else.
For example, proposals SHOULD NOT require new attribute formats or
include definition of new RADIUS services.
Nelson Expires May 23, 2009 [Page 5]
Internet-Draft RADIUS Crypto-Agility Requirements November 2008
4.4. Interoperability and Change Control
Proposals MUST indicate a willingness to cede change control to the
IETF.
Crypto-agility solutions MUST be interoperable between independent
implementations based purely on the information provided in the
specification.
4.5. Scope of Work
Crypto-agility solutions MUST apply to all RADIUS packet types,
including Access-Request, Access-Challenge, Access-Reject, Access-
Accept, Accounting-Request, Accounting-Response, and CoA/Disconnect
messages.
Proposals MUST include a Diameter compatibility section, although it
is expected that the work will occur purely within RADIUS or in the
transport, and therefore does not affect message data that is
exchanged with Diameter.
Proposals MUST discuss any inherent assumptions about, or limitations
on, client/server operations or deployment and SHOULD provide
recommendations for transition of deployments from legacy RADIUS to
crypto-agile RADIUS. Issues regarding ciper-suite negotiation,
legacy interoperability and the potential for biding down attacks,
SHOULD be among these discussions.
4.6. Applicability of Automated Key Management Requirements
[RFC 4107] provides guidelines for when automated key management is
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
Crypto-Agility solution to feature Automated Key Management (AKM).
The working 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.
This does not apply to RADIUS deployments, which require O(n) keys
o RADIUS does not require the encryption of large amounts of data in
a short time
o Organizations already have operational practices to manage
existing RADIUS shared secrets to address key changes required
through personnel changes
Nelson Expires May 23, 2009 [Page 6]
Internet-Draft RADIUS Crypto-Agility Requirements November 2008
o The crypto-agility solution can avoid use cryptographic modes of
operation such as a counter mode cipher that require frequent key
changes
Automated key management is required for RADIUS crypto agility
solutions that use cryptographic modes of operation that require
frequent key changes.
5. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
This specification describes the requirements for new cryptographic
protection mechanisms, including the modular selection of algorithms
and modes. Therefore, the subject matter of this memo is all about
security.
7. Acknowledgements
Thanks to all the reviewers and contributors, inclding Bernard Aboba,
Joe Salowey and Glen Zorn.
8. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial 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,
Nelson Expires May 23, 2009 [Page 7]
Internet-Draft RADIUS Crypto-Agility Requirements November 2008
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
Author's Address
David Nelson
Elbrys Networks, Inc.
75 Rochester Ave, Unit #3,
Portsmouth, NH 03801
USA
Phone: +1.603.570.2636
Email: dnelson@elbrysnetworks.com
Nelson Expires May 23, 2009 [Page 8]
Internet-Draft RADIUS Crypto-Agility Requirements November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Nelson Expires May 23, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 15:20:14 |