From sunseawq@huawei.com Tue Sep 1 19:33:02 2009 Return-Path: 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 B3B243A69FC for ; Tue, 1 Sep 2009 19:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=1.307, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6] 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 OW6wZRsV-qXP for ; Tue, 1 Sep 2009 19:33:01 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E432728C8AA for ; Tue, 1 Sep 2009 19:32:17 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPB00GTIO9RRH@szxga04-in.huawei.com> for dime@ietf.org; Wed, 02 Sep 2009 10:29:51 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPB00LPBO9RL9@szxga04-in.huawei.com> for dime@ietf.org; Wed, 02 Sep 2009 10:29:51 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPB00KXOO9Q2G@szxml04-in.huawei.com> for dime@ietf.org; Wed, 02 Sep 2009 10:29:51 +0800 (CST) Date: Wed, 02 Sep 2009 10:29:51 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <00a601ca2b75$40358de0$260ca40a@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.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <00e701ca2784$6b664030$260ca40a@china.huawei.com> <4A974A80.8020807@nict.go.jp> <00e901ca2a02$8ceaa6d0$260ca40a@china.huawei.com> <4A9B7878.4020001@nict.go.jp> <013501ca2ab0$f16354f0$260ca40a@china.huawei.com> <4A9CA29E.4010801@nict.go.jp> Cc: Glen Zorn , dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 02:33:02 -0000 Hi, Sebastien: Thank for your perspective on this AVP issue. :) Please see my reply below! ----- Original Message ----- From: "Sebastien Decugis" To: "Qin Wu" Cc: Sent: Tuesday, September 01, 2009 12:27 PM Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft > Hi Qin, > >> However we put the key type as the first nested AVP and define it as eNumerated type, >> it does not take time to interpret this first inner AVP of one grouped AVP, i.e., parsing is >> not so deep as you concerned. What do you think of it? :) >> > Yes, it's right, if the key type is a fixed position AVP, it is not much > more work than having the information in the avp header. It just takes a > little more space in the message, [Qin]: Yes, it does not take much work. >but if there are good reasons to > define only one grouped AVP, I guess the additional space is not really > an issue. [Qin]: The reason is to enable the transport of 2 or more keys in the same message. The definition of the EAP-Master=Key & EAP-Key-Name AVPs is predicated upon the fact that there is at most one key in a given message. Also this generic approach is not specific to the ERP. >>> It is not clear to me what should be the behavior in such case when an >>> intermediary node detects a problem in an answer message, to avoid >>> breaking application synchronization between the client and the >>> end-server... >>> >> >> [Qin]: In my understanding, if the intermediary node, e.g.,local server detects >> the inside AVP is not validated, the intermediary node can simply notify the >> authenticator of the results by encapsulating the EAP-Failure in the AAA message >> and sending to the authenticator. or ask the home server to re-transport the relevant >> key materials. >> > I see. In any case, the NAS probably have to validate the key, so I > still believe the validation in the intermediary node is not necessary. [Qin]: The problem is when the NAS recieves MSK or rMSK, the NAS can not judge whether MSK or rMSK is validated. because the NAS has no root key. Only intermediary node and End-Server can tell whether MSK or rMSK is validated. What the NAS can do is format checking, e.g., whether the lifetime of MSK is more than 0 or something else. >>> In my understanding the purpose of defining a "generic" approach is that >>> what we define should be re-usable for transport of other keys in future >>> usages. We don't know yet the semantics of these key, and the meta-data >>> that will be needed along them. That is IMHO a good reason to have a >>> different AVP code for different keys, while the AVPs inside the group >>> can be reused whenever possible (key name, key lifetime, and so on...). >>> >> >> [Qin] As described in the draft-ietf-hokey-key-mgm-09, actually we have already specified such future usages for key transportation, i.e., >> In these scenarios, USRK,DSRK, DSUSRK are all EAP based keys and should be defined. >> > But the usages you are talking of here are not defined yet, right? And > we are only talking about keys derived from EAP EMSK, following rfc5295 > method. We may also have to transport keys in different contexts. In > some future usages of the key material, additional metadata might be > needed (a version of the key derivation algorithm for example). Of > course new AVPs can be defined inside the [ * AVP ] rule of the grouped > AVP ABNF, but I think that having a clear definition of the ABNF for > each key usage is easier to understand and more explicit -- and we don't > implicitely imply the ABNF for the group from the value of the Key-Type > AVP in that case. [Qin]: Yes, in my understanding, all these Scenarios can be taken as a usage which has already defined in the draft-ietf-hokey-key-mgm-09. The keys defined in the draft-ietf-hokey-key-mgm-09 are all derived from EMSK, conforming to rfc5295. As described in rfc5295, USRK is derived from EMSK, DSUSRK is derived from DSRK, so USRK and DSRK also can be transported from home server to the local server. Suppose USRK,DSRK and DSUSRK are all transported from home server to the local server, they all has the same destination,i.e., intermediary node.Since they have the same destination, it does not matter whether the key Type is in the grouped AVP. The intermediary node needs to parse them one by one. >> In two bootstrapping scenarios, DSRK and rMSK are both EAP based key and should be defined. >> Since all these keys are directly or indirectly derived from the same EMSK. I wonder is >>it necessary for us to define each grouped >> AVP for USRK, DSRK, DSUSRK, rMSK. >> > Because these keys are used differently, it seems to me logical to have > different AVP defined. But if other people prefer to define only one > container and put all the keys in the same one with an AVP inside to > distinguish between different types of keys, it is OK with me, I already > argued why I think the other possibility is better... [Qin]: Okay.:) >> [Qin]: The reasons to define only one AVP code for these keys are: >> 1. Save AVP code >> > The code space is 2^32, just for IETF... We will not run out of codes ^^. > >> 2. All these transported key materials derive from the same EMSK and are variants of EAP based key. >> Is it necessary for us to define separate AVP codes for them? >> > As I wrote before, the way these keys are used, as well as the node to > which they are destined, differ. That is a good reason IMHO. > In addition, if you want to defined a generic AVP, you don't want to > restrict to keys following the semantics you are describing here, do you? [Qin] Suppose the home server uses EAP method to export MSK and EMSK during the full EAP authentication, and then home server further derives DSRK, rRK,USRK and rMSK, in all these keys, MSK and rMSK has the same destination, authenticator. DSRK, rRK and USRK has the same destination, i.e., local server. when the home server needs to transport all these keys to the given local server and authenticator, I don't think we need to change the semantices the keys follow. >> 3. As described in draft-ietf-hokey-key-mgm-09, distribution of EAP based keys for handover are not >> only specific to the ERP scenarios or Re-authentication. There are other scenarios which this generic AVP >> can be applied as well. >> > Yes, from the beginning I agree that defining a generic way to transport > keys is a good idea... It's only the way that it is done that I am > discussing :) [Qin]: Okay. >> [Qin] Are you intending to use EAP-Master-Session-Key AVP to transport rMSK >> from the home Server to the Local Server, > Yes. >> In this sense, I am afraid you change the >> meaning of EAP-Master-Session-Key. > Well, basically, rMSK is an MSK also, I do not see a contradiction here. >> Because the local server will confuse whether >> the home Server is transporting MSK or rMSK to him. > First of all, it is not important for the local server, since it does > not use this key at all. [Qin]: It may introduce security threat. Because the authenticator has no root keys and can not judge the key is validated. Only local server can validate the rMSK based on DSRK. > Second, during a full EAP authentication, it is an MSK. During an > explicit bootstrapping ERP exchange, it is an rMSK. There is no > confusion here. [Qin]: In implicit bootstrapping aren't both the MSK & rMSK sent in the same message? How can you tell the difference between them at the NAS? >> because rMSK is derived from >> rRK while MSK is Exported by EAP method. Also when you use the EAP-Master-Session-Key >> to transport rMSK to the authencator, it will cause confusion of authenticator as well. :) >> > The authenticator uses the rMSK exactly in the same maneer as the MSK, > there is no point in distinguishing between them. >> In this way, it is better to distinguish between rMSK and MSK. >> > I don't think so... Why do you need to distinguish? Only the peer need > to know what key the authenticator will be using. And the peer always > know... [Qin]: See above. > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From sdecugis@nict.go.jp Tue Sep 1 20:34:32 2009 Return-Path: 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 B2E213A697C for ; Tue, 1 Sep 2009 20:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.059 X-Spam-Level: X-Spam-Status: No, score=-0.059 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_05=-1.11, HELO_EQ_JP=1.244] 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 prcQsBYEGtfT for ; Tue, 1 Sep 2009 20:34:31 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 4B5433A67E1 for ; Tue, 1 Sep 2009 20:34:31 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n823YRth001651; Wed, 2 Sep 2009 12:34:27 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n823YR0M006148; Wed, 2 Sep 2009 12:34:27 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n823YRuc006145; Wed, 2 Sep 2009 12:34:27 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 1385F16848; Wed, 2 Sep 2009 12:34:27 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 0D6B21682C; Wed, 2 Sep 2009 12:34:27 +0900 (JST) Message-ID: <4A9DE7BC.3030900@nict.go.jp> Date: Wed, 02 Sep 2009 12:34:20 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Qin Wu References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <00e701ca2784$6b664030$260ca40a@china.huawei.com> <4A974A80.8020807@nict.go.jp> <00e901ca2a02$8ceaa6d0$260ca40a@china.huawei.com> <4A9B7878.4020001@nict.go.jp> <013501ca2ab0$f16354f0$260ca40a@china.huawei.com> <4A9CA29E.4010801@nict.go.jp> <00a601ca2b75$40358de0$260ca40a@china.huawei.com> In-Reply-To: <00a601ca2b75$40358de0$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Glen Zorn , dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 03:34:32 -0000 Hi Qin, > [Qin]: The problem is when the NAS recieves MSK or rMSK, the NAS can not judge > whether MSK or rMSK is validated. because the NAS has no root key. Only intermediary node and End-Server > can tell whether MSK or rMSK is validated. What the NAS can do is format checking, e.g., > whether the lifetime of MSK is more than 0 or something else. > > [Qin]: It may introduce security threat. Because the authenticator has no > root keys and can not judge the key is validated. Only local server can validate > the rMSK based on DSRK. > > [Qin]: In implicit bootstrapping aren't both the MSK & rMSK sent in the same > message? How can you tell the difference between them at the NAS? > Implicit bootstrapping is not an ERP exchange, therefore it does cannot derive an rMSK (no SEQ available). Only MSK is sent in that case. In my understanding explicit bootstrapping is an ERP exchange between peer and home server; therefore the rMSK is derived from the rRK key (although I could not find this clarified in RFC5296 after a quick search). At the same time, the rDSRK is derived to be provided to local server. There is no relationship between this rMSK and rDSRK, so the local server would not be able to check the validity of the key material further than the NAS. Anyway, these details are far away from the initial discussion about what is best choice for distinguishing between two different keys: - an enumerated AVP "Key-Type" inside the grouped AVP, or - a different grouped AVP code for each key types. Except for the different parsing and different message size, those two possibilities are equivalent in terms of functionality it offers... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From root@core3.amsl.com Wed Sep 2 10:00:02 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1AB873A6CB9; Wed, 2 Sep 2009 10:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090902170002.1AB873A6CB9@core3.amsl.com> Date: Wed, 2 Sep 2009 10:00:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-19.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 17:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-19.txt Pages : 159 Date : 2009-09-02 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-02094856.I-D@ietf.org> --NextPart-- From vfajardo@research.telcordia.com Wed Sep 2 12:31:07 2009 Return-Path: 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 8EED928C989 for ; Wed, 2 Sep 2009 12:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.505, 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 0lbGkhlOCJNG for ; Wed, 2 Sep 2009 12:31:06 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id CA9ED28C983 for ; Wed, 2 Sep 2009 12:31:03 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n82JU9QL002981 for ; Wed, 2 Sep 2009 15:30:09 -0400 (EDT) From: "Victor Fajardo" To: References: <20090902170002.1AB873A6CB9@core3.amsl.com> In-Reply-To: <20090902170002.1AB873A6CB9@core3.amsl.com> Date: Wed, 2 Sep 2009 15:30:09 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <000c01ca2c03$c8e2c7f0$5aa857d0$@telcordia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acor7tsBWpCdjnXDSU+YyQaD7R773AAFJQZg Content-Language: en-us Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-19.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 19:31:07 -0000 This version increment includes: * Technical and Editorial comments from Glen (this spans a few threads in the list) * Comments from Anders regarding clarify of the ABNF syntax as well as notes on the ABNF 'rules' Regards, Victor -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, September 02, 2009 1:00 PM To: i-d-announce@ietf.org Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-19.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-19.txt Pages : 159 Date : 2009-09-02 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From sunseawq@huawei.com Wed Sep 2 19:32:30 2009 Return-Path: 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 294983A699E for ; Wed, 2 Sep 2009 19:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.278 X-Spam-Level: X-Spam-Status: No, score=0.278 tagged_above=-999 required=5 tests=[AWL=0.773, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 cMZOcH6AFT4t for ; Wed, 2 Sep 2009 19:32:29 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 45C653A6ADA for ; Wed, 2 Sep 2009 19:32:16 -0700 (PDT) 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 <0KPD00608IW9PQ@szxga01-in.huawei.com> for dime@ietf.org; Thu, 03 Sep 2009 10:28:57 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPD001QLIW95G@szxga01-in.huawei.com> for dime@ietf.org; Thu, 03 Sep 2009 10:28:57 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPD000IDIW8O9@szxml06-in.huawei.com> for dime@ietf.org; Thu, 03 Sep 2009 10:28:57 +0800 (CST) Date: Thu, 03 Sep 2009 10:28:56 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <01c601ca2c3e$49a49dc0$260ca40a@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.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <00e701ca2784$6b664030$260ca40a@china.huawei.com> <4A974A80.8020807@nict.go.jp> <00e901ca2a02$8ceaa6d0$260ca40a@china.huawei.com> <4A9B7878.4020001@nict.go.jp> <013501ca2ab0$f16354f0$260ca40a@china.huawei.com> <4A9CA29E.4010801@nict.go.jp> <00a601ca2b75$40358de0$260ca40a@china.huawei.com> <4A9DE7BC.3030900@nict.go.jp> Cc: Glen Zorn , dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 02:32:30 -0000 Hi, Sebastine and Glen: ----- Original Message ----- From: "Sebastien Decugis" To: "Qin Wu" Cc: ; "Glen Zorn" Sent: Wednesday, September 02, 2009 11:34 AM Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft > Hi Qin, > >> [Qin]: The problem is when the NAS recieves MSK or rMSK, the NAS can not judge >> whether MSK or rMSK is validated. because the NAS has no root key. Only intermediary node and End-Server >> can tell whether MSK or rMSK is validated. What the NAS can do is format checking, e.g., >> whether the lifetime of MSK is more than 0 or something else. >> > >> [Qin]: It may introduce security threat. Because the authenticator has no >> root keys and can not judge the key is validated. Only local server can validate >> the rMSK based on DSRK. >> > >> [Qin]: In implicit bootstrapping aren't both the MSK & rMSK sent in the same >> message? How can you tell the difference between them at the NAS? >> > Implicit bootstrapping is not an ERP exchange, therefore it does cannot > derive an rMSK (no SEQ available). Only MSK is sent in that case. [Qin]: Implicit ERP bootstrapping is actually full EAP authentication. However it is involved in the Implicit ERP exchange. Because the local ER server will request Re-authentication root key from home EAP server through local EAP server. So in my understanding, rMSK and MSK can be sent in the same message with same SEQ. Am I right? > In my understanding explicit bootstrapping is an ERP exchange between > peer and home server; therefore the rMSK is derived from the rRK key > (although I could not find this clarified in RFC5296 after a quick > search). At the same time, the rDSRK is derived to be provided to local > server. There is no relationship between this rMSK and rDSRK, so the > local server would not be able to check the validity of the key material > further than the NAS. [Qin]: As described in RFC5296, rMSK can be derived from DSRK or EMSK. So there are two choice: a) If rMSK and DSRK are both derived from EMSK, I think you are right. the local server can not check the validity of key material. b) If rMSK is derived from DSRK, I think the local server definitely can check the validity of key material. For security consideration, I prefer the b). > Anyway, these details are far away from the initial discussion about > what is best choice for distinguishing between two different keys: > - an enumerated AVP "Key-Type" inside the grouped AVP, or > - a different grouped AVP code for each key types. > Except for the different parsing and different message size, those two > possibilities are equivalent in terms of functionality it offers... [Qin]: Okay, Let's see what other folks think,-:). > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From dromasca@avaya.com Thu Sep 3 01:43:57 2009 Return-Path: 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 E8E153A681B for ; Thu, 3 Sep 2009 01:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 q0UHnWTPoAWS for ; Thu, 3 Sep 2009 01:43:56 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 9AACF3A67AB for ; Thu, 3 Sep 2009 01:43:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,324,1249272000"; d="scan'208";a="172231710" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 03 Sep 2009 04:41:52 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Sep 2009 04:41:51 -0400 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: Thu, 3 Sep 2009 10:41:44 +0200 Message-ID: In-Reply-To: <000c01ca2c03$c8e2c7f0$5aa857d0$@telcordia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-19.txt Thread-Index: Acor7tsBWpCdjnXDSU+YyQaD7R773AAFJQZgABu1nIA= References: <20090902170002.1AB873A6CB9@core3.amsl.com> <000c01ca2c03$c8e2c7f0$5aa857d0$@telcordia.com> From: "Romascanu, Dan (Dan)" To: , Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-19.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 08:43:58 -0000 Are we ready for WGLC with this document?=20 Dan =20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Victor Fajardo > Sent: Wednesday, September 02, 2009 10:30 PM > To: dime@ietf.org > Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-19.txt >=20 > This version increment includes: >=20 > * Technical and Editorial comments from Glen (this spans a=20 > few threads in the list) > * Comments from Anders regarding clarify of the ABNF syntax=20 > as well as notes on the ABNF 'rules' >=20 > Regards, > Victor >=20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, September 02, 2009 1:00 PM > To: i-d-announce@ietf.org > Cc: dime@ietf.org > Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-19.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Diameter Maintenance and=20 > Extensions Working Group of the IETF. >=20 >=20 > Title : Diameter Base Protocol > Author(s) : V. Fajardo, et al. > Filename : draft-ietf-dime-rfc3588bis-19.txt > Pages : 159 > Date : 2009-09-02 >=20 > The Diameter base protocol is intended to provide an=20 > Authentication, Authorization and Accounting (AAA) framework=20 > for applications such as network access or IP mobility in=20 > both local and roaming situations. > This document specifies the message format, transport, error=20 > reporting, accounting and security services used by all=20 > Diameter applications. The Diameter base protocol as defined=20 > in this document must be supported by all Diameter implementations. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-19.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From vfajardo@research.telcordia.com Thu Sep 3 08:00:04 2009 Return-Path: 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 68FE73A6D9A for ; Thu, 3 Sep 2009 08:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=0.477, 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 LD6Nz+tsEDxC for ; Thu, 3 Sep 2009 08:00:03 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 261FD3A6838 for ; Thu, 3 Sep 2009 08:00:03 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n83El8Gx001577; Thu, 3 Sep 2009 10:47:08 -0400 (EDT) From: "Victor Fajardo" To: "'Romascanu, Dan \(Dan\)'" , References: <20090902170002.1AB873A6CB9@core3.amsl.com> <000c01ca2c03$c8e2c7f0$5aa857d0$@telcordia.com> In-Reply-To: Date: Thu, 3 Sep 2009 10:47:08 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <003f01ca2ca5$6940a270$3bc1e750$@telcordia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acor7tsBWpCdjnXDSU+YyQaD7R773AAFJQZgABu1nIAACvmnAA== Content-Language: en-us Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-19.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 15:00:04 -0000 Hi Dan, Yes I believe we are. Some folks wanted to review parts of the doc and we are expecting them to finish during the WGLC. A 3-week WGLC starting next week should be sufficient. Regards, victor -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Thursday, September 03, 2009 4:42 AM To: vfajardo@research.telcordia.com; dime@ietf.org Subject: RE: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-19.txt Are we ready for WGLC with this document? Dan > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Victor Fajardo > Sent: Wednesday, September 02, 2009 10:30 PM > To: dime@ietf.org > Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-19.txt > > This version increment includes: > > * Technical and Editorial comments from Glen (this spans a > few threads in the list) > * Comments from Anders regarding clarify of the ABNF syntax > as well as notes on the ABNF 'rules' > > Regards, > Victor > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, September 02, 2009 1:00 PM > To: i-d-announce@ietf.org > Cc: dime@ietf.org > Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-19.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Diameter Maintenance and > Extensions Working Group of the IETF. > > > Title : Diameter Base Protocol > Author(s) : V. Fajardo, et al. > Filename : draft-ietf-dime-rfc3588bis-19.txt > Pages : 159 > Date : 2009-09-02 > > The Diameter base protocol is intended to provide an > Authentication, Authorization and Accounting (AAA) framework > for applications such as network access or IP mobility in > both local and roaming situations. > This document specifies the message format, transport, error > reporting, accounting and security services used by all > Diameter applications. The Diameter base protocol as defined > in this document must be supported by all Diameter implementations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-19.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From wwwrun@core3.amsl.com Tue Sep 8 08:04:36 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CF6DA3A6895; Tue, 8 Sep 2009 08:04:36 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090908150436.CF6DA3A6895@core3.amsl.com> Date: Tue, 8 Sep 2009 08:04:36 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] Last Call: draft-ietf-dime-diameter-cmd-iana (Updated IANA Considerations for Diameter Command Code Allocations) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 15:04:36 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Updated IANA Considerations for Diameter Command Code Allocations ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cmd-iana-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18633&rfc_flag=0 From sunseawq@huawei.com Tue Sep 8 20:56:00 2009 Return-Path: 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 E88023A68BE for ; Tue, 8 Sep 2009 20:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.176 X-Spam-Level: X-Spam-Status: No, score=0.176 tagged_above=-999 required=5 tests=[AWL=0.670, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 g6tHQg2Oq7wK for ; Tue, 8 Sep 2009 20:56:00 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id EFE743A68FF for ; Tue, 8 Sep 2009 20:55:54 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPO00MI2QXRKZ@szxga04-in.huawei.com> for dime@ietf.org; Wed, 09 Sep 2009 11:56:16 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPO00FPVQXRQV@szxga04-in.huawei.com> for dime@ietf.org; Wed, 09 Sep 2009 11:56:15 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPO00I8NQXRI1@szxml06-in.huawei.com> for dime@ietf.org; Wed, 09 Sep 2009 11:56:15 +0800 (CST) Date: Wed, 09 Sep 2009 11:56:14 +0800 From: Qin Wu To: dime@ietf.org Message-id: <01df01ca3101$7aba52c0$260ca40a@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: multipart/alternative; boundary="Boundary_(ID_Z2EXZdtewzndoJygXq+EHA)" X-Priority: 3 X-MSMail-priority: Normal Cc: julien.bournelle@orange-ftgroup.com Subject: [Dime] Comments on abstract and section 1 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 03:56:01 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Z2EXZdtewzndoJygXq+EHA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi,all: I have some comments on the abstract and section 1 of new version draft-ietf-dime-erp-01. please see the comments inline! Abstract EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the EAP peer and an EAP re-authentication server through an EAP/ERP authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between authenticator and ERP server, and a set of new AVPs that can be used to transport the cryptographic material needed by ERP server. [Qin]:ERP authenticator and ERP server seems new terminologies, I am wondering whether we need to define these terminologies in the document? Actually as described in RFC5296, ER Server relevant to ERP server has already been defined, Is it necessary to define the same thing? 1. Introduction [RFC5296] defines the EAP Re-authentication Protocol (ERP). It consists in the following steps: 1. Bootstrapping: a root key for re-authentication is derived from the Extended Master Session Key (EMSK) created during EAP authentication [RFC5295]. This root key is transported from the EAP server to the ER server. [Qin]: I agree implicit bootstrapping is not Re-authentication. However I am wondering whether explicit bootstrapping can still be viewed as Re-authentication? So whether dividing ERP into two step will cause a little confusion? 2. Re-authentication: a one-round-trip exchange between the peer and the ER server, resulting in mutual authentication. To accomplish the EAP reauthentication functionality, ERP defines two new EAP codes - EAP-Initiate and EAP-Finish. This document defines how Diameter transports the ERP messages (Re- authentication step). For this purpose, we define a new Application Id for ERP, and re-use the Diameter EAP commands (DER/DEA). This document also discusses the distribution of the root key (bootstrapping step), either during the initial EAP authentication (implicit bootstrapping) or during the first ERP exchange (explicit bootstrapping). Security considerations for this key distribution are detailed in [RFC5295]. --Boundary_(ID_Z2EXZdtewzndoJygXq+EHA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi,all:
I have some comments on the abstract and section 1 of new version draft-ietf-dime-erp-01.
please see the comments inline!
 
