Re: [Dime] New version of draft-wu-dime-local-keytran
Qin Wu <sunseawq@huawei.com> Wed, 09 December 2009 06:49 UTC
Return-Path: <sunseawq@huawei.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 D56B03A6879 for <dime@core3.amsl.com>; Tue, 8 Dec 2009 22:49:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.243
X-Spam-Level:
X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[AWL=1.356, 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 aKzVLnLBoMZM for <dime@core3.amsl.com>; Tue, 8 Dec 2009 22:49:31 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 5D4C43A67A2 for <dime@ietf.org>; Tue, 8 Dec 2009 22:49:31 -0800 (PST)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUD00LHSHM674@szxga01-in.huawei.com> for dime@ietf.org; Wed, 09 Dec 2009 14:49:18 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUD00JSYHM6CD@szxga01-in.huawei.com> for dime@ietf.org; Wed, 09 Dec 2009 14:49:18 +0800 (CST)
Received: from w53375 ([10.164.12.66]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUD007I8HM6OL@szxml04-in.huawei.com> for dime@ietf.org; Wed, 09 Dec 2009 14:49:18 +0800 (CST)
Date: Wed, 09 Dec 2009 14:49:18 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Sebastien Decugis <sdecugis@nict.go.jp>
Message-id: <030901ca789b$bb071cf0$420ca40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <01ce01ca7842$352c49b0$9f84dd10$@net> <4B1F0642.2090604@nict.go.jp> <02a301ca7881$73bf1f60$420ca40a@china.huawei.com> <4B1F2A20.9060407@nict.go.jp>
Cc: dime@ietf.org
Subject: Re: [Dime] New version of draft-wu-dime-local-keytran
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, 09 Dec 2009 06:49:34 -0000
Hi,Sebastien: ----- Original Message ----- From: "Sebastien Decugis" <sdecugis@nict.go.jp> To: "Qin Wu" <sunseawq@huawei.com> Cc: "Glen Zorn" <gwz@net-zen.net>; <dime@ietf.org> Sent: Wednesday, December 09, 2009 12:40 PM Subject: Re: [Dime] New version of draft-wu-dime-local-keytran > Hi Qin, > >> - USRK (2) & DSUSRK (5): RFC5295 defines a generic algorithm to derive >> usage-specific keys. The definition alone is not sufficient to create >> keying material: we need the usage itself to define the missing parts. >> [Qin]: The usages for USRK and DSUSRK have been defined in the section >> 4.2 of draft-ietf-hokey-key-mgm-13. >> That is to say, USRK and DSUSRK may be derived in the EAP/AAA server >> and transported in the message to the same USR-KH. >> And then DSUSRK can be further transported from USR-KH to DSUSR-KH. > Sorry, I have difficulties to express my idea clearly. What I mean is > that for example the definition of USRK is just a generic method to > derive a class of keys, we will never have a "USRK key" without any > precision on the usage it-self (usage as in the "US" part of USRK). On > the other hand, rRK is an instance of this class, where the algorithm > parameters are specified in the ERP document, and we can effectively > have to transport rRK keys. As I understand draft-ietf-hokey-key-mgm-13, > that document is also talking about generic mechanisms, that can be > applied for instance to the ERP specific usage. [Qin]: According to draft-ietf-hokey-key-mgm-13, USRK and DSUSRK can be used in Key Distribution Exchange Scenarios, that is to say EAP based key transportation is not limited for ERP specific usage. Also I am not saying using of USRK and DSUSRK in the ERP scenario. I am wondering whether USRK and DSUSRK transportation can be used for other non ERP specific cases like Key Distribution Exchange Scenarios. > Does this make my point more understandable? > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >
- [Dime] New version of draft-wu-dime-local-keytran Glen Zorn
- Re: [Dime] New version of draft-wu-dime-local-key… Sebastien Decugis
- Re: [Dime] New version of draft-wu-dime-local-key… Sebastien Decugis
- Re: [Dime] New version of draft-wu-dime-local-key… Glen Zorn
- Re: [Dime] New version of draft-wu-dime-local-key… Qin Wu
- Re: [Dime] New version of draft-wu-dime-local-key… Sebastien Decugis
- Re: [Dime] New version of draft-wu-dime-local-key… Qin Wu
- Re: [Dime] New version of draft-wu-dime-local-key… Sebastien Decugis
- Re: [Dime] New version of draft-wu-dime-local-key… Qin Wu