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

["Joseph Salowey (jsalowey)" <[e-mail]>]

> -----Original Message-----
> From: Glen Zorn [mailto:[e-mail]]
> Sent: Friday, May 07, 2010 2:13 AM
> To: Joseph Salowey (jsalowey)
> Cc: [e-mail]
> Subject: RE: [Dime] Review of draft-ietf-dime-local-keytran-03
> 
> Joseph Salowey [mailto://[e-mail]]
> <mailto:[mailto://[e-mail]%5d>  writes:
> 
> 
> 
> 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?
> 
> Any recommendations?

[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.  "

> 
> 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).
> 
[Joe] The draft should probably include reference to this work.

> 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.
> 
[Joe] Good

> 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