Abstract
 
   EAP Re-authentication Protocol (ERP) defines extensions to the
   Extensible Authentication Protocol (EAP) to support efficient re-
   authentication between the EAP peer and an EAP re-authentication
   server through an EAP/ERP authenticator.  This document specifies
   Diameter support for ERP.  It defines a new Diameter ERP application
   to transport ERP messages between authenticator and ERP server, and a
   set of new AVPs that can be used to transport the cryptographic
   material needed by ERP server.
[Qin]:ERP authenticator and ERP server seems  new terminologies, I am wondering
      whether we need to define these terminologies in the document? Actually as
      described in RFC5296, ER Server relevant to ERP server has already been
      defined, Is it necessary to define the same thing?
 

1.  Introduction
 
   [RFC5296] defines the EAP Re-authentication Protocol (ERP).  It
   consists in the following steps:
 
   1.  Bootstrapping: a root key for re-authentication is derived from
       the Extended Master Session Key (EMSK) created during EAP
       authentication [RFC5295].  This root key is transported from the
       EAP server to the ER server.

   [Qin]: I agree implicit bootstrapping is not Re-authentication. However
          I am wondering whether explicit bootstrapping can still be viewed as
          Re-authentication?
          So whether dividing ERP into two step will cause a little confusion?
 
   2.  Re-authentication: a one-round-trip exchange between the peer and
       the ER server, resulting in mutual authentication.  To accomplish
       the EAP reauthentication functionality, ERP defines two new EAP
       codes - EAP-Initiate and EAP-Finish.
 
   This document defines how Diameter transports the ERP messages (Re-
   authentication step).  For this purpose, we define a new Application
   Id for ERP, and re-use the Diameter EAP commands (DER/DEA).
 
   This document also discusses the distribution of the root key
   (bootstrapping step), either during the initial EAP authentication
   (implicit bootstrapping) or during the first ERP exchange (explicit
   bootstrapping).  Security considerations for this key distribution
   are detailed in [RFC5295].
 
 --Boundary_(ID_Z2EXZdtewzndoJygXq+EHA)-- From sunseawq@huawei.com Tue Sep 8 20:59:10 2009 Return-Path: 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 351BC3A6AAE for ; Tue, 8 Sep 2009 20:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.14 X-Spam-Level: X-Spam-Status: No, score=0.14 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 5oQadSzTZCM5 for ; Tue, 8 Sep 2009 20:59:09 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 39EC63A6910 for ; Tue, 8 Sep 2009 20:59:09 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPO0020BQYRHZ@szxga02-in.huawei.com> for dime@ietf.org; Wed, 09 Sep 2009 11:56:51 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPO001WVQYR7G@szxga02-in.huawei.com> for dime@ietf.org; Wed, 09 Sep 2009 11:56:51 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPO00EQJQYPJN@szxml06-in.huawei.com> for dime@ietf.org; Wed, 09 Sep 2009 11:56:51 +0800 (CST) Date: Wed, 09 Sep 2009 11:56:46 +0800 From: Qin Wu To: dime@ietf.org Message-id: <01e301ca3101$8feef150$260ca40a@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: multipart/alternative; boundary="Boundary_(ID_CP3uDa6ZWmnK+e9EIZbbUQ)" X-Priority: 3 X-MSMail-priority: Normal Cc: julien.bournelle@orange-ftgroup.com Subject: [Dime] Comments on section 2 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 03:59:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_CP3uDa6ZWmnK+e9EIZbbUQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT 2. Terminology This document uses terminology defined in [RFC3748], [RFC5295], [RFC5296], and [RFC4072]. "Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK derived from an EMSK, depending on the location of the ER server in home or foreign domain. We note in this document ERP/DER a Diameter-EAP-Request command with the Application Id set to Diameter ERP application. On the same model, we use ERP/DEA, EAP/DER and EAP/DEA. [Qin]: what does the same model mean? how about saying: " We note in this document ERP/DER *refer to* a Diameter-EAP-Request Command with the Application Id set to Diameter ERP application. *Similarly*, we use ERP/DEA, EAP/DER and EAP/DEA " [Qin] I am wondering how EAP/DER and ERP/DER can be used in the same one roundtrip exhange between the authenticator, ER server and home EAP server. In my understanding, when to use ERP/DER and when to use EAP/DER depends on the deployment scenario and bootstrapping mode. e.g., in implicit bootstrapping mode, we use EAP/DER, in explicit bootstraping mode, we use ERP/DER? another example when home EAP server does not support ERP and ER server support EAP, in this case, EAP/DER and EAP/DEA can be used between ER server with EAP proxy function support and home EAP server. Am I right? --Boundary_(ID_CP3uDa6ZWmnK+e9EIZbbUQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
