Re: [HOKEY] Change proposal for ERP-AAK - 3: Multiple CAP case support

Glen Zorn <glenzorn@gmail.com> Wed, 05 October 2011 11:50 UTC

Return-Path: <glenzorn@gmail.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 C3D2821F8D14 for <hokey@ietfa.amsl.com>; Wed, 5 Oct 2011 04:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpc8LiTSORx5 for <hokey@ietfa.amsl.com>; Wed, 5 Oct 2011 04:50:31 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1757B21F8D11 for <hokey@ietf.org>; Wed, 5 Oct 2011 04:50:30 -0700 (PDT)
Received: by qadb12 with SMTP id b12so1419613qad.31 for <hokey@ietf.org>; Wed, 05 Oct 2011 04:53:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8WHJqZ5X9om1mJ/kaGHYqeyQqfFCZl2wNnBmUO7vIQM=; b=EpigOWzDsEWeK/fktEtFCRRTQ8niUucQn/9dZXsOzboKUDQTMGNCfkh/l/lw6TzfZX kOQwNdZUkrS9kqRws+4V+JgJnKDyZfqK+lTpWt71DPrhyWqDS1aBEylJw5t19tDHwLtd YXnWjktsOLP/Bp4AYN3rVdkZe2giqLNd1TFGg=
Received: by 10.224.189.18 with SMTP id dc18mr1832725qab.337.1317815618567; Wed, 05 Oct 2011 04:53:38 -0700 (PDT)
Received: from [192.168.1.98] (ppp-58-11-240-156.revip2.asianet.co.th. [58.11.240.156]) by mx.google.com with ESMTPS id d20sm1726465qak.10.2011.10.05.04.53.35 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 04:53:37 -0700 (PDT)
Message-ID: <4E8C453C.5080400@gmail.com>
Date: Wed, 05 Oct 2011 18:53:32 +0700
From: Glen Zorn <glenzorn@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Qin Wu <bill.wu@huawei.com>
References: <29A088215B784663B37041D5BCD3B130@china.huawei.com>
In-Reply-To: <29A088215B784663B37041D5BCD3B130@china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: hokey@ietf.org
Subject: Re: [HOKEY] Change proposal for ERP-AAK - 3: Multiple CAP case support
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: Wed, 05 Oct 2011 11:50:31 -0000

On 9/29/2011 4:45 PM, Qin Wu wrote:

> Hi,
> As we discussed on the list to the draft-ietf-hokey-erp-aak-04, it is
> not difficult to support multiple CAP(s) case.
> However we should make sure each pMSK is calculated for each CAP using
> different Sequence number, therefore I propose to do the
> following change to allow two ways to avoid the same pMSK derived for
> multiple CAP,
> one way is
> 
> The multiple sequence numbers can be derived from SEQ field in the
> message header by following +1 rule.
> 
> e.g., we have 3 CAP, the SEQ field is set to the value 100
> 
> so the pMSK for CAP A will be derived using seqence number 100.
> 
>     the pMSK for CAP B will be derived using sequence number 100+1
> 
>    the pMSK for CAP C will be derived using sequence number 100+2
> 
>  

OK, how does the AAA server know which CAP to send which key?

> 
> The second way is directly using Sequence number field carried in the TV
> of the message for each CAP,and mandate
> 
> each sequence number asscicated with each CAP must always follow that
> CAP. Also I think if multiple Sequenced number TLV are carried for each CAP,
> 
> the SEQ field in the ERP/AAK message header should be set to smallest 
> value contained in the  Sequenced number TLVs. This is more flexible way
> comparing
> 
> with the first way. But I think it will be better to allow both.

I'm not sure that I understand this, would you mind explaining a little
more?  Also, if both are allowed, which one would be mandatory to implement?

...