RE: Last Call: 'Guidance for AAA Key Management' to BCP (draft-housley-a

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 mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf