IETF Logo Mail Archive

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

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Fri, 07 May 2010 03:43 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 D30F33A68EE for <dime@core3.amsl.com>; Thu, 6 May 2010 20:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.163
X-Spam-Level:
X-Spam-Status: No, score=-9.163 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_40=-0.185, HTML_MESSAGE=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 OZki6gvcEuZ6 for <dime@core3.amsl.com>; Thu, 6 May 2010 20:43:06 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 9BE663A67B2 for <dime@ietf.org>; Thu, 6 May 2010 20:43:06 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAKoo40urR7Hu/2dsb2JhbACBP5AajDNxojWZQYUTBINB
X-IronPort-AV: E=Sophos; i="4.52,345,1270425600"; d="scan'208,217"; a="126050878"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 07 May 2010 03:42:54 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o473gs72000569 for <dime@ietf.org>; Fri, 7 May 2010 03:42:54 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 May 2010 20:42:53 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAED97.6005DD5D"
Date: Thu, 06 May 2010 20:42:50 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50A43AE83@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-ietf-dime-local-keytran-03
Thread-Index: Acrtl12sPac6N9K9TPSXykaaNEhQSw==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: dime@ietf.org
X-OriginalArrivalTime: 07 May 2010 03:42:53.0985 (UTC) FILETIME=[5FFEA910:01CAED97]
Subject: [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 03:43:10 -0000

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

v2.23.0 | Report a Bug | By Email