[Dime] Quick look at draft-ietf-dime-local-keytran-00.txt
"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Mon, 11 January 2010 13:21 UTC
Return-Path: <hannes.tschofenig@nsn.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 AE4B93A69FD for <dime@core3.amsl.com>; Mon, 11 Jan 2010 05:21:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.232
X-Spam-Level:
X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599]
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 0RdnkMxRmPsT for <dime@core3.amsl.com>; Mon, 11 Jan 2010 05:21:24 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 6EABB3A6930 for <dime@ietf.org>; Mon, 11 Jan 2010 05:21:23 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o0BDLJBA007137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Mon, 11 Jan 2010 14:21:19 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0BDLIHX032766 for <dime@ietf.org>; Mon, 11 Jan 2010 14:21:18 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 14:21:18 +0100
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: Mon, 11 Jan 2010 15:25:13 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45020B8289@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Quick look at draft-ietf-dime-local-keytran-00.txt
Thread-Index: AcqSwYGwXq8uKAvPTV2ZOoQkSOPjGA==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: dime@ietf.org
X-OriginalArrivalTime: 11 Jan 2010 13:21:18.0828 (UTC) FILETIME=[F5C672C0:01CA92C0]
Subject: [Dime] Quick look at draft-ietf-dime-local-keytran-00.txt
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: Mon, 11 Jan 2010 13:21:25 -0000
Hi Glen,
I thought I should take a look at the document to see where we are.
I have a few comments:
1) I don't think you need to introduce so many terms in the terminology
section but rather expand their first occurrence in the intro section.
Example:
"
The Diameter EAP application [RFC4072] defines the EAP-Master-
Session-Key and EAP-Key-Name AVPs for the purpose of transporting
cryptographic keying material derived during the execution of certain
EAP [RFC3748] methods (for example, EAP-TLS [RFC5216]). At most one
instance of either of these AVPs is allowed in any Diameter message.
However, recent work [RFC5295] has specified methods to derive other
keys from the keying material created during EAP method execution
that may require transport in addition to the MSK. In addition, ERP
[RFC5296] specifies new keys that may need to be transported between
Diameter nodes.
This note specifies a set of AVPs allowing the transport of multiple
cryptographic keys in a single Diameter message.
"
I would just expend the terms "ERP", "MSK", and "EAP" in this section
and avoid listing them in the terminology section.
Also other terms do not appear too often in the document other than in
Section 3.1.1.
Example: rRK
Just a matter of style -- not terribly important.
2) I think you only define some AVPs and hence you don't need to say
anything about the usage of these AVPs in certain Diameter messages.
Example: I would remove the following sentence from Section 3.1.1:
"
The Key-Type AVP MAY be included in
a DER command as a signal that a certain type of key is required in
the response (e.g., to support ERP).
"
3) Key-Lifetime
You made a note that I did not quite understand:
"
NOTE:
Applications using this value SHOULD consider the beginning of the
lifetime to be the point in time when the keying material is first
used.
"
What is the reasoning behind this statement? Wouldn't you leave such
decisions to the specific document that describes how these AVPs are
used?
4) I believe that the AVP occurrence table is not useful for this
document. I suggest to delete it.
You would want to put one in a document describing how these AVPs are,
for example, used with ERP.
5) Security Considerations
Even though the security considerations are not dramatically different
to Diameter EAP I would suggest to discuss the topics. I suggest to copy
text.
6) Section 6.2 - IANA Registry for AVP values
The text is a bit incomplete as you might want to tell IANA that you
want to create a new registry here. You have indicated the policy for
adding new values but you might want to also state whether you allow
values from the registry to be deleted, replaced, modified or depicated.
Do you think that FCFS is a good policy here? Everyone can come along
and put some really bogus stuff into this registry. Would Expert Review
be too much here?
Otherwise I have no other comments and I believe we should start a WGLC
very soon.
Ciao
Hannes
- [Dime] Quick look at draft-ietf-dime-local-keytra… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Dime] Quick look at draft-ietf-dime-local-ke… Glen Zorn