draft-ietf-radext-crypto-agility-requirements-00.txt   draft-ietf-radext-crypto-agility-requirements-01.txt 
Network Working Group D. Nelson Network Working Group D. Nelson
Internet-Draft Elbrys Networks, Inc. Internet-Draft Elbrys Networks, Inc.
Intended status: Informational May 8, 2008 Intended status: Informational November 19, 2008
Expires: November 9, 2008 Expires: May 23, 2009
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-00.txt draft-ietf-radext-crypto-agility-requirements-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 November 9, 2008. This Internet-Draft will expire on May 23, 2009.
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).
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 3 2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 3
3. The Current State of RADIUS Encryption . . . . . . . . . . . . 4 3. The Current State of RADIUS Encryption . . . . . . . . . . . . 4
4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 4 4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 4
4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 4 4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 4
4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 5 4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 5
4.4. Interoperability and Change Control . . . . . . . . . . . . 5 4.4. Interoperability and Change Control . . . . . . . . . . . . 6
4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 5 4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 6
4.6. Applicability of Automated Key Management Requirements . . 6 4.6. Applicability of Automated Key Management Requirements . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9
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
skipping to change at page 3, line 39 skipping to change at page 3, line 39
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. Specific attention will be paid to RFC 4962.
The RADEXT WG will propose one of more Internet Drafts to remediate The RADEXT WG will propose one or more Internet Drafts 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 algorithm will be
defined in each of these areas, as required. 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
skipping to change at page 4, line 42 skipping to change at page 4, line 42
However, the progress toward compromise of MD5's basic cryptographic However, the progress toward compromise of MD5's basic cryptographic
assumptions has resulted in the deprecation of MD5 usage in a variety assumptions has resulted in the deprecation of MD5 usage in a variety
of applications. of applications.
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 RFC 3162 and 3579, this technique is already already described in RFC 3162 and RFC 3579, this technique is already
available to those who wish to use it. Therefore, it is expected available to those who wish to use it. Therefore, it is expected
that proposals will utilize other techniques. 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. Support for
confidentiality of entire RADIUS packets is OPTIONAL. However, confidentiality of entire RADIUS packets is OPTIONAL. However,
proposals MUST support the negotiation of algorithms for encryption proposals MUST support the negotiation of algorithms for encryption
(sometimes referred to as "hiding") of RADIUS attributes. If (sometimes referred to as "hiding") of RADIUS attributes. If
possible, it is desirable for proposals to provide for the encryption possible, it is desirable for proposals to provide for the encryption
of existing attributes. This includes existing "hidden" attributes of existing attributes. This includes existing "hidden" attributes
as well as attributes (such as location attributes) that require as well as attributes (such as location attributes) that require
confidentiality. confidentiality.
Included in negotiation techniques are "hint and consent" mechanisms
where the NAS provides a list of algorithms and the server selects
one.
Proposals MUST support replay protection. The existing mechanisms Proposals MUST support replay protection. The existing mechanisms
for replay protection are considered adequate and should be for replay protection are considered adequate and should be
maintained. 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 Crypto-agility solutions MUST specify mandatory-to-implement
algorithms for each mechanism. algorithms for each defined mechanism.
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, a crypto-agility solution existing RADIUS implementations. That is, a crypto-agility solution
needs to be able to send packets that a legacy RADIUS client or needs to be able to send packets that a legacy RADIUS client or
server will receive and process successfully. Similarly, a crypto- server will receive and process successfully. Similarly, a crypto-
agility solution needs to be capable of receiving and processing agility solution needs to be capable of receiving and processing
packets from a legacy RADIUS client or server. packets from a legacy RADIUS client or server.
Crypto-agility solutions MUST avoid security compromise, even in Proposals MUST NOT introduce new capabilities negotation features
situations where the existing cryptographic algorithms utilized by into the RADIUS protocol, but rather MUST use the existing
RADIUS implementations are shown to be weak enough to provide little mechanisms. Included in such negotiation techniques are "hint and
or no security (e.g. in event of compromise of the "legacy" RADIUS accept" and "hint and reject" mechanisms, where the NAS (RADIUS
shared secret). Included in this would be protection against bidding client) provides a list of supported algorithms and the RADIUS server
down attacks. 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.
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.
skipping to change at page 6, line 12 skipping to change at page 6, line 26
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, and CoA/Disconnect
messages. messages.
Proposals MUST include a Diameter compatibility section, although it Proposals MUST include a Diameter compatibility section, although it
is expected that the work will occur purely within RADIUS or in the is expected that the work will occur purely within RADIUS or in the
transport, and therefore does not affect message data that is transport, and therefore does not affect message data that is
exchanged with Diameter. exchanged with Diameter.
Crypto-agility solutions SHOULD NOT require fundamental changes to Proposals MUST discuss any inherent assumptions about, or limitations
the RADIUS operational model, such as the introduction of new on, client/server operations or deployment and SHOULD provide
commands or maintenance of state on the RADIUS server. Similarly, a recommendations for transition of deployments from legacy RADIUS to
proposal SHOULD focus on the crypto-agility problem and nothing else. crypto-agile RADIUS. Issues regarding ciper-suite negotiation,
For example, proposals SHOULD NOT require new attribute formats or legacy interoperability and the potential for biding down attacks,
include definition of new RADIUS services. Unless modified, the SHOULD be among these discussions.
restrictions in the RADEXT WG charter apply.
Note that for the purposes of this work, the RADEXT WG charter 4.6. Applicability of Automated Key Management Requirements
restriction against definition of "new security mechanisms" should be
interpreted as prohibiting changes to the basic RADIUS packet format
(e.g. headers), but permits new crypto-algorithms to be substituted
for use in existing security mechanisms.
Editorial Note: With the expected acceptance of the proposed RADEXT [RFC 4107] provides guidelines for when automated key management is
WG Charter revision, some of the issues raised in the preceding necessary. At the IETF-70 meeting, and leading up to that meeting,
paragraphs become moot, and this section ought to be revised to the RADEXT WG debated whether or not RFC 4107 would require a RADIUS
reflect the revised charter. 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:
4.6. Applicability of Automated Key Management Requirements 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
At the IETF-70 meeting, and leading up to that meeting, the RADEXT WG o RADIUS does not require the encryption of large amounts of data in
debated whether or not RFC 4107 would require a RADIUS Crypto-Agility a short time
solution to feature Automated Key Management (AKM). It was pointed
out that RFC 4107 only requires AKM for protocols that involve O(n^2) o Organizations already have operational practices to manage
keys. This does not apply to RADIUS deployments, which require O(n) existing RADIUS shared secrets to address key changes required
keys. The consensus of the RADEXT WG is that RADIUS crypto-agility through personnel changes
solutions do not need to provide AKM, and that appropriate security o The crypto-agility solution can avoid use cryptographic modes of
considerations text would be drafted to explain why the AKM operation such as a counter mode cipher that require frequent key
provisions of RFC 4107 do not apply. 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 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations 6. Security Considerations
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. Acknowledgements
TBS Thanks to all the reviewers and contributors, inclding Bernard Aboba,
Joe Salowey and Glen Zorn.
8. Informative References 8. Informative References
[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.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
 End of changes. 19 change blocks. 
52 lines changed or deleted 62 lines changed or added

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