2.  Terminology
 
   This document uses terminology defined in [RFC3748], [RFC5295],
   [RFC5296], and [RFC4072].
 
   "Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK
   derived from an EMSK, depending on the location of the ER server in
   home or foreign domain.
 
   We note in this document ERP/DER a Diameter-EAP-Request command with
   the Application Id set to Diameter ERP application.  On the same
   model, we use ERP/DEA, EAP/DER and EAP/DEA.
  
   [Qin]: what does the same model mean? how about saying:
   "
   We note in this document ERP/DER *refer to* a Diameter-EAP-Request Command with the
   Application Id set to Diameter ERP application. *Similarly*, we use ERP/DEA, EAP/DER
   and EAP/DEA
   "
   [Qin] I am wondering how EAP/DER and ERP/DER can be used in the same one roundtrip exhange
   between the authenticator, ER server and home EAP server. In my understanding, when to use ERP/DER
   and when to use EAP/DER depends on the deployment scenario and bootstrapping mode. e.g., in implicit
   bootstrapping mode, we use EAP/DER, in explicit bootstraping mode, we use ERP/DER?
   another example when home EAP server does not support ERP and ER server support EAP, in this case,
   EAP/DER and EAP/DEA can be used between ER server with EAP proxy function support and home EAP server.
   Am I right?
 
