Subject: [Dime] Review of draft-ietf-dime-local-keytran-03

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 6 May 2010 20:42:50 -0700

I think this specification is useful.    Here are some  comments:

1.       Key types -  The document lists USRK and DSUSRK as key types.
These are a class of keys and do not necessarily refer to a specific
application.  How would one represent different USRKs for different
usages?  Are rMSK and rRK examples of USRKs?  

2.       IN 3.1.2 and 3.1.3 it mentions that this depends upon the link
layer.  Could these keys be used for other purposes  (say at the IP
layer)?  If they could perhaps it would be better to say "usage" instead
of link layer.   If not then the current text is fine.  

3.       The key lifetime is specified from when the key is first used.
In this case if there is a long period of time between when the key is
generated and used then the key life time may exceed the lifetime of the
root key.   This indicates that the key generator can't determine when a
particular set of keys  will expire.  Is this what is desired?  Why not
start the timer from when it is received?  

4.       Key-SPI - is there a particular example for a usage of this?
How does it differ from key ID?  

5.       Section 3.1 states certain attributes as optional it seems that
key name is also optional so it seems the text is a bit misleading.
You might also mention that additional attributes can be defined to
pertain to a key (I think this is the case from the  *[ AVP ]

Joe

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 7 May 2010 16:13:25 +0700

Joseph Salowey  <mailto:[mailto://[email-masked]%5d>
[mailto://[email-masked]] writes:

1.       Key types -  The document lists USRK and DSUSRK as key types.
These are a class of keys and do not necessarily refer to a specific
application.  How would one represent different USRKs for different usages?
Are rMSK and rRK examples of USRKs?  

Any recommendations?

2.       IN 3.1.2 and 3.1.3 it mentions that this depends upon the link
layer.  Could these keys be used for other purposes  (say at the IP layer)?
If they could perhaps it would be better to say "usage" instead of link
layer.   If not then the current text is fine.  

Good idea, I can make that change (see below).

3.       The key lifetime is specified from when the key is first used.   In
this case if there is a long period of time between when the key is
generated and used then the key life time may exceed the lifetime of the
root key.   This indicates that the key generator can't determine when a
particular set of keys  will expire.  Is this what is desired?  Why not
start the timer from when it is received?  

OK

4.       Key-SPI - is there a particular example for a usage of this?   How
does it differ from key ID?  

Check
<https://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/>
https://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/.  In
fact, this AVP was added in response to a request from the authors of that
draft, so that they remove the key-related stuff from that document (which
is, unfortunately, yet to be updated).

5.       Section 3.1 states certain attributes as optional it seems that key
name is also optional so it seems the text is a bit misleading.   

Good point.  How's this:

   The Key AVP (AVP Code <AC1>) is of type Grouped [RFC3588] It contains the
type and 

   keying material and optionally an indication of the usable lifetime of
the key, the 

   name of the key and a SPI with which the key is associated.

You might also mention that additional attributes can be defined to pertain
to a key (I think this is the case from the  *[ AVP ]

OK

Joe

---

From: Tom Taylor <[email-masked]>
Date: Sun, 09 May 2010 19:24:54 -0400

Below.

Glen Zorn wrote:
>[GZ] Any recommendations?

[PTT] Looking at that section it seemed natural to me to specify applicable 
domain and key usage as separate attributes.

...

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 12 May 2010 15:46:42 -0700

> -----Original Message-----
> From: Glen Zorn [mailto:[email-masked]]
> Sent: Friday, May 07, 2010 2:13 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: RE: [Dime] Review of draft-ietf-dime-local-keytran-03
> 
> Joseph Salowey [mailto://[email-masked]]
> <mailto:[mailto://[email-masked]%5d>  writes:
> 
> 
> 

[Joe] Right now key type is representing both a class of key
(USRK,DSUSRK,etc) and a specific application and usage of key material
(rMSK and rRK).    For example an rRK may either be a USRK or a DSUSRK.
There are several ways you could do this differently.

a) Flatten out the space - get rid of USRK, DSUSRK - include rRK, rMSK,
MSK, DSRK, IKEv2 PSK.  Add a domain AVP that would be included if the
key is a DSRK or an instance of a DSUSRK.  This would contain the domain
that was used in the key derivation (perhaps this is always know, but
maybe a server can server more than one domain).  

b) Keep the key type to indicate the class of the key and have a new
attribute indicate the application and specific type.  The class would
indicate what other attributes would be required in the group.  For
example, IKE keys would have an SPI, DSUSRKs a domain etc.  The classes
might be USRK, DSUSRK, MSK, IKE-PSK,... Another attribute would indicate
the specific application for the key. 

I think b is too complex.  I'd suggest modifying the key Type section as
follows:

"3.1.1. Key-Type AVP

   The Key-Type AVP (AVP Code <AC2>) is of type Enumerated and signifies
   the type of the key being sent.  The following values are defined in
   this document:

   MSK (0)
      The EAP Master Session Key [RFC3748].

   DSRK (1)
      A Domain-Specific Root Key [RFC5295].  If the domain of the key is
not known through other means then the Key AVP MUST contain a Key-Domain
AVP.  

   rRK (2)
      A reauthentication Root Key [RFC5296].  If the rRK is derive from
a DSRK and the domain of the key is not known through other means then
the Key AVP MUST contain a Key-Domain AVP.  

   rMSK (3)
      A reauthentication Master Session Key [RFC5296]. If the rMSK is
derive from a DSRK and the domain of the key is not known through other
means then the Key AVP MUST contain a Key-Domain AVP.  

   ikev2-psk(4)

	A pre-shared key for use in IKE-V2 key exchange
[draft-ietf-dime-ikev2-psk-diameter]

   If additional values are needed, they are to be assigned by IANA
   according to the policy stated in Section 5.2"

Also it may make sense to define a key-domain AVP assuming that it is
possible that the domain of the key is ambiguous:

" 3.1.6  Key-Domain

   The Key-Domain AVP (AVP Code <AC6>) is of type UTF8String and
contains the domain name associated with the key.  "

> How does it differ from key ID?
https://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/
> <https://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/>
.
> In fact, this AVP was added in response to a request from the authors
of
> that draft, so that they remove the key-related stuff from that
document
> (which is, unfortunately, yet to be updated).
> 
[Joe] The draft should probably include reference to this work.

>    The Key AVP (AVP Code <AC1>) is of type Grouped [RFC3588] It
contains
> the type and
[Joe] Good

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 13 May 2010 12:29:19 +0700

> maybe a server can server more than one domain).

Tom Taylor mentioned this as well but I am still puzzled by it: in what
scenario could this occur?  AFAIK all the keys are bound to a particular
session which is itself bound to a particular access point.  What am I
missing?

...

> [Joe] The draft should probably include reference to this work.

OK.  BTW, I apparently misspoke: draft-ietf-dime-ikev2-psk-diameter actually
was updated to remove the key-related stuff & reference our draft some time
ago.  Sorry for any confusion!

...

---

From: Tom Taylor <[email-masked]>
Date: Thu, 13 May 2010 09:01:23 -0400

Below.

> session which is itself bound to a particular access point.  What am I
[PTT]
OK, this is one for the architecture to answer. I'll review the different 
interfaces to see if there is a case of anticipatory keying that isn't bound as 
tightly as you suggest. At the very least, I don't think the keys passed to a 
local ER server would be bound to a particular access point, but they may indeed 
be bound to a particular session, in some sense of session.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 13 May 2010 09:35:04 -0700

> tightly as you suggest. At the very least, I don't think the keys
passed
> to a
> local ER server would be bound to a particular access point, but they
may
> indeed

[Joe] I can't think of a reason why the domain wouldn't already be known
to the session.  I'd be okay with leaving the domain out until there is
a use-case for it.

---

From: jouni korhonen <[email-masked]>
Date: Tue, 18 May 2010 00:09:41 +0300

<chair mode>
So, everybody happy with Joe's proposal of leaving the domain out? If so, a new revision would be needed so that we can get this sorted out and successfully conclude the WGLC.

- Jouni

On May 13, 2010, at 7:35 PM, Joseph Salowey (jsalowey) wrote:

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

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 18 May 2010 10:47:37 +0900

Hi,

Since the Key AVP's ABNF allows other AVPs anyway ( * [AVP ] ), it will
be easy to add the domain, should one encounter a situation where it is
not the same as the Orinigin-Realm of the message... So, I think is it
not a problem to not include the domain here.

My 2 cents,
Sebastien.

Le 18/05/2010 06:09, jouni korhonen a écrit :
>>>> Tom Taylor mentioned this as well but I am still puzzled by it: in
>>>>         
>> what
>>     
>>>> scenario could this occur?  AFAIK all the keys are bound to a
>>>>         
>> particular
>>     
>>>> session which is itself bound to a particular access point.  What am
>>>>         
>> I
>>     
>>>> missing?
>>>>
>>>> ...
>>>>         
>>> [PTT]
>>> OK, this is one for the architecture to answer. I'll review the
>>>       
>> different
>>     

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 24 May 2010 08:17:55 +0700

jouni korhonen [mailto:[email-masked]] writes:

> <chair mode>
> So, everybody happy with Joe's proposal of leaving the domain out? If
> so, a new revision would be needed so that we can get this sorted out
> and successfully conclude the WGLC.

<editor mode> 
Awaiting editing instructions from the Chairs...

...

---

From: jouni korhonen <[email-masked]>
Date: Mon, 24 May 2010 15:08:45 +0300

We'll go for Joe's proposal and leave the domain out.

- Jouni