Subject: [Gen-art] Gen-ART Last Call Review of Document draft-housley-aaa-key-mgmt-06.txt

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Thu, 11 Jan 2007 13:49:58 -0600

Russ/Bernard,

I have been selected as the General Area Review Team (Gen-ART) 
reviewer for this draft (for background on Gen-ART, please see 
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). 

Please resolve these comments along with any other Last Call 
comments you may receive. 

Document: draft-housley-aaa-key-mgmt-06.txt

	Guidance for AAA Key Management

Reviewer: Eric Gray
Review Date: 2007.01.11
IETF LC End Date: 2007.01.11

Summary: 

This document is nearly ready for publication as a BCP RFC.  
Minor comments below may be incorporated at the author's or
AD's discretion.  A minor issue may need to be answered, or
clarified, as well.

Comments: 

Minor Issue - there is an interesting statement made as a 
final sentence in the next-to-last paragraph of page 6.
It reads - 

"A party has access to a particular key if it has access to 
 all of the secret information needed to derive it."

Can you clarify the causality associated with this logical
expression?  It is likely that a party can derive a key if
"[the party] has access to all of the secret information 
needed to derive [the key]."  This is particularly true if
we only treat as "secret" anything that a party might not
know.  In other words, if a party has all required input
data as well as the key derivation algorithm, clearly the
party can derive the key.

But are you making a statement about entitlement - i.e - are 
you saying it is both necessary and sufficient that a party 
has legitimate access to secret information (used to derive 
a key) as a condition of being allowed access to a key?  Or 
are you just making the simple observation that a key may be 
known to any party having all of the information necessary to 
derive the key on their own - without specifically intending 
to rule on whether or not it is appropriate to simply be given 
the key?

If the former, "if" should be changed to "if and only if" -
otherwise, I am not sure the statement adds any value.

As an observation from a non-expert, I find it difficult to
understand why it should be the former - if that is indeed 
your intent.

This same statement is also repeated under "Limit key scope"
(p9), last sentence of the first paragraph.

=============================================================
 
Minor comment - next to last paragraph on page 2, it may be
a good idea to expand "IETF working groups" (first - long -
sentence) to be more inclusive.  This might be accomplished
by changing the sentence from -

"Given the complexity and difficulty in designing secure, 
 long-lasting key management algorithms and protocols by 
 experts in the field, it is almost certainly inappropriate 
 for IETF working groups without deep expertise in the area 
 to be designing their own key management algorithms and 
 protocols based on Authentication, Authorization and
 Accounting (AAA) protocols."

- to - 

"It is complex and difficult to design robust key management
 algorithms - even by people with expertise in the field. 
 Given this fact, it is almost certainly inappropriate for
 IETF working groups - and other standards development bodies
 - to be designing their own key management algorithms and 
 protocols based on Authentication, Authorization and
 Accounting (AAA) protocols.  This is especially true if the
 group in question does not include people having the needed
 expertise in security algorithms and protocols."

(Actual wording is entirely up to the author, however, the
 original sentence is fairly complex and might be interpreted
 to _only_ apply to IETF working groups)
______________________________________________________________

Minor Comment - In the definition of "Key Wrap" (p4), you also 
include a definition of the acronym "KEK."  This term is not
used through-out the remainder of the document.  Consequently,
I wonder why this definition is provided.  If it is intended
to be used by other document writers, should it be called out
as a separate definition?
______________________________________________________________

Minor Comment - Under "Cryptographic algorithm independent"
(p8), the third sentence in the first paragraph (lines 4, 5)
might be reworded to clarify that you're not describing the 
same algorithm in both cases.  For example, change from -

"The ability to negotiate the use of a particular 
 cryptographic algorithm provides resilience against 
 compromise of a particular cryptographic algorithm."

- to - 

"The ability to negotiate the use of a particular 
 cryptographic algorithm provides resilience against 
 compromise of one or more other cryptographic 
 algorithms."
______________________________________________________________

NIT - Under "Strong, fresh session keys" (p9), the second
sentence of the last paragraph should read - 

"Multiple session keys may be derived ..."  ("be" added)
______________________________________________________________

NIT - Under "Peer and authenticator authorization", second
paragraph, second sentence (p11) should read - 

"Once the AAA key ... these parties should hold a common 
 view of the authorizations associated with the other
 parties."  ("with" added)

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Jan 2007 12:33:15 -0500

Eric:

Thanks or your careful reading of the document.  See below.

>understand why it should be the former - if that is indeed

I suggest:
A party is considered to have access to a particular key if
and only if the party has access to all of the secret
information needed to derive the key.

>(p9), last sentence of the first paragraph.

We'll use the same words in both places.

I suggest:
It is complex and difficult to design robust key management algorithms
and protocols, even by people with expertise in the field.  Given this fact,
it is most often inappropriate for IETF working groups and other
standards development organizations (SDOs) to be designing their own key
management algorithms and protocols based on Authentication, Authorization
and Accounting (AAA) protocols.  This is especially true for groups that do
not include people with the appropriate experience.  These guidelines apply
to documents requesting publication as IETF RFCs.  However, these guidelines
will also be useful to other SDOs that specify AAA key management that depend
on IETF specifications for protocols such as EAP [RFC3748], RADIUS [RFC2865],
and Diameter [RFC3588].

Okay.  I'll drop "(KEK)" from the end of the definition.

I suggest:
The ability to negotiate the use of a particular cryptographic algorithm
from a set of cryptographic algorithms provides resilience against
compromise of one or more cryptographic algorithms.

Fixed.

Fixed.

Russ

---

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Mon, 22 Jan 2007 16:50:02 -0600

Russ,

	Your wording suggestions are fine with me.

--
Eric 

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]] 
> Sent: Monday, January 22, 2007 12:33 PM
> To: Eric Gray (LO/EUS); Bernard Aboba
> Cc: [email-masked]; Sam Hartman
> Subject: Re: Gen-ART Last Call Review of Document 
> draft-housley-aaa-key-mgmt-06.txt
> 
> Eric:
>