IETF Logo Mail Archive

Re: [HOKEY] WGLC on draft-ietf-hokey-erp-aak

Qin Wu <sunseawq@huawei.com> Mon, 16 May 2011 08:18 UTC

Return-Path: <sunseawq@huawei.com>
X-Original-To: hokey@ietfa.amsl.com
Delivered-To: hokey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6D9E0738; Mon, 16 May 2011 01:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.38
X-Spam-Level:
X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeOlSHnSVv2S; Mon, 16 May 2011 01:18:22 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B4A53E070B; Mon, 16 May 2011 01:18:16 -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 <0LLA001H04EF4S@szxga03-in.huawei.com>; Mon, 16 May 2011 16:18:16 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLA007RC4EFX3@szxga03-in.huawei.com>; Mon, 16 May 2011 16:18:15 +0800 (CST)
Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLA005EJ4EF85@szxml06-in.huawei.com>; Mon, 16 May 2011 16:18:15 +0800 (CST)
Date: Mon, 16 May 2011 16:22:06 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Glen Zorn <gwz@net-zen.net>
Message-id: <00bb01cc13a2$57f3b1c0$46298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <4DC13C44.7070106@net-zen.net> <038001cc0ec3$5298d0e0$46298a0a@china.huawei.com> <4DCF727E.7050700@net-zen.net> <024b01cc1376$98550880$46298a0a@china.huawei.com> <4DD0D31E.5090702@net-zen.net>
Cc: hokey-chairs@ietf.org, hokey@ietf.org, draft-ietf-hokey-erp-aak@tools.ietf.org
Subject: Re: [HOKEY] WGLC on draft-ietf-hokey-erp-aak
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 May 2011 08:18:23 -0000

Hi,
----- Original Message ----- 
From: "Glen Zorn" <gwz@net-zen.net>
To: "Qin Wu" <sunseawq@huawei.com>
Cc: <hokey@ietf.org>rg>; <hokey-chairs@ietf.org>rg>; <draft-ietf-hokey-erp-aak@tools.ietf.org>
Sent: Monday, May 16, 2011 3:32 PM
Subject: Re: [HOKEY] WGLC on draft-ietf-hokey-erp-aak


> On 5/16/2011 10:08 AM, Qin Wu wrote:
> 
> ...
> 
>>>>>
>>>>> Section 7 last setence:
>>>>>    [Qin]: Remove the last sentence since we can resue the extisting AAA message.
>> 
>> What message did you have in mind?  I can't think of any that do what is
>> necessary.
>> 
>>> [Qin]: I think Diameter DEA/DER message can be reused. You don't think so?
> 
> For the response to the SAP (which seems to be missing from the
> protocol, BTW: How does the peer know whether or not the domain in which
> the CAP resides supports ERP-AAK or not?  It seems like a fair amount of
> time could be saved with a confirmation before movement), yes, I think
> so.  However a the Diameter peer will not be expecting a DEA containing
> the new keying material.  I suppose that we could rework the DER/DEA
> messages so that the DER came from the Diameter "server", though.

[Qin]: I think you are talking about capability negotation.
I assume Diameter Server has the knowledge if the CAP support ERP-AAK.
In this case, the Diameter Server can tell the peer if the CAP support ERP-AAK
by sending EAP-Finish.
If Diameter Server doesn't know if the CAP support ERP-AAK, AAA exchange for 
capablity negotiation between Diameter Server and CAP is required.
Another possible way is through authenticator discovery. The peer can know both CAPs and 
whether these CAPs support ERP-AAK.

v2.8.7 | Report a Bug | By Email