--Boundary_(ID_CP3uDa6ZWmnK+e9EIZbbUQ)-- From sunseawq@huawei.com Tue Sep 8 20:59:10 2009 Return-Path: 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 A5EA33A6910 for ; Tue, 8 Sep 2009 20:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 zdr5XGuEQNpU for ; Tue, 8 Sep 2009 20:59:09 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 8FE793A69DC for ; Tue, 8 Sep 2009 20:59:09 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPO0023UQYYHZ@szxga02-in.huawei.com> for dime@ietf.org; Wed, 09 Sep 2009 11:56:58 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPO001YVQYY7G@szxga02-in.huawei.com> for dime@ietf.org; Wed, 09 Sep 2009 11:56:58 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPO00IE7QYXI1@szxml06-in.huawei.com> for dime@ietf.org; Wed, 09 Sep 2009 11:56:58 +0800 (CST) Date: Wed, 09 Sep 2009 11:56:56 +0800 From: Qin Wu To: dime@ietf.org Message-id: <01e701ca3101$93daaa70$260ca40a@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: multipart/alternative; boundary="Boundary_(ID_TSujQLYDFTVwQir20SxYzQ)" X-Priority: 3 X-MSMail-priority: Normal Cc: julien.bournelle@orange-ftgroup.com Subject: [Dime] Comments on section 3 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 03:59:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_TSujQLYDFTVwQir20SxYzQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT 3. Assumptions This document makes the following assumptions. The Home EAP server of a peer that wants to use ERP is extended to support: Cryptographic operations needed to derive the ERP root key from the EMSK. By deriving the ERP root key for a specific domain, the [Qin]: Since ERP root key can be derived for specific domain, I think these root key can also be derived for the same part of the home domain as the home EAP server, am I right? home EAP server implicitly authorizes the use of ERP within this domain. [Qin]: I am wondering what does the home EAP server base on to authorize the use of ERP within given domain? Isn't it enough to assume trust relationship between local domain and home domain? Diameter operations to include this root key inside an appropriate AVP as defined in this document, in an answer message corresponding to a request that contained a request for this [Qin]: s/contained/contains material (AVP for the request also defined in this document). (recommanded) Ability to answer a DER message with EAP-Payload containing an explicit bootstrapping ERP message. [Qin]:What does "(recommanded)"? recommended? Is there any missing text here? I am wondering ability to answer a DER message can be covered by Diameter operations? The Authenticator (NAS) is extended to support: Allow the new ERP command codes (EAP-Initiate and EAP-Finish) in its EAP pass-through mode. (optional) Send the EAP-Initiate/Re-Auth-Start message [Qin]: I am wondering what's the difference between the first bullet and the second bullet? (optional) Provide the local domain name via lower layer specific mechanism or via TLV in the EAP-Initiate/Re-Auth-Start message. Encapsulate ERP message and receive corresponding Diameter answer, as described in this document. If one of the components does not match these assumptions, the ERP mechanism will fail. In such situation, a full EAP authentication may be attempted as a fallback mechanism. We consider at most one logical ER server entity in a domain. If several physical servers are deployed for robustness, a replication mechanism must be deployed to synchronize the ERP states (root keys ) between these servers. This replication mechanism is out of the scope of this document. If several ER servers are deployed in the domain, we assume that they can be used interchangeably. [Qin] Does this mean all the ER server in one domain can be seem as one logical ER server? --Boundary_(ID_TSujQLYDFTVwQir20SxYzQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
3.  Assumptions
 
   This document makes the following assumptions.

   The Home EAP server of a peer that wants to use ERP is extended to
   support:
 
      Cryptographic operations needed to derive the ERP root key from
      the EMSK.  By deriving the ERP root key for a specific domain, the
     
      [Qin]: Since ERP root key can be derived for specific domain, I think
      these root key can also be derived for the same part of the home domain as the home EAP server,
      am I right?
 
      home EAP server implicitly authorizes the use of ERP within this
      domain.
     
      [Qin]: I am wondering what does the home EAP server base on to authorize the use of ERP within
      given domain? Isn't it enough to assume trust relationship between local domain and home domain?
 
      Diameter operations to include this root key inside an appropriate
      AVP as defined in this document, in an answer message
      corresponding to a request that contained a request for this
     
      [Qin]: s/contained/contains
      material (AVP for the request also defined in this document).
 
      (recommanded) Ability to answer a DER message with EAP-Payload
      containing an explicit bootstrapping ERP message.
     
      [Qin]:What does "(recommanded)"? recommended?
      Is there any missing text here? I am wondering ability to answer
      a DER message can be covered by Diameter operations?
 
   The Authenticator (NAS) is extended to support:
 
      Allow the new ERP command codes (EAP-Initiate and EAP-Finish) in
      its EAP pass-through mode.
 
      (optional) Send the EAP-Initiate/Re-Auth-Start message
 
       [Qin]: I am wondering what's the difference between the first bullet and the second bullet?
 
      (optional) Provide the local domain name via lower layer specific
      mechanism or via TLV in the EAP-Initiate/Re-Auth-Start message.
 
      Encapsulate ERP message and receive corresponding Diameter answer,
      as described in this document.
 
   If one of the components does not match these assumptions, the ERP
   mechanism will fail.  In such situation, a full EAP authentication
   may be attempted as a fallback mechanism.
 
   We consider at most one logical ER server entity in a domain.  If
   several physical servers are deployed for robustness, a replication
   mechanism must be deployed to synchronize the ERP states (root keys )
   between these servers.  This replication mechanism is out of the
   scope of this document.  If several ER servers are deployed in the
   domain, we assume that they can be used interchangeably.
 
   [Qin] Does this mean all the ER server in one domain can be seem as one logical ER server?
--Boundary_(ID_TSujQLYDFTVwQir20SxYzQ)-- From sdecugis@nict.go.jp Fri Sep 11 01:44:08 2009 Return-Path: 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 64D3A3A6A39 for ; Fri, 11 Sep 2009 01:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.785 X-Spam-Level: X-Spam-Status: No, score=0.785 tagged_above=-999 required=5 tests=[AWL=-1.011, BAYES_20=-0.74, HELO_EQ_JP=1.244, MISSING_HEADERS=1.292] 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 cfEaB7yluABL for ; Fri, 11 Sep 2009 01:44:07 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id E24023A6860 for ; Fri, 11 Sep 2009 01:44:06 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n8B8ifhb001913 for ; Fri, 11 Sep 2009 17:44:41 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n8B8ifcn013705 for ; Fri, 11 Sep 2009 17:44:41 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n8B8ifxM013702 for ; Fri, 11 Sep 2009 17:44:41 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 8E4082C31A for ; Fri, 11 Sep 2009 17:44:41 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 894232C319 for ; Fri, 11 Sep 2009 17:44:41 +0900 (JST) Message-ID: <4AAA0DF2.9000806@nict.go.jp> Date: Fri, 11 Sep 2009 17:44:34 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: dime@ietf.org References: <01df01ca3101$7aba52c0$260ca40a@china.huawei.com> In-Reply-To: <01df01ca3101$7aba52c0$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Comments on abstract and section 1 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 08:44:08 -0000 Hello Qin, Thank you for the detailed review. Please find my comments inline. Sorry for my late answer. > Abstract > [Qin]:ERP authenticator and ERP server seems new terminologies, I am > wondering > whether we need to define these terminologies in the document? > Actually as > described in RFC5296, ER Server relevant to ERP server has already been > defined, Is it necessary to define the same thing? You are right, we must use consistent terminology with RFC5296. I will change "ERP server" to "ER server" and replace "EAP/ERP authenticator" with "Compatible authenticator". Do you agree with these changes? > [Qin]: I agree implicit bootstrapping is not Re-authentication. However > I am wondering whether explicit bootstrapping can still be viewed as > Re-authentication? > So whether dividing ERP into two step will cause a little confusion? Explicit bootstrapping in a kind of special case: the re-authentication happens between peer and home ER server, and also carries the key material for the local ER server. Therefore it is a "step 2" for the home server and "step 1" for the local server. In any case, the home server must already be bootstrapped -- or collocated with the EAP server, as we currently assume, and derive the key when it is needed. But from a process point of view, I believe these two separate steps still apply to any ERP exchange -- only the timing may be different with some scenarios. Does this clarify the text? Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Fri Sep 11 01:50:49 2009 Return-Path: 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 39E7A3A68E0 for ; Fri, 11 Sep 2009 01:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HELO_EQ_JP=1.244, MISSING_HEADERS=1.292] 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 YHPUSNVJvw+1 for ; Fri, 11 Sep 2009 01:50:48 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id AE6103A67B1 for ; Fri, 11 Sep 2009 01:50:47 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n8B8pN8P003022 for ; Fri, 11 Sep 2009 17:51:23 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n8B8pNVZ015903 for ; Fri, 11 Sep 2009 17:51:23 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n8B8pNsI015900 for ; Fri, 11 Sep 2009 17:51:23 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 3373E2C1B7 for ; Fri, 11 Sep 2009 17:51:23 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 2EC842C1B6 for ; Fri, 11 Sep 2009 17:51:23 +0900 (JST) Message-ID: <4AAA0F84.3010601@nict.go.jp> Date: Fri, 11 Sep 2009 17:51:16 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: dime@ietf.org References: <01e301ca3101$8feef150$260ca40a@china.huawei.com> In-Reply-To: <01e301ca3101$8feef150$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Comments on section 2 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 08:50:49 -0000 Hi again, comments inline... > We note in this document ERP/DER a Diameter-EAP-Request command with > the Application Id set to Diameter ERP application. On the same > model, we use ERP/DEA, EAP/DER and EAP/DEA. > > [Qin]: what does the same model mean? how about saying: > " > We note in this document ERP/DER *refer to* a Diameter-EAP-Request > Command with the > Application Id set to Diameter ERP application. *Similarly*, we use > ERP/DEA, EAP/DER > and EAP/DEA > " Agreed, my phrasing was quite bad :D I will change it to something better, such as what you are suggesting. Thank you for catching this. > [Qin] I am wondering how EAP/DER and ERP/DER can be used in the same > one roundtrip exhange > between the authenticator, ER server and home EAP server. In my > understanding, when to use ERP/DER > and when to use EAP/DER depends on the deployment scenario and > bootstrapping mode. e.g., in implicit > bootstrapping mode, we use EAP/DER, in explicit bootstraping mode, we > use ERP/DER? This is explained in the explicit mechanism description later in the document... Basically the local ER server proxies the request and changes its application Id, so ERP/DER becomes EAP/DER. > another example when home EAP server does not support ERP In that case, the ER server cannot obtain the root key required for ERP function... > and ER server support EAP, in this case, > EAP/DER and EAP/DEA can be used between ER server with EAP proxy > function support and home EAP server. > Am I right? I don't really understand what you are implying here, sorry. Can you clarify? Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Fri Sep 11 02:12:46 2009 Return-Path: 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 9CC463A68C7 for ; Fri, 11 Sep 2009 02:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.076 X-Spam-Level: X-Spam-Status: No, score=-0.076 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HELO_EQ_JP=1.244, MISSING_HEADERS=1.292] 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 L1fsbJ3YiD7r for ; Fri, 11 Sep 2009 02:12:45 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 1416A3A67F5 for ; Fri, 11 Sep 2009 02:12:44 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n8B9DJlJ016383 for ; Fri, 11 Sep 2009 18:13:19 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n8B9DJ0F016269 for ; Fri, 11 Sep 2009 18:13:19 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n8B9DJ3E016266 for ; Fri, 11 Sep 2009 18:13:19 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 08CBA2C1B3 for ; Fri, 11 Sep 2009 18:13:19 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 0380A2C1AB for ; Fri, 11 Sep 2009 18:13:19 +0900 (JST) Message-ID: <4AAA14A8.20101@nict.go.jp> Date: Fri, 11 Sep 2009 18:13:12 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: dime@ietf.org References: <01e701ca3101$93daaa70$260ca40a@china.huawei.com> In-Reply-To: <01e701ca3101$93daaa70$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Comments on section 3 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 09:12:46 -0000 Hi again again, and inline... > 3. Assumptions > > [Qin]: Since ERP root key can be derived for specific domain, I think > these root key can also be derived for the same part of the home > domain as the home EAP server, > am I right? I think I don't understand the question... For home domain, the key derivation is different in ERP: rRK instead of rDSRK. > > home EAP server implicitly authorizes the use of ERP within this > domain. > > [Qin]: I am wondering what does the home EAP server base on to > authorize the use of ERP within > given domain? Isn't it enough to assume trust relationship between > local domain and home domain? I wanted to highlight the implication of deriving a key for ERP. By providing an ERP root key for a visited domain, the local domain server implicitly authorizes the use of ERP in that domain. The consequences on the management of the session and other side effects should be understood by the home domain before accepting to derive this material. > [Qin]: s/contained/contains Hmmm I will try a different phrasing here, the sentence is too complicated anyway. Thank you for pointing it out. > > [Qin]:What does "(recommanded)"? recommended? Oops that is French-English sorry I will fix it. Yes, I meant "recommended". > Is there any missing text here? I am wondering ability to answer > a DER message can be covered by Diameter operations? There are two different operations: support to send the rRK/rDSRK in Diameter message; and support to answer an EAP-Initiate ERP message. While the first is mandatory, the second is only needed to support explicit bootstrapping scenario. That is the rationale for the "(recommended)" notation. > Allow the new ERP command codes (EAP-Initiate and EAP-Finish) in > its EAP pass-through mode. > (optional) Send the EAP-Initiate/Re-Auth-Start message > [Qin]: I am wondering what's the difference between the first bullet > and the second bullet? The EAP-Initiate/Re-Auth-Start message is optionally sent by the NAS to the *peer* to initiate ERP exchange, as described in RFC5296 (second bullet). The other messages (from first bullet) are exchanged between the peer and the server, the NAS is only acting as a passthrough. But EAP passthrough definition requires that unknown EAP codes messages are dropped, so the NAS must be changed to allow the ERP codes as well. > We consider at most one logical ER server entity in a domain. If > several physical servers are deployed for robustness, a replication > mechanism must be deployed to synchronize the ERP states (root keys ) > between these servers. This replication mechanism is out of the > scope of this document. If several ER servers are deployed in the > domain, we assume that they can be used interchangeably. > [Qin] Does this mean all the ER server in one domain can be seem as > one logical ER server? Yes it is the assumption here in this version of the document. If we don't have this assumption, we must provide a way to either: - synchronize explicitly the states between different ER servers inside one domain. - ensure that messages belonging to one session are routed to the appropriate ER server. Since the primary rationale for having several ER server is robustness, it is logical to assume that the servers must be synchronized in any case. Since synchronization of states in Diameter between several servers is a general issue, it is better not to define a solution only for ERP application. A new Diameter application could be defined for this matter, but we don't want to do this inside Diameter ERP. So, all in all, it is easier to simply assume the servers are synchronized and can be used interchangeably. Does that make sense? Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sunseawq@huawei.com Sun Sep 13 19:51:47 2009 Return-Path: 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 102013A695C for ; Sun, 13 Sep 2009 19:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_40=-0.185] 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 55x+bGhyiIKL for ; Sun, 13 Sep 2009 19:51:46 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id D64A93A68AF for ; Sun, 13 Sep 2009 19:51:45 -0700 (PDT) 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 <0KPX00J93XBFUG@szxga01-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 10:52:27 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPX0087XXBFZE@szxga01-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 10:52:27 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPX00NDKXBF4K@szxml04-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 10:52:27 +0800 (CST) Date: Mon, 14 Sep 2009 10:52:26 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <00ac01ca34e6$64f43990$260ca40a@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=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <01df01ca3101$7aba52c0$260ca40a@china.huawei.com> <4AAA0DF2.9000806@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] Comments on abstract and section 1 of new versiondraft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 02:51:47 -0000 Hi, Sebastien: ----- Original Message ----- From: "Sebastien Decugis" Cc: Sent: Friday, September 11, 2009 4:44 PM Subject: Re: [Dime] Comments on abstract and section 1 of new versiondraft-ietf-dime-erp-01 > Hello Qin, > > Thank you for the detailed review. Please find my comments inline. Sorry > for my late answer. > > >> Abstract >> [Qin]:ERP authenticator and ERP server seems new terminologies, I am >> wondering >> whether we need to define these terminologies in the document? >> Actually as >> described in RFC5296, ER Server relevant to ERP server has already been >> defined, Is it necessary to define the same thing? > You are right, we must use consistent terminology with RFC5296. I will > change "ERP server" to "ER server" and replace "EAP/ERP authenticator" > with "Compatible authenticator". Do you agree with these changes? [Qin]: I agree to change ERP Server to ER Server. As regarding "EAP/ERP authenticator", I think the definition of authenticator has already implied that it supports EAP authentication, ERP is a extension to EAP, So it seems not neccessary to emphasize whether authenticator support EAP. Given "ER Peer" and "ER Authenticator" defined in the RFC5296, how about say: " support efficient re- authentication between the *ER peer* and an EAP re-authentication server through an *ER authenticator*. " instead of " support efficient re- authentication between the EAP peer and an EAP re-authentication server through an EAP/ERP authenticator. " >> [Qin]: I agree implicit bootstrapping is not Re-authentication. However >> I am wondering whether explicit bootstrapping can still be viewed as >> Re-authentication? >> So whether dividing ERP into two step will cause a little confusion? > Explicit bootstrapping in a kind of special case: the re-authentication > happens between peer and home ER server, and also carries the key > material for the local ER server. Therefore it is a "step 2" for the > home server and "step 1" for the local server. In any case, the home > server must already be bootstrapped -- or collocated with the EAP > server, as we currently assume, and derive the key when it is needed. > But from a process point of view, I believe these two separate steps > still apply to any ERP exchange -- only the timing may be different with > some scenarios. Does this clarify the text? [Qin]: What I am difficult to understand is Explicit bootstrapping actually can be understand as full ERP authentication with the home ER server. Because Explicit bootstrapping uses ERP message with bootstrapping flag turned on to request the key materials. In this sense, in the Explicit bootstrapping, key transport happens in the same step. Unlike Explicit bootstrapping, Implicit bootstrapping uses EAP message to request key materials.Therefore Re-authentication will not happen with Implicit bootstrapping at the same time. So for Implicit bootstrapping, I agree with you implicit bootrapping step happen before re-authentication. However for Explicit bootstrapping, I am afraid bootstrapping and Re-authentication happens in the same step at the same time. To avoid confusion, how about say: step 1 is for Re-auth root key transport, Step 2 is for Re-authentication, i.e., using key material from step 1 to perform Re-auth. > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sunseawq@huawei.com Sun Sep 13 19:52:14 2009 Return-Path: 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 E712D3A67D1 for ; Sun, 13 Sep 2009 19:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[AWL=1.511, 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 F2iWVeNp42Kq for ; Sun, 13 Sep 2009 19:52:13 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 8A58F3A67CF for ; Sun, 13 Sep 2009 19:52:13 -0700 (PDT) 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 <0KPX00JGKXC7UG@szxga01-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 10:52:56 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPX008EUXC7ZE@szxga01-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 10:52:55 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPX00NHRXC54K@szxml04-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 10:52:54 +0800 (CST) Date: Mon, 14 Sep 2009 10:52:53 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <00ae01ca34e6$74e3a980$260ca40a@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=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <01e701ca3101$93daaa70$260ca40a@china.huawei.com> <4AAA14A8.20101@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] Comments on section 3 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 02:52:15 -0000 Hi, Sebastien: Thank for your reply, Please see my followup comments. ----- Original Message ----- From: "Sebastien Decugis" Cc: Sent: Friday, September 11, 2009 5:13 PM Subject: Re: [Dime] Comments on section 3 of new version draft-ietf-dime-erp-01 > Hi again again, and inline... > >> 3. Assumptions >> >> [Qin]: Since ERP root key can be derived for specific domain, I think >> these root key can also be derived for the same part of the home >> domain as the home EAP server, >> am I right? > I think I don't understand the question... For home domain, the key > derivation is different in ERP: rRK instead of rDSRK. [Qin]: Since DSRK is calculated based the Domain name, given home domain name in the home domain I am wondering whether we can derive home domain specific DSRK based on the home domain name? Anyway, it seems not relevant to this new version draft.-:) >> home EAP server implicitly authorizes the use of ERP within this >> domain. >> >> [Qin]: I am wondering what does the home EAP server base on to >> authorize the use of ERP within >> given domain? Isn't it enough to assume trust relationship between >> local domain and home domain? > I wanted to highlight the implication of deriving a key for ERP. By > providing an ERP root key for a visited domain, the local domain server > implicitly authorizes the use of ERP in that domain. The consequences on > the management of the session and other side effects should be > understood by the home domain before accepting to derive this material. [Qin]: Okay, I agree with your explainnation. However I have two followup comments as follows: 1. The home EAP server that uses ERP is the home ER server or not? 2. Who actually authorize the use of ERP, home EAP server or home ER server? >> [Qin]: s/contained/contains > Hmmm I will try a different phrasing here, the sentence is too > complicated anyway. Thank you for pointing it out. [Qin]: Okay. >> >> [Qin]:What does "(recommanded)"? recommended? > Oops that is French-English sorry I will fix it. Yes, I meant > "recommended". [Qin]: Okay. >> Is there any missing text here? I am wondering ability to answer >> a DER message can be covered by Diameter operations? > There are two different operations: support to send the rRK/rDSRK in > Diameter message; and support to answer an EAP-Initiate ERP message. > While the first is mandatory, the second is only needed to support > explicit bootstrapping scenario. That is the rationale for the > "(recommended)" notation. [Qin]: Well, I understand. >> Allow the new ERP command codes (EAP-Initiate and EAP-Finish) in >> its EAP pass-through mode. >> (optional) Send the EAP-Initiate/Re-Auth-Start message >> [Qin]: I am wondering what's the difference between the first bullet >> and the second bullet? > The EAP-Initiate/Re-Auth-Start message is optionally sent by the NAS to > the *peer* to initiate ERP exchange, as described in RFC5296 (second > bullet). The other messages (from first bullet) are exchanged between > the peer and the server, the NAS is only acting as a passthrough. But > EAP passthrough definition requires that unknown EAP codes messages are > dropped, so the NAS must be changed to allow the ERP codes as well. [Qin]: Right, thank for your clarification. >> We consider at most one logical ER server entity in a domain. If >> several physical servers are deployed for robustness, a replication >> mechanism must be deployed to synchronize the ERP states (root keys ) >> between these servers. This replication mechanism is out of the >> scope of this document. If several ER servers are deployed in the >> domain, we assume that they can be used interchangeably. >> [Qin] Does this mean all the ER server in one domain can be seem as >> one logical ER server? > Yes it is the assumption here in this version of the document. If we > don't have this assumption, we must provide a way to either: > - synchronize explicitly the states between different ER servers inside > one domain. > - ensure that messages belonging to one session are routed to the > appropriate ER server. > Since the primary rationale for having several ER server is robustness, > it is logical to assume that the servers must be synchronized in any > case. Since synchronization of states in Diameter between several > servers is a general issue, it is better not to define a solution only > for ERP application. A new Diameter application could be defined for > this matter, but we don't want to do this inside Diameter ERP. So, all > in all, it is easier to simply assume the servers are synchronized and > can be used interchangeably. Does that make sense? [Qin]: I agree, without this assumption, it seems ERP exchange and EAP Re-authentication operations on the peer, authenticator and server will be complicated. I wonder what do you think of the case where the home realm contains several EAP servers described in the "open issues"section? Isn't it the same thing? > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sunseawq@huawei.com Sun Sep 13 19:53:02 2009 Return-Path: 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 1DAA53A697F for ; Sun, 13 Sep 2009 19:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 GhrI1GTFUdXY for ; Sun, 13 Sep 2009 19:53:01 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2CEBB3A6962 for ; Sun, 13 Sep 2009 19:53:01 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPX009EXXBX9A@szxga03-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 10:52:45 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPX002UDXBXUF@szxga03-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 10:52:45 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPX00IGFXBWZZ@szxml04-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 10:52:44 +0800 (CST) Date: Mon, 14 Sep 2009 10:52:44 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <00ad01ca34e6$6f603960$260ca40a@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=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <01e301ca3101$8feef150$260ca40a@china.huawei.com> <4AAA0F84.3010601@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] Comments on section 2 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 02:53:02 -0000 Hi, Sebastien: ----- Original Message ----- From: "Sebastien Decugis" Cc: Sent: Friday, September 11, 2009 4:51 PM Subject: Re: [Dime] Comments on section 2 of new version draft-ietf-dime-erp-01 > Hi again, comments inline... > > >> We note in this document ERP/DER a Diameter-EAP-Request command with >> the Application Id set to Diameter ERP application. On the same >> model, we use ERP/DEA, EAP/DER and EAP/DEA. >> >> [Qin]: what does the same model mean? how about saying: >> " >> We note in this document ERP/DER *refer to* a Diameter-EAP-Request >> Command with the >> Application Id set to Diameter ERP application. *Similarly*, we use >> ERP/DEA, EAP/DER >> and EAP/DEA >> " > Agreed, my phrasing was quite bad :D I will change it to something > better, such as what you are suggesting. Thank you for catching this. > >> [Qin] I am wondering how EAP/DER and ERP/DER can be used in the same >> one roundtrip exhange >> between the authenticator, ER server and home EAP server. In my >> understanding, when to use ERP/DER >> and when to use EAP/DER depends on the deployment scenario and >> bootstrapping mode. e.g., in implicit >> bootstrapping mode, we use EAP/DER, in explicit bootstraping mode, we >> use ERP/DER? > This is explained in the explicit mechanism description later in the > document... Basically the local ER server proxies the request and > changes its application Id, so ERP/DER becomes EAP/DER. [Qin]: If only the local server support ERP, I think it is necessary for local ER server to change its application ID from ERP to EAP. However If the local server and home server both support ERP, I don't think it is necessary for local ER server to change its application ID from ERP to EAP, am I right? >> another example when home EAP server does not support ERP > In that case, the ER server cannot obtain the root key required for ERP > function... [Qin]: In the Implicit Bootstrapping, the local ER server can obtain the root key from the home EAP server through local AAA agent or proxy.You can check the following errata report in the hokey ML: http://www.ietf.org/mail-archive/web/hokey/current/msg01662.html In this scenario, the local ER can fetch root key from the local AAA agent or the local AAA agent can manually install root key on the local ER, am I right? >> and ER server support EAP, in this case, >> EAP/DER and EAP/DEA can be used between ER server with EAP proxy >> function support and home EAP server. >> Am I right? > I don't really understand what you are implying here, sorry. Can you > clarify? [Qin]: Sorry for your misunderstanding. I just want to figure out in which scenario EAP/DER and EAP/DEA will be used? In my understanding, If the home server does not support ERP, the local ER server collocated with the local AAA agent, we can use EAP/DER and EAP/DEA, in this sense, we need to change application ID from EAP to ERP, as you mentioned above. > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Sun Sep 13 21:22:13 2009 Return-Path: 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 F3FFE3A698C for ; Sun, 13 Sep 2009 21:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.705 X-Spam-Level: X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 KBUAGS1Fo37d for ; Sun, 13 Sep 2009 21:22:12 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 72AD53A6841 for ; Sun, 13 Sep 2009 21:22:11 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n8E4MrZu019731 for ; Mon, 14 Sep 2009 13:22:53 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n8E4Mr8s023507 for ; Mon, 14 Sep 2009 13:22:53 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n8E4MrNu023504 for ; Mon, 14 Sep 2009 13:22:53 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id B360B2C359 for ; Mon, 14 Sep 2009 13:22:53 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail3.nict.go.jp (NICT Mail) with ESMTP id ADDCF2C344 for ; Mon, 14 Sep 2009 13:22:53 +0900 (JST) Message-ID: <4AADC515.9000609@nict.go.jp> Date: Mon, 14 Sep 2009 13:22:45 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: dime@ietf.org References: <01df01ca3101$7aba52c0$260ca40a@china.huawei.com> <4AAA0DF2.9000806@nict.go.jp> <00ac01ca34e6$64f43990$260ca40a@china.huawei.com> In-Reply-To: <00ac01ca34e6$64f43990$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Comments on abstract and section 1 of new versiondraft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 04:22:13 -0000 Hi Qin, > As regarding "EAP/ERP authenticator", I think the definition of authenticator > has already implied that it supports EAP authentication, ERP is a extension to EAP, > So it seems not neccessary to emphasize whether authenticator support EAP. I understand your point now, thank you. Since it's only the abstract, I think we should try and avoid using too much abbreviations such as "ER". I'll change to more explicit language using words instead of acronyms. >> Explicit bootstrapping in a kind of special case: the re-authentication >> happens between peer and home ER server, and also carries the key >> material for the local ER server. Therefore it is a "step 2" for the >> home server and "step 1" for the local server. In any case, the home >> server must already be bootstrapped -- or collocated with the EAP >> server, as we currently assume, and derive the key when it is needed. >> But from a process point of view, I believe these two separate steps >> still apply to any ERP exchange -- only the timing may be different with >> some scenarios. Does this clarify the text? >> > > [Qin]: What I am difficult to understand is Explicit bootstrapping actually can be understand > as full ERP authentication with the home ER server. Because Explicit bootstrapping uses ERP message > with bootstrapping flag turned on to request the key materials. It's actually a strange behavior of ERP (which I hope would be fixed in new revision if any): the peer sets the B flag to request for key material on behalf of an hypothetic local ER server... In explicit bootstrapping we have really two different things in the same exchange: 1) peer <-> home server : re-authentication 2) local ER server <-> home server : bootstrapping For (1) to occur, it supposes that the home server already have the key material. Therefore it is either collocated with EAP server (and so the key material is locally available) or has already bootstrapped previously (kind of recursive architecture in this case). > To avoid confusion, how about say: > step 1 is for Re-auth root key transport, > Step 2 is for Re-authentication, i.e., using key material from step 1 to perform Re-auth. > I don't see the difference between your proposal and the current text... Can you highlight what is changed? Thanks , Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Sun Sep 13 21:36:32 2009 Return-Path: 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 C1C1B3A699E for ; Sun, 13 Sep 2009 21:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 4LdxZ1F8KiTT for ; Sun, 13 Sep 2009 21:36:31 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 2E3B73A69A2 for ; Sun, 13 Sep 2009 21:36:30 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n8E4b8Lo020831; Mon, 14 Sep 2009 13:37:08 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n8E4b8mq026320; Mon, 14 Sep 2009 13:37:08 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n8E4b8SD026317; Mon, 14 Sep 2009 13:37:08 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 286522C4C0; Mon, 14 Sep 2009 13:37:08 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 2270B2C4A8; Mon, 14 Sep 2009 13:37:08 +0900 (JST) Message-ID: <4AADC86B.7060904@nict.go.jp> Date: Mon, 14 Sep 2009 13:36:59 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Qin Wu References: <01e301ca3101$8feef150$260ca40a@china.huawei.com> <4AAA0F84.3010601@nict.go.jp> <00ad01ca34e6$6f603960$260ca40a@china.huawei.com> In-Reply-To: <00ad01ca34e6$6f603960$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Comments on section 2 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 04:36:32 -0000 Hi, > [Qin]: > If only the local server support ERP, I think it is necessary for local ER server to change > its application ID from ERP to EAP. > However If the local server and home server both support ERP, I don't think > it is necessary for local ER server to change its application ID from ERP to EAP, > am I right? > The EMSK is located on the EAP server, not ER server. For bootstrapping, the message *must* therefore reach the *EAP* server. We might go through the ER server in the home domain but it would be just an additional useless relay... The reason for changing the application Id is routing of the message to the proper server (the one that has the EMSK). Of course if there is only one server in the domain, the application Id can be anything... But we want to separate the logical entities... >>> another example when home EAP server does not support ERP >>> >> In that case, the ER server cannot obtain the root key required for ERP >> function... >> > [Qin]: In the Implicit Bootstrapping, the local ER server can obtain the root key > from the home EAP server through local AAA agent or proxy.You can check > the following errata report in the hokey ML: > http://www.ietf.org/mail-archive/web/hokey/current/msg01662.html > In this scenario, the local ER can fetch root key from the local AAA agent or > the local AAA agent can manually install root key on the local ER, am I right? > Well, even if the errata says so, if the EAP server is not able to derive ERP material, I cannot see how the AAA server (a third entity?) would be able to obtain it... Furthermore, this errata assumes that some protocol such as Diameter is available to do all the operations it describes. If we want to accommodate such architecture, we have to define new messages for key exchanges only (maybe even another Diameter application Id). Anyway, I don't see the benefit of this compared to the architecture we define currently... I think this can be discussed in next IETF meeting with interested people. > [Qin]: Sorry for your misunderstanding. I just want to figure out in which scenario EAP/DER > and EAP/DEA will be used? > In my understanding, If the home server does not support ERP, the local ER server collocated with > the local AAA agent, we can use EAP/DER and EAP/DEA, in this sense, we need to change application ID from > EAP to ERP, as you mentioned above. > As I wrote earlier, the rationale for changing the application Id is to route the message to the server that has the EMSK material, which is needed for bootstrapping. Unfortunately, so far we don't consider the situation where several EAP servers are in the home domain (and only 1 has the EMSK). It must be addressed. BR Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Sun Sep 13 21:46:29 2009 Return-Path: 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 384F73A6855 for ; Sun, 13 Sep 2009 21:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 qKVaGSgWKMx4 for ; Sun, 13 Sep 2009 21:46:28 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id A34ED3A67DF for ; Sun, 13 Sep 2009 21:46:27 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n8E4lANF021868 for ; Mon, 14 Sep 2009 13:47:10 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n8E4l9UJ028739 for ; Mon, 14 Sep 2009 13:47:09 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n8E4l9a2028735 for ; Mon, 14 Sep 2009 13:47:09 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id D22372C4B6 for ; Mon, 14 Sep 2009 13:47:09 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail2.nict.go.jp (NICT Mail) with ESMTP id CD35C2C4AC for ; Mon, 14 Sep 2009 13:47:09 +0900 (JST) Message-ID: <4AADCAC5.9010007@nict.go.jp> Date: Mon, 14 Sep 2009 13:47:01 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: dime@ietf.org References: <01e701ca3101$93daaa70$260ca40a@china.huawei.com> <4AAA14A8.20101@nict.go.jp> <00ae01ca34e6$74e3a980$260ca40a@china.huawei.com> In-Reply-To: <00ae01ca34e6$74e3a980$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Comments on section 3 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 04:46:29 -0000 Hi, again :) > [Qin]: Since DSRK is calculated based the Domain name, given home domain name > in the home domain I am wondering whether we can derive home domain specific DSRK > based on the home domain name? > It would seem quite logical, but the RFC5295/5296 currently specify a different mechanism for the home domain (rRK)... So no, currently we cannot do that unfortunately. > [Qin]: Okay, I agree with your explainnation. However I have two followup comments as follows: > 1. The home EAP server that uses ERP is the home ER server or not? > Can you define the "home ER server" in the context of your question? We don't use this in the document, I think this terminology is too vague, sorry... > 2. Who actually authorize the use of ERP, home EAP server or home ER server? > The home EAP server when it derives the DSRK from the EMSK, and provide it to a foreign ER server. > [Qin]: I agree, without this assumption, it seems ERP exchange and EAP > Re-authentication operations on the peer, authenticator and server will > be complicated. > I wonder what do you think of the case where the home realm contains several > EAP servers described in the "open issues"section? Isn't it the same thing? > Unfortunately, the architecture for EAP is already defined, so we cannot change it, and it has different assumptions (which are justified because each EAP server may support a different set of EAP methods). So, we have to deal with it, as described in the open issues... BR Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sunseawq@huawei.com Sun Sep 13 23:54:51 2009 Return-Path: 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 8316B3A67B5 for ; Sun, 13 Sep 2009 23:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=1.440, 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 PtHWqyIkxbck for ; Sun, 13 Sep 2009 23:54:50 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 204103A67DF for ; Sun, 13 Sep 2009 23:54:50 -0700 (PDT) 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 <0KPY00FAH8KKC9@szxga01-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 14:55:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPY00JSB8KKCW@szxga01-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 14:55:32 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPY0067I8KJ13@szxml04-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 14:55:32 +0800 (CST) Date: Mon, 14 Sep 2009 14:55:31 +0800 From: Qin Wu To: Sebastien Decugis , dime@ietf.org Message-id: <015501ca3508$5a097460$260ca40a@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=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <01df01ca3101$7aba52c0$260ca40a@china.huawei.com> <4AAA0DF2.9000806@nict.go.jp> <00ac01ca34e6$64f43990$260ca40a@china.huawei.com> <4AADC515.9000609@nict.go.jp> Subject: Re: [Dime] Comments on abstract and section 1 of newversiondraft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 06:54:51 -0000 Hi,Sebastien: ----- Original Message ----- From: "Sebastien Decugis" To: Sent: Monday, September 14, 2009 12:22 PM Subject: Re: [Dime] Comments on abstract and section 1 of newversiondraft-ietf-dime-erp-01 > Hi Qin, > >> As regarding "EAP/ERP authenticator", I think the definition of authenticator >> has already implied that it supports EAP authentication, ERP is a extension to EAP, >> So it seems not neccessary to emphasize whether authenticator support EAP. > I understand your point now, thank you. Since it's only the abstract, I > think we should try and avoid using too much abbreviations such as "ER". > I'll change to more explicit language using words instead of acronyms. [Qin]: Okay. >>> Explicit bootstrapping in a kind of special case: the re-authentication >>> happens between peer and home ER server, and also carries the key >>> material for the local ER server. Therefore it is a "step 2" for the >>> home server and "step 1" for the local server. In any case, the home >>> server must already be bootstrapped -- or collocated with the EAP >>> server, as we currently assume, and derive the key when it is needed. >>> But from a process point of view, I believe these two separate steps >>> still apply to any ERP exchange -- only the timing may be different with >>> some scenarios. Does this clarify the text? >>> >> >> [Qin]: What I am difficult to understand is Explicit bootstrapping actually can be understand >> as full ERP authentication with the home ER server. Because Explicit bootstrapping uses ERP message >> with bootstrapping flag turned on to request the key materials. > It's actually a strange behavior of ERP (which I hope would be fixed in > new revision if any): the peer sets the B flag to request for key > material on behalf of an hypothetic local ER server... [Qin]: It is not very strange to me. Because it is not the ER server but the peer to do bootstrapping. So it is natual for peer to set B flag in the ERP message. when the peer gets response from the home server, the peer need to compute DSRK, DS-rRK, DS-rIK, and keyName- NAI based on the local domain name and install these key on the peer. That's what is called "bootstrapping", in my understanding. >In explicit bootstrapping we have really two different things in the same exchange: > 1) peer <-> home server : re-authentication > 2) local ER server <-> home server : bootstrapping > For (1) to occur, it supposes that the home server already have the key > material. Therefore it is either collocated with EAP server (and so the > key material is locally available) or has already bootstrapped > previously (kind of recursive architecture in this case). [Qin] Unlike explicit bootstrapping, Implicit bootstrapping only has 2) in the exchange. 1) does not happen in the implicit bootstrapping. Am I right? So I am wondering whether we can say ERP has two steps? or we just say Explicit ERP bootstrapping has two step or two phase. Another concern is whether we can say local ER server<--> home ER server can be viewed as "bootstrapping"? How to understand bootstrapping? >> To avoid confusion, how about say: >> step 1 is for Re-auth root key transport, >> Step 2 is for Re-authentication, i.e., using key material from step 1 to perform Re-auth. >> > I don't see the difference between your proposal and the current text... > Can you highlight what is changed? [Qin]: The difference is using *Re-auth root key transport* instead of *Bootstrapping* Because I am afraid that bootstrapping is not used by local server but by the peer to request Re-authentication key. What do you think of it? > Thanks , > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sunseawq@huawei.com Mon Sep 14 00:19:35 2009 Return-Path: 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 34D9628C117 for ; Mon, 14 Sep 2009 00:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.156 X-Spam-Level: X-Spam-Status: No, score=-0.156 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 xxn3J7R8dMTz for ; Mon, 14 Sep 2009 00:19:34 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E63C428C11D for ; Mon, 14 Sep 2009 00:19:33 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPY0081O9PJNL@szxga04-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 15:20:07 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPY00GBI9PJNS@szxga04-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 15:20:07 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPY009QY9PI2U@szxml06-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 15:20:07 +0800 (CST) Date: Mon, 14 Sep 2009 15:20:06 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <015f01ca350b$c950d270$260ca40a@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=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <01e301ca3101$8feef150$260ca40a@china.huawei.com> <4AAA0F84.3010601@nict.go.jp> <00ad01ca34e6$6f603960$260ca40a@china.huawei.com> <4AADC86B.7060904@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] Comments on section 2 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 07:19:35 -0000 Hi, Sebastien: ----- Original Message ----- From: "Sebastien Decugis" To: "Qin Wu" Cc: Sent: Monday, September 14, 2009 12:36 PM Subject: Re: [Dime] Comments on section 2 of new version draft-ietf-dime-erp-01 > Hi, > >> [Qin]: >> If only the local server support ERP, I think it is necessary for local ER server to change >> its application ID from ERP to EAP. >> However If the local server and home server both support ERP, I don't think >> it is necessary for local ER server to change its application ID from ERP to EAP, >> am I right? >> > The EMSK is located on the EAP server, not ER server. For bootstrapping, > the message *must* therefore reach the *EAP* server. We might go through > the ER server in the home domain but it would be just an additional > useless relay... > The reason for changing the application Id is routing of the message to > the proper server (the one that has the EMSK). > Of course if there is only one server in the domain, the application Id > can be anything... But we want to separate the logical entities... [Qin]: Sorry for your misunderstanding here. what I want to say here is suppose both the local ER server and the home ER server support *EAP*, we can simply assume the home EAP server and the peer has already export the same EMSK during the initial EAP exchange. In this way, the Re-authentication root key can be derived from EMSK. There is no extra delay to be introduced. >>>> another example when home EAP server does not support ERP >>> In that case, the ER server cannot obtain the root key required for ERP >>> function... >> [Qin]: In the Implicit Bootstrapping, the local ER server can obtain the root key >> from the home EAP server through local AAA agent or proxy.You can check >> the following errata report in the hokey ML: >> http://www.ietf.org/mail-archive/web/hokey/current/msg01662.html >> In this scenario, the local ER can fetch root key from the local AAA agent or >> the local AAA agent can manually install root key on the local ER, am I right? >> > Well, even if the errata says so, if the EAP server is not able to > derive ERP material, I cannot see how the AAA server (a third entity?) > would be able to obtain it... > Furthermore, this errata assumes that some protocol such as Diameter is > available to do all the operations it describes. If we want to > accommodate such architecture, we have to define new messages for key > exchanges only (maybe even another Diameter application Id). Anyway, I > don't see the benefit of this compared to the architecture we define > currently... I think this can be discussed in next IETF meeting with > interested people. [Qin]: Sorry for your misunderstanding, Here mentioned AAA server or AAA agent is not third entity but the EAP sever. So it is not necessary to define new message for key exchange here. If the EAP sever is not able to derive ERP stuff, the ERP exchange will fail and fall back to the full EAP exchange. >> [Qin]: Sorry for your misunderstanding. I just want to figure out in which scenario EAP/DER >> and EAP/DEA will be used? >> In my understanding, If the home server does not support ERP, the local ER server collocated with >> the local AAA agent, we can use EAP/DER and EAP/DEA, in this sense, we need to change application ID from >> EAP to ERP, as you mentioned above. >> > As I wrote earlier, the rationale for changing the application Id is to > route the message to the server that has the EMSK material, which is > needed for bootstrapping. > > Unfortunately, so far we don't consider the situation where several EAP > servers are in the home domain (and only 1 has the EMSK). It must be > addressed. [Qin]: Okay. Suppose there is serveral EAP servers in the home domain, If one EAP server can not use specific EAP method to export EMSK, why do we need to deploy such kind of EAP server? > BR > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From sunseawq@huawei.com Mon Sep 14 00:40:10 2009 Return-Path: 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 53EB93A68E9 for ; Mon, 14 Sep 2009 00:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 dRXcgzhcWKKp for ; Mon, 14 Sep 2009 00:40:09 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id DC7413A67B5 for ; Mon, 14 Sep 2009 00:40:07 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPY00BNYANS22@szxga02-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 15:40:41 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPY003QMANSV2@szxga02-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 15:40:40 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPY00D33ANSPT@szxml06-in.huawei.com> for dime@ietf.org; Mon, 14 Sep 2009 15:40:40 +0800 (CST) Date: Mon, 14 Sep 2009 15:40:40 +0800 From: Qin Wu To: Sebastien Decugis , dime@ietf.org Message-id: <016501ca350e$a889d520$260ca40a@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=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <01e701ca3101$93daaa70$260ca40a@china.huawei.com> <4AAA14A8.20101@nict.go.jp> <00ae01ca34e6$74e3a980$260ca40a@china.huawei.com> <4AADCAC5.9010007@nict.go.jp> Subject: Re: [Dime] Comments on section 3 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 07:40:10 -0000 Hi, Sebastien: ----- Original Message ----- From: "Sebastien Decugis" To: Sent: Monday, September 14, 2009 12:47 PM Subject: Re: [Dime] Comments on section 3 of new version draft-ietf-dime-erp-01 > Hi, again :) > >> [Qin]: Since DSRK is calculated based the Domain name, given home domain name >> in the home domain I am wondering whether we can derive home domain specific DSRK >> based on the home domain name? >> > It would seem quite logical, but the RFC5295/5296 currently specify a > different mechanism for the home domain (rRK)... So no, currently we > cannot do that unfortunately. [Qin]: Okay. I agree with you. But based on the definition of rRK, rRK is not derived based on domain name. >> [Qin]: Okay, I agree with your explainnation. However I have two followup comments as follows: >> 1. The home EAP server that uses ERP is the home ER server or not? >> > Can you define the "home ER server" in the context of your question? We > don't use this in the document, I think this terminology is too vague, > sorry... [Qin] Home ER server is defined in the section 2 of RFC5296. Home ER server is refered as an logical entity that performs the server portion of ERP in the home domain. >> 2. Who actually authorize the use of ERP, home EAP server or home ER server? >> > The home EAP server when it derives the DSRK from the EMSK, and provide > it to a foreign ER server. [Qin]: What you said here is not consistent with what RFC5296 describes. According to the section 5.1 of RFC5296, it said: " the home ER server MUST include the DSRK for the local ER server (derived using the EMSK and the domain name as specified in [3]), EMSKname, and DSRK lifetime along with the EAP- Finish/Re-auth message. " Based the above description, it is home ER server to derive DSRK from the EMSK. Am I missing something? >> [Qin]: I agree, without this assumption, it seems ERP exchange and EAP >> Re-authentication operations on the peer, authenticator and server will >> be complicated. >> I wonder what do you think of the case where the home realm contains several >> EAP servers described in the "open issues"section? Isn't it the same thing? >> > Unfortunately, the architecture for EAP is already defined, so we cannot > change it, and it has different assumptions (which are justified because > each EAP server may support a different set of EAP methods). So, we have > to deal with it, as described in the open issues... [Qin]: In this sense, does it mean each EAP server only support one EAP method? Given the home realm name, how the foreign ER server route the message to the given EAP server which support the same EAP method as the peer? > BR > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Mon Sep 14 01:33:56 2009 Return-Path: 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 A73073A68F2 for ; Mon, 14 Sep 2009 01:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 43pQAsMRdGju for ; Mon, 14 Sep 2009 01:33:55 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 31AD83A68BC for ; Mon, 14 Sep 2009 01:33:54 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n8E8Ybkr000485 for ; Mon, 14 Sep 2009 17:34:37 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n8E8YbCp014211 for ; Mon, 14 Sep 2009 17:34:37 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n8E8YbCH014208 for ; Mon, 14 Sep 2009 17:34:37 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 61C342C380 for ; Mon, 14 Sep 2009 17:34:37 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 5D3DD2C37D for ; Mon, 14 Sep 2009 17:34:37 +0900 (JST) Message-ID: <4AAE0012.508@nict.go.jp> Date: Mon, 14 Sep 2009 17:34:26 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: dime@ietf.org References: <01df01ca3101$7aba52c0$260ca40a@china.huawei.com> <4AAA0DF2.9000806@nict.go.jp> <00ac01ca34e6$64f43990$260ca40a@china.huawei.com> <4AADC515.9000609@nict.go.jp> <015501ca3508$5a097460$260ca40a@china.huawei.com> In-Reply-To: <015501ca3508$5a097460$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Comments on abstract and section 1 of newversiondraft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 08:33:56 -0000 Hi again, > [Qin]: It is not very strange to me. Because it is not the ER server but the peer to do bootstrapping. > So it is natual for peer to set B flag in the ERP message. when the peer gets response from the home server, > the peer need to compute DSRK, DS-rRK, DS-rIK, and keyName- NAI based on the local domain name > and install these key on the peer. That's what is called "bootstrapping", in my understanding. > The peer does not receive any key material during the ERP exchange: it already possess the EMSK. The only eventual benefit for the peer in explicit bootstrapping is to learn the domain of the local ER server. The main goal is the bootstrapping of this local server, IIUC. >> In explicit bootstrapping we have really two different things in the same exchange: >> 1) peer <-> home server : re-authentication >> 2) local ER server <-> home server : bootstrapping >> For (1) to occur, it supposes that the home server already have the key >> material. Therefore it is either collocated with EAP server (and so the >> key material is locally available) or has already bootstrapped >> previously (kind of recursive architecture in this case). >> > > [Qin] Unlike explicit bootstrapping, Implicit bootstrapping only has 2) in the exchange. > 1) does not happen in the implicit bootstrapping. Am I right? > Yes that is right for the bootstrapping exchange; but then later ERP exchange are performed to actually re-authenticate the peer. > Another concern is whether we can say local ER server<--> home ER server can be viewed as "bootstrapping"? > How to understand bootstrapping? > Bootstrapping is providing the ERP root key to the ER server that need it, to perform the re-authentication of the peer. > [Qin]: The difference is using *Re-auth root key transport* instead of *Bootstrapping* > Because I am afraid that bootstrapping is not used by local server but by the peer to request Re-authentication key. > What do you think of it? > Well, since bootstrapping is creating and transporting the key material to the ER server, I still think it is equivalent :) The peer never request any key to the server, otherwise there would be no security... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Mon Sep 14 18:51:22 2009 Return-Path: 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 36F643A681C for ; Mon, 14 Sep 2009 18:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.823 X-Spam-Level: X-Spam-Status: No, score=-0.823 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 MZF4QvrWV74T for ; Mon, 14 Sep 2009 18:51:21 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id B6FC63A6814 for ; Mon, 14 Sep 2009 18:51:20 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n8F1q52j029780 for ; Tue, 15 Sep 2009 10:52:05 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n8F1q5CM025304 for ; Tue, 15 Sep 2009 10:52:05 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n8F1q5jn025301 for ; Tue, 15 Sep 2009 10:52:05 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 050452C545 for ; Tue, 15 Sep 2009 10:52:05 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail2.nict.go.jp (NICT Mail) with ESMTP id F36BA2C510 for ; Tue, 15 Sep 2009 10:52:04 +0900 (JST) Message-ID: <4AAEF33D.9050202@nict.go.jp> Date: Tue, 15 Sep 2009 10:51:57 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: dime@ietf.org References: <01e301ca3101$8feef150$260ca40a@china.huawei.com> <4AAA0F84.3010601@nict.go.jp> <00ad01ca34e6$6f603960$260ca40a@china.huawei.com> <4AADC86B.7060904@nict.go.jp> <015f01ca350b$c950d270$260ca40a@china.huawei.com> In-Reply-To: <015f01ca350b$c950d270$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Comments on section 2 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 01:51:22 -0000 Hi, Sorry for late answer. > [Qin]: Sorry for your misunderstanding here. what I want to say here is > suppose both the local ER server and the home ER server support *EAP*, > ... > we can simply assume the home EAP server and the peer has already export > the same EMSK during the initial EAP exchange. That's the base assumption of ERP, yes. > In this way, the Re-authentication > root key can be derived from EMSK. There is no extra delay to be introduced. > Do you mean that intermediary nodes (such as local ER server) can derive the EMSK also? This would be a security issue... > [Qin]: Sorry for your misunderstanding, Here mentioned AAA server or AAA agent is not third entity but the EAP sever. > So it is not necessary to define new message for key exchange here. If the EAP sever is not able to derive ERP stuff, > the ERP exchange will fail and fall back to the full EAP exchange. > I think this is what is written in the document, yes... > [Qin]: Okay. > Suppose there is serveral EAP servers in the home domain, > If one EAP server can not use specific EAP method to export EMSK, why do we > need to deploy such kind of EAP server? > There can be several EAP servers that are able to derive EMSK... Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Mon Sep 14 19:00:04 2009 Return-Path: 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 6E3E33A681E for ; Mon, 14 Sep 2009 19:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 n7cG4z2oiAFW for ; Mon, 14 Sep 2009 19:00:03 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id CBADD3A67E2 for ; Mon, 14 Sep 2009 19:00:02 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n8F20ZSA008354; Tue, 15 Sep 2009 11:00:35 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n8F20Zd7029728; Tue, 15 Sep 2009 11:00:35 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n8F20ZFG029725; Tue, 15 Sep 2009 11:00:35 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 3A4CE2C539; Tue, 15 Sep 2009 11:00:35 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 354D32C510; Tue, 15 Sep 2009 11:00:35 +0900 (JST) Message-ID: <4AAEF53B.1020605@nict.go.jp> Date: Tue, 15 Sep 2009 11:00:27 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Qin Wu References: <01e701ca3101$93daaa70$260ca40a@china.huawei.com> <4AAA14A8.20101@nict.go.jp> <00ae01ca34e6$74e3a980$260ca40a@china.huawei.com> <4AADCAC5.9010007@nict.go.jp> <016501ca350e$a889d520$260ca40a@china.huawei.com> In-Reply-To: <016501ca350e$a889d520$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Comments on section 3 of new version draft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 02:00:04 -0000 Hi, >>> 1. The home EAP server that uses ERP is the home ER server or not? >>> >>> >> Can you define the "home ER server" in the context of your question? We >> don't use this in the document, I think this terminology is too vague, >> sorry... >> > > [Qin] Home ER server is defined in the section 2 of RFC5296. > Home ER server is refered as an logical entity that performs the server portion of ERP > in the home domain. > The "server portion of ERP" is the key derivation, right? >>> 2. Who actually authorize the use of ERP, home EAP server or home ER server? >>> >>> >> The home EAP server when it derives the DSRK from the EMSK, and provide >> it to a foreign ER server. >> > > [Qin]: What you said here is not consistent with what RFC5296 describes. According to the section 5.1 of RFC5296, > it said: > " > the home ER server MUST include the DSRK for the > local ER server (derived using the EMSK and the domain name as > specified in [3]), EMSKname, and DSRK lifetime along with the EAP- > Finish/Re-auth message. > " > Based the above description, it is home ER server to derive DSRK from the EMSK. > Am I missing something? > Yes: the EMSK is on the EAP server, nowhere else. So only the EAP server can use it for any purpose... > [Qin]: > In this sense, does it mean each EAP server only support one EAP method? > no > Given the home realm name, how the foreign ER server route the message to > the given EAP server which support the same EAP method as the peer? > For full EAP, the first message is routed by a proxy based on the EAP method; the following messages use the Destination-Host AVP. In ERP we should use Destination-Host also, but it is in open issues for the moment. If you have ideas on how to solve it cleanly... Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sunseawq@huawei.com Mon Sep 14 20:14:43 2009 Return-Path: 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 D37C03A685A for ; Mon, 14 Sep 2009 20:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 DLJZya8K74z9 for ; Mon, 14 Sep 2009 20:14:42 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 958E73A67D3 for ; Mon, 14 Sep 2009 20:14:42 -0700 (PDT) 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 <0KPZ001FRT1HPL@szxga01-in.huawei.com> for dime@ietf.org; Tue, 15 Sep 2009 11:15:18 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPZ001O0T1H6M@szxga01-in.huawei.com> for dime@ietf.org; Tue, 15 Sep 2009 11:15:17 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPZ009DVT1FWB@szxml06-in.huawei.com> for dime@ietf.org; Tue, 15 Sep 2009 11:15:17 +0800 (CST) Date: Tue, 15 Sep 2009 11:15:14 +0800 From: Qin Wu To: Sebastien Decugis , dime@ietf.org Message-id: <02c001ca35b2$c02484b0$260ca40a@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=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <01df01ca3101$7aba52c0$260ca40a@china.huawei.com> <4AAA0DF2.9000806@nict.go.jp> <00ac01ca34e6$64f43990$260ca40a@china.huawei.com> <4AADC515.9000609@nict.go.jp> <015501ca3508$5a097460$260ca40a@china.huawei.com> <4AAE0012.508@nict.go.jp> Subject: Re: [Dime] Comments on abstract and section 1 ofnewversiondraft-ietf-dime-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 03:14:44 -0000 Hi, Sebastien: ----- Original Message ----- From: "Sebastien Decugis" To: Sent: Monday, September 14, 2009 4:34 PM Subject: Re: [Dime] Comments on abstract and section 1 ofnewversiondraft-ietf-dime-erp-01 > Hi again, > >> [Qin]: It is not very strange to me. Because it is not the ER server but the peer to do bootstrapping. >> So it is natual for peer to set B flag in the ERP message. when the peer gets response from the home server, >> the peer need to compute DSRK, DS-rRK, DS-rIK, and keyName- NAI based on the local domain name >> and install these key on the peer. That's what is called "bootstrapping", in my understanding. >> > The peer does not receive any key material during the ERP exchange: it > already possess the EMSK. The only eventual benefit for the peer in > explicit bootstrapping is to learn the domain of the local ER server. > The main goal is the bootstrapping of this local server, IIUC. [Qin]: I agree key derivation and transport happens during bootstrapping, But I am still difficult to understand bootstrapping is identical to key transport. on the other hand, as described in the section 5.1 of RFC5296: " The peer MAY also* initiate bootstrapping* to fetch information ++++++++++++++++ such as the rRK lifetime from the AAA server. " From the above description, it is the peer who accomplish bootstrapping, if we say local server is bootstrapped, I am wondering whether it is consistent with the description in the RFC5296,what am I missing? Another reason is during bootstrapping, it is not the local server but the peer who turn on "bootstrapping" flag in the ERP message. Is it enough to justify who make bootstrapping? -:) >>> In explicit bootstrapping we have really two different things in the same exchange: >>> 1) peer <-> home server : re-authentication >>> 2) local ER server <-> home server : bootstrapping >>> For (1) to occur, it supposes that the home server already have the key >>> material. Therefore it is either collocated with EAP server (and so the >>> key material is locally available) or has already bootstrapped >>> previously (kind of recursive architecture in this case). >>> >> >> [Qin] Unlike explicit bootstrapping, Implicit bootstrapping only has 2) in the exchange. >> 1) does not happen in the implicit bootstrapping. Am I right? >> > Yes that is right for the bootstrapping exchange; but then later ERP > exchange are performed to actually re-authenticate the peer. [Qin]: I am wondering whether the implicit bootstrapping can be viewed as part of ERP? >> Another concern is whether we can say local ER server<--> home ER server can be viewed as "bootstrapping"? >> How to understand bootstrapping? >> > Bootstrapping is providing the ERP root key to the ER server that need > it, to perform the re-authentication of the peer. [Qin]: Isn't consistent with bootstrapping described in RFC5296? >> [Qin]: The difference is using *Re-auth root key transport* instead of *Bootstrapping* >> Because I am afraid that bootstrapping is not used by local server but by the peer to request Re-authentication key. >> What do you think of it? >> > Well, since bootstrapping is creating and transporting the key material > to the ER server, I still think it is equivalent :) The peer never > request any key to the server, otherwise there would be no security... [Qin] I neve say the peer need to request any key from the server. The peer can fetch local domain name during explicit ERP bootstrapping and base on local name to derive Re-auth root keys, isn't it termed bootstrapping? :-) Anyway, if you can redefine bootstrapping in the document different from RFC5296, that's another thing. > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From root@core3.amsl.com Tue Sep 22 06:15:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A3A9B3A69F6; Tue, 22 Sep 2009 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090922131501.A3A9B3A69F6@core3.amsl.com> Date: Tue, 22 Sep 2009 06:15:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-pmip6-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 13:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-pmip6-04.txt Pages : 21 Date : 2009-09-22 This specification defines Authentication, Authorization, and Accounting interactions between Proxy Mobile IPv6 entities (both Mobile Access Gateway and Local Mobility Anchor) and an Authentication, Authorization, and Accounting server within a Proxy Mobile IPv6 Domain. These Authentication, Authorization, and Accounting interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-pmip6-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-22061138.I-D@ietf.org> --NextPart-- From j4copley@yahoo.com Wed Sep 23 06:23:37 2009 Return-Path: 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 E683F3A6883 for ; Wed, 23 Sep 2009 06:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 K+twlIeCiCEW for ; Wed, 23 Sep 2009 06:23:37 -0700 (PDT) Received: from n1.bullet.mail.re3.yahoo.com (n1.bullet.mail.re3.yahoo.com [68.142.237.108]) by core3.amsl.com (Postfix) with SMTP id F31A828C0F9 for ; Wed, 23 Sep 2009 06:23:36 -0700 (PDT) Received: from [68.142.237.89] by n1.bullet.mail.re3.yahoo.com with NNFMP; 23 Sep 2009 13:24:40 -0000 Received: from [216.252.111.167] by t5.bullet.re3.yahoo.com with NNFMP; 23 Sep 2009 13:24:40 -0000 Received: from [127.0.0.1] by omp102.mail.re3.yahoo.com with NNFMP; 23 Sep 2009 13:24:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 655009.28372.bm@omp102.mail.re3.yahoo.com Received: (qmail 64409 invoked by uid 60001); 23 Sep 2009 13:24:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253712280; bh=5meN5TAYz4nN5M42i8FpaQuu4rHkQgwe61degwC6lWs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=2+XVbnO/7M7RPWCRDYxjn2uB0urkto15AAZTQOfsWNil4MBxPzFEUEXjVfEUonqqwCjnPl9eDGUh6OAQRqKLclsdpmiz8ZUF0/wELVrFU3GUwk+NN5zenbSQIzraCbo/GNMjI7odA2eiT/RHQ33VYpfEXfXDR9F/9Ilp9worJb0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=eD/bUrh+yNI0IlPkbCrVvrJR53q+rWFXeFydCZV6wCxl9SJY+gOgn9v8KzP1AcL6AuBd7G0auQKahhr37Lp3fY812wNF3sm+fPD1jaxscPJifuHhIT8DGYBb5A5+pArZQ4IztqWUl3zhX7ZLucVJltZF27s11THmQ1EQASr856w=; Message-ID: <473400.63963.qm@web57002.mail.re3.yahoo.com> X-YMail-OSG: pf.ZGGMVM1n.UbwRaK599T64QJiHUzZyBVUwipoDjmt4p72IuLRZD7toRJIfY69ly1f8qRccdlHvJKAyvhEFJ5Ca0mq2u8ZvA8eMTEcqwD7lEYt7mS3VZsng.q3uvRRTNfhMFosenZZRH1M1Pvr6xPHFdhRm_6_bb.mZxyMmMFuJZfk_WZVrN0sMsqHiJlIT1oAvAAybEnsoBXc5zpr4NJscd7jFnm14_nZfBMzLmxidFsNqGb2VGAiyGzMByjbVD9.S7HDmr3TeWE7bN7R1XzdWqmr_enEZ3.TeF4T2cmMVYvjhTKs- Received: from [192.65.45.25] by web57002.mail.re3.yahoo.com via HTTP; Wed, 23 Sep 2009 06:24:40 PDT X-Mailer: YahooMailClassic/7.0.14 YahooMailWebService/0.7.347.2 Date: Wed, 23 Sep 2009 06:24:40 -0700 (PDT) From: jc To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Dime] Diameter SCTP PPId X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 13:59:14 -0000 I looked through past posts and on IANA site and did not find where an SCTP Payload Protocol Identifier has been assigned for Diameter. Has this been addressed? My apologies if this has and I missed it. From wwwrun@core3.amsl.com Mon Sep 28 11:36:54 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3A5B228C0FA; Mon, 28 Sep 2009 11:36:53 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090928183654.3A5B228C0FA@core3.amsl.com> Date: Mon, 28 Sep 2009 11:36:54 -0700 (PDT) Cc: Internet Architecture Board , dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server' to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 18:36:54 -0000 The IESG has approved the following document: - 'Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server ' as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-04.txt Technical Summary This specification defines the Diameter support for the Proxy Mobile IPv6 and the corresponding mobility service session setup. The policy information needed by the Proxy Mobile IPv6 is defined in mobile node's policy profile, which could be downloaded from the Diameter server to the Mobile Access Gateway once the mobile node attaches to a Proxy Mobile IPv6 Domain and performs access authentication. During the binding update exchange between the Mobile Access Gateway and the Local Mobility Anchor, the Local Mobility Anchor can interact with the Diameter server in order to update the remote policy store with the mobility session related information. Working Group Summary This document was progressed through the DIME working group without delays or problems. Document Quality This document is the product of the DIME working group. with support from the NETLMM WG. It is anticipated thatvendors interested in Proxy Mobile IP are also going to implement the client side part of this protocol. The current implementation status of this specification is, however, unknown. Personnel Hannes Tschofenig is the document shepherd for this document. Dan Romascanu is the responsible AD. From b.swamy@aricent.com Wed Sep 30 02:07:23 2009 Return-Path: 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 6D4D328C0D9 for ; Wed, 30 Sep 2009 02:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6] 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 JYo7RxX461fl for ; Wed, 30 Sep 2009 02:07:18 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [125.21.164.247]) by core3.amsl.com (Postfix) with ESMTP id BC4143A6A2D for ; Wed, 30 Sep 2009 02:07:17 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id n8U8qQcn022789 for ; Wed, 30 Sep 2009 14:22:26 +0530 Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id n8U8qQd9022729 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 30 Sep 2009 14:22:26 +0530 Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Wed, 30 Sep 2009 14:38:32 +0530 From: B Venkat S R Swamy To: "dime@ietf.org" Date: Wed, 30 Sep 2009 14:38:23 +0530 Thread-Topic: Retransmission of Pending Requests on Failover Thread-Index: AcpBrY/G516AqdecSDSsRvTLLnRRMA== Message-ID: <079B6109FD98AD488574FF3191B508BE0173657E4F@GUREXMB01.ASIAN.AD.ARICENT.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_079B6109FD98AD488574FF3191B508BE0173657E4FGUREXMB01ASIA_" MIME-Version: 1.0 Subject: [Dime] Retransmission of Pending Requests on Failover X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 09:07:23 -0000 --_000_079B6109FD98AD488574FF3191B508BE0173657E4FGUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi As per section 5.5.4 of the RFC 3588, it is mentioned that: "In the event that a transport failure is detected with a peer, it is neces= sary for all pending request messages to be forwarded to an alternate agent= , if possible." However in the same section, it is also written that: "An example of a case where it is not possible to forward the message to an= alternate server is when the message has a fixed destination, and the unavailable peer is the message's final destination (see Destinatio= n-Host AVP)." Now does that mean that in case of session based interfaces, wherein after = the response to the Start CCR, the diameter client is aware of the Destinat= ion-Host and hence for subsequent messages such as Interim/Stop CCR there s= hould not be any retransmission of these session messages to secondary peer= if the primary peer is down. In a scenario where primary peer is able to replicate session contexts to s= econdary peer, it should be possible to retransmit the interim/stop CCR req= uest to secondary peer, in case primary peer is down. Would request Diameter gurus to clarify the above doubt. regards B. Venkat S.R Swamy ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." --_000_079B6109FD98AD488574FF3191B508BE0173657E4FGUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

As per section 5.5.4 of the RFC 3588, it is mentione= d that:

 

“In the event that a transport failure is dete= cted with a peer, it is necessary for all pending request messages to be fo= rwarded to an alternate agent, if possible.”

 

However in the same section, it is also written that= :

“An example of a case where it is not possible= to forward the message to an alternate server is when the message has a fi= xed destination, and

 the unavailable peer is the message's final de= stination (see    Destination-Host AVP).”

 

Now does that mean that in case of session based int= erfaces, wherein after the response to the Start CCR, the diameter client i= s aware of the Destination-Host and hence for subsequent messages such as I= nterim/Stop CCR there should not be any retransmission of these session messages to secondary peer if the prim= ary peer is down.

 

In a scenario where primary peer is able to replicat= e session contexts to secondary peer, it should be possible to retransmit t= he interim/stop CCR request to secondary peer, in case primary peer is down= .

 

Would request Diameter gurus to clarify the above do= ubt.

 

regards<= /span>

B. Venkat S.R Swamy

 


"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error,please notify the originator immediately. If you = are not the intended recipient, you are notified that you are strictly proh= ibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
 --_000_079B6109FD98AD488574FF3191B508BE0173657E4FGUREXMB01ASIA_--