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

"Glen Zorn" <gwz@net-zen.net> Fri, 07 May 2010 09:15 UTC

Return-Path: <gwz@net-zen.net>
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 947E43A6CAA for <dime@core3.amsl.com>; Fri, 7 May 2010 02:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.141
X-Spam-Level:
X-Spam-Status: No, score=0.141 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619]
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 mlE9OjwZnnXk for <dime@core3.amsl.com>; Fri, 7 May 2010 02:14:53 -0700 (PDT)
Received: from p3plsmtpa01-04.prod.phx3.secureserver.net (p3plsmtpa01-04.prod.phx3.secureserver.net [72.167.82.84]) by core3.amsl.com (Postfix) with SMTP id 96ECF3A6999 for <dime@ietf.org>; Fri, 7 May 2010 02:14:29 -0700 (PDT)
Received: (qmail 16488 invoked from network); 7 May 2010 09:14:15 -0000
Received: from unknown (115.67.96.71) by p3plsmtpa01-04.prod.phx3.secureserver.net (72.167.82.84) with ESMTP; 07 May 2010 09:14:09 -0000
From: Glen Zorn <gwz@net-zen.net>
To: "'Joseph Salowey (jsalowey)'" <jsalowey@cisco.com>
References: <AC1CFD94F59A264488DC2BEC3E890DE50A43AE83@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50A43AE83@xmb-sjc-225.amer.cisco.com>
Date: Fri, 07 May 2010 16:13:25 +0700
Organization: Network Zen
Message-ID: <00b701caedc5$92e4d150$b8ae73f0$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B8_01CAEE00.3F43A950"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acrtl12sPac6N9K9TPSXykaaNEhQSwALJAvA
Content-Language: en-us
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: Fri, 07 May 2010 09:15:06 -0000

Joseph Salowey  <mailto:[mailto://jsalowey@cisco.com%5d>
[mailto://jsalowey@cisco.com] 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?

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