Subject: [Dime] Quick look at draft-ietf-dime-local-keytran-00.txt

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 11 Jan 2010 15:25:13 +0200

Hi Glen, 

I thought I should take a look at the document to see where we are. 

I have a few comments:

1) I don't think you need to introduce so many terms in the terminology
section but rather expand their first occurrence in the intro section. 

Example:

"
   The Diameter EAP application [RFC4072] defines the EAP-Master-
   Session-Key and EAP-Key-Name AVPs for the purpose of transporting
   cryptographic keying material derived during the execution of certain
   EAP [RFC3748] methods (for example, EAP-TLS [RFC5216]).  At most one
   instance of either of these AVPs is allowed in any Diameter message.

   However, recent work [RFC5295] has specified methods to derive other
   keys from the keying material created during EAP method execution
   that may require transport in addition to the MSK.  In addition, ERP
   [RFC5296] specifies new keys that may need to be transported between
   Diameter nodes.

   This note specifies a set of AVPs allowing the transport of multiple
   cryptographic keys in a single Diameter message.
"

I would just expend the terms "ERP", "MSK", and "EAP" in this section
and avoid listing them in the terminology section.

Also other terms do not appear too often in the document other than in
Section 3.1.1. 

Example: rRK 

Just a matter of style -- not terribly important. 

2) I think you only define some AVPs and hence you don't need to say
anything about the usage of these AVPs in certain Diameter messages. 

Example: I would remove the following sentence from Section 3.1.1: 
"
The Key-Type AVP MAY be included in
   a DER command as a signal that a certain type of key is required in
   the response (e.g., to support ERP). 
"

3) Key-Lifetime

You made a note that I did not quite understand:

"
   NOTE:
      Applications using this value SHOULD consider the beginning of the
      lifetime to be the point in time when the keying material is first
      used.
"

What is the reasoning behind this statement? Wouldn't you leave such
decisions to the specific document that describes how these AVPs are
used? 

4) I believe that the AVP occurrence table is not useful for this
document. I suggest to delete it. 
You would want to put one in a document describing how these AVPs are,
for example, used with ERP. 

5) Security Considerations

Even though the security considerations are not dramatically different
to Diameter EAP I would suggest to discuss the topics. I suggest to copy
text. 

6) Section 6.2 - IANA Registry for AVP values

The text is a bit incomplete as you might want to tell IANA that you
want to create a new registry here. You have indicated the policy for
adding new values but you might want to also state whether you allow
values from the registry to be deleted, replaced, modified or depicated.

Do you think that FCFS is a good policy here? Everyone can come along
and put some really bogus stuff into this registry. Would Expert Review
be too much here? 

Otherwise I have no other comments and I believe we should start a WGLC
very soon. 

Ciao
Hannes

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 28 Jan 2010 15:24:38 +0700

Tschofenig, Hannes (NSN - FI/Espoo) [mailto://[email-masked]]

> Just a matter of style -- not terribly important.

Glad to hear that -- since this was done purposely just to avoid having to
do what you suggest I'm not too thrilled with this idea ;-).

>    the response (e.g., to support ERP).

OK

> decisions to the specific document that describes how these AVPs are

Do we really want the same AVP to have different semantics in different
apps?

> document. I suggest to delete it.

OK

> to Diameter EAP I would suggest to discuss the topics. I suggest to copy

OK

> values from the registry to be deleted, replaced, modified or depicated.

OK.

> 
> 
> Do you think that FCFS is a good policy here? 

Don't really care.

> Everyone can come along
> and put some really bogus stuff into this registry. 

How bogus could it be?

> Would Expert Review

Fine w/me.

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime