Subject: RE: Last Call: 'Guidance for AAA Key Management' to BCP (draft-housley-aaa-key-mgmt)

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Nov 2006 13:27:04 -0800 (PST)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Russ Housley <[email-masked]>
Date: Tue, 07 Nov 2006 17:30:38 -0500

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Nov 2006 15:08:15 -0800 (PST)

> Bernard:
> 
> Your rewording of section 2 seems fine to me.  As co-author, you could have
> provided it many months ago ;-)
> 

Adding such a statement would at least make it clear to a reviewer that it 
was the intent of the author to comply with the guidelines.  However, I 
think that having a section on key management claims would make it easier 
for a reviewer to examine a document and find the material relating to the guidelines. 

For example, EAP method documents are required to include a security 
claims section that is typically short since it typically just references 
material already in the document or in external references.  Similarly a 
Key Management Claims section might make it easier for a reviewer.  Such a 
section might look like this:

"4.1.  Key Management Claims

   AAA Key Management requirements  are defined in [RFCXXXX].  This
   document claims to meet the following  requirements, as described 
   below: 

   Cryptographic Algorithm Independence:  Yes (See Sections 2.1, 2.3)
   Strong, fresh session keys: Yes (See Section 3.1, 3.4)
   Key scope: Yes (See Section 4.5)
   Replay protection: Yes (See Section 5.1)
   Authentication: Yes (See Section 2.6)
   Authorization: Yes (See Section 2.7)
   Key confidentiality: Yes (See Section 2.8)
   Confirmed ciphersuite selection: Partial (See Section 2.9)
   Key naming: Yes (See Section 6.1)
   Domino Effect: Yes (See Section 8.1)
   Key context binding: Yes (See Section 7.2)
   Confidentiality of Identity: No
   Authorization Restriction: Partial (See Section 6.2)"

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Nov 2006 18:51:21 -0500

As an individual I would prefer not having this level of formality.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 08 Nov 2006 01:21:03 -0800

I agree that such a section on key management claims makes sense, but 
that should go in security considerations.  I have some of the 
reservations that Sam has, but this is a necessary evil, IMO.

Lakshminath

At 03:08 PM 11/7/2006, Bernard Aboba wrote:

<snip>