One document matched: draft-ietf-radext-crypto-agility-requirements-02.txt
Differences from draft-ietf-radext-crypto-agility-requirements-01.txt
Network Working Group D. Nelson
Internet-Draft Elbrys Networks, Inc.
Intended status: Informational March 3, 2011
Expires: September 3, 2011
Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)
draft-ietf-radext-crypto-agility-requirements-02.txt
Abstract
This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS).
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 3, 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].
Nelson Expires September 3, 2011 [Page 1]
Internet-Draft RADIUS Crypto-Agility Requirements March 2011
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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
Nelson Expires September 3, 2011 [Page 2]
Internet-Draft RADIUS Crypto-Agility Requirements March 2011
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 September 3, 2011 [Page 3]
Internet-Draft RADIUS Crypto-Agility Requirements March 2011
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 September 3, 2011 [Page 4]
Internet-Draft RADIUS Crypto-Agility Requirements March 2011
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 September 3, 2011 [Page 5]
Internet-Draft RADIUS Crypto-Agility Requirements March 2011
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
[RFC4107] 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 September 3, 2011 [Page 6]
Internet-Draft RADIUS Crypto-Agility Requirements March 2011
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 September 3, 2011 [Page 7]
Internet-Draft RADIUS Crypto-Agility Requirements March 2011
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
Author's Address
David B. Nelson
Elbrys Networks, Inc.
75 Rochester Avenue, Unit 3
Portsmouth, NH 03801
USA
Email: d.b.nelson@comcast.net
Nelson Expires September 3, 2011 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 15:20:05 |