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

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Wed, 12 May 2010 22:47 UTC

Return-Path: <jsalowey@cisco.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1FC23A682E for <dime@core3.amsl.com>; Wed, 12 May 2010 15:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.905
X-Spam-Level:
X-Spam-Status: No, score=-8.905 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2byBe2-8AGBr for <dime@core3.amsl.com>; Wed, 12 May 2010 15:47:07 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0A8E33A6942 for <dime@ietf.org>; Wed, 12 May 2010 15:46:55 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAIfM6kurR7Ht/2dsb2JhbACeJ3GjYplThRIEg0A
X-IronPort-AV: E=Sophos;i="4.53,217,1272844800"; d="scan'208";a="528847469"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 12 May 2010 22:46:45 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4CMkjTT003946; Wed, 12 May 2010 22:46:45 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 15:46:45 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 May 2010 15:46:42 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50A554125@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <00b701caedc5$92e4d150$b8ae73f0$@net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Dime] Review of draft-ietf-dime-local-keytran-03
Thread-Index: Acrtl12sPac6N9K9TPSXykaaNEhQSwALJAvAAQtx3wA=
References: <AC1CFD94F59A264488DC2BEC3E890DE50A43AE83@xmb-sjc-225.amer.cisco.com> <00b701caedc5$92e4d150$b8ae73f0$@net>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: Glen Zorn <gwz@net-zen.net>
X-OriginalArrivalTime: 12 May 2010 22:46:45.0233 (UTC) FILETIME=[FF78C610:01CAF224]
Cc: dime@ietf.org
Subject: Re: [Dime] Review of draft-ietf-dime-local-keytran-03
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2010 22:47:10 -0000

> -----Original Message-----
> From: Glen Zorn [mailto:gwz@net-zen.net]
> Sent: Friday, May 07, 2010 2:13 AM
> To: Joseph Salowey (jsalowey)
> Cc: dime@ietf.org
> Subject: RE: [Dime] Review of draft-ietf-dime-local-keytran-03
> 
> Joseph Salowey [mailto://jsalowey@cisco.com]
> <mailto:[mailto://jsalowey@cisco.com%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