Bernard:
Your rewording of section 2 seems fine to me. As co-author, you
could have provided it many months ago ;-)
Are you suggesting the addition of something like:
Authors who follow these guidelines specified in this document
should incorporate this phrase near the beginning of their document:
This document follows the AAA key management guidelines
specified in RFC XXXX.
Russ
At 04:27 PM 11/7/2006, Bernard Aboba wrote:
Here are my comments on the document:
Overall Comments
While this document includes a lot of useful requirements, it does not
provide guidance on how document authors should demonstrate adherence to
the principles that are described. For example, a AAA key management
document may not include a section describing the assumptions and
requirements of the design, which can make it difficult for a reviewer
to determine whether or not the protocol fulfills its goals. The
document describes a number of useful security properties, but there is
no request that document authors include sections in their
documents that correspond to these requirements.
As a result, my concern is that reviewers could be left with a large task
to determine whether a given document did or did not fulfill the
requirements described in this document.
In order to make life easier for reviewers, it might be helpful for the
document to provide explicit guidance for draft authors.
NITs
Section 2
This section is entitled "AAA Environment Concerns". As a result, I was
expecting the section to begin with a description of issues relating to
AAA. Instead the section starts off talking about EAP. My suggestion is
that the section be reorganized as follows:
" Examples of serious flaws plague the history of key management
protocol development, starting with the very first attempt to define
a key management protocol in the open literature, which was published
in 1978 [NS]. A flaw and a fix were published in 1981 [DS], and the
fix was broken in 1994 [AN]. In 1995 [L], a new flaw was found in
the original 1978 version, in an area not affected by the 1981/1994
issue. All of these flaws were blindingly obvious once described,
yet no one spotted them earlier. Note that the original protocol, if
it were revised to employ certificates, which of course had yet to be
invented, was only three messages. Many proposed AAA key management
schemes are significantly more complicated.
This bit of history shows that key management protocols are subtle.
Experts can easily miss a flaw. As a result, peer review by multiple
experts is essential. In addition, formal methods can help uncover
problems [M].
AAA-based key management is being incorporated into standards
developed by the IETF and other standards development organizations
(SDOs), such as IEEE 802. However, due to ad hoc development of AAA-
based key management, AAA-based key distribution schemes have poorly
understood security properties, even when well-studied cryptographic
algorithms are employed. More academic research is needed to fully
understand the security properties of AAA-based key management in the
diverse protocol environments where it is being employed today. In
the absence of research results, pragmatic guidance based on sound
security engineering principles is needed.
In addition to the need for interoperability, cryptographic algorithm
independent solutions are greatly preferable. Without algorithm
independence, the protocol must be changed whenever a problem is
discovered with the selected algorithm. As the AAA history shows,
problems are inevitable. Problems can surface due to age or design
failure.
DES [FIPS46] was a well designed encryption algorithm, and it
provided protection for many years. Yet, the 56-bit key size was
eventually overcome by Moore's Law. No cryptographic deficiencies
have been discovered in DES.
The history of AAA underlines the importance of algorithm
independence as flaws have been found in authentication mechanisms
such as CHAP, MS-CHAPv1 [SM1], MS-CHAPv2 [SM2], Kerberos
[W][BM][DLS], and LEAP [B]. Unfortunately, RADIUS [RFC2865] mandates
use of the MD5 algorithm for integrity protection, which has known
deficiencies, and RADIUS has no provisions to negotiate substitute
algorithms. Similarly, the vendor-specific key wrap mechanism
defined in [RFC2548] has no provisions to negotiate substitute
algorithms.
The principle of least privilege is an important design guideline.
This principle requires that a party be given no more privilege than
necessary to perform the task assigned to them. Ensuring least
privilege requires clear identification of the tasks assigned to each
party, and explicit determination of the minimum set of privileges
required to perform those tasks. Only those privileges necessary to
perform the tasks are granted. By denying to parties unneeded
privileges, those denied privileges cannot be used to circumvent
security policy or enable attackers. With this principle in mind,
AAA key management schemes need to be designed in a manner where each
party has only the privileges necessary to perform their role. That
is, no party should have access to any keying material that is not
needed to perform their own role. A party has access to a particular
key if it has access to all of the secret information needed to
derive it.
EAP is being used in new ways. The inclusion of support for EAP
within IKEv2 and the standardization of robust Wireless LAN security
[802.11i] based on EAP are two examples. EAP is also supported
within IEEE 802.16e [802.16e] and by the IETF PANA Working Group.
EAP selects one end-to-end authentication mechanism. The mechanisms
defined in [RFC3748] only support unilateral authentication, and they
do not support mutual authentication or key derivation. As a result,
these mechanisms do not fulfill the security requirements for many
deployment scenarios, including Wireless LAN authentication
[RFC4017].
To ensure adequate security and interoperability, EAP applications
need to specify mandatory-to-implement algorithms. As described in
[RFC3748], EAP methods seeking publication as an IETF RFC need to
document their security claims. However, some EAP methods are not
based on well-studied models, which makes the validity of these
security claims difficult to determine.
In the context of EAP, the EAP peer and server are the parties
involved in the EAP method conversation, and they gain access to key
material when the conversation completes successfully. However, the
lower layer needs keying material to provide the desired protection
through the use of cryptographic mechanisms. As a result, a "pass-
through" mode is used to provide the keying material, and the lower
layer keying material is replicated from the AAA server to the
authenticator. The only parties authorized to obtain all of the
keying material are the EAP peer and server; the authenticator
obtains only the keying material necessary for its specific role. No
other party can obtain access to any of the keying material."
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf