[HOKEY] Change proposal for ERP-AAK - 4: Cryptosuite
Qin Wu <bill.wu@huawei.com> Thu, 29 September 2011 09:52 UTC
Return-Path: <bill.wu@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 BF9D821F8B34 for <hokey@ietfa.amsl.com>; Thu, 29 Sep 2011 02:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.726
X-Spam-Level:
X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
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 PJ03UDc-uF-D for <hokey@ietfa.amsl.com>; Thu, 29 Sep 2011 02:52:31 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6314B21F8B5F for <hokey@ietf.org>; Thu, 29 Sep 2011 02:52:29 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSA00H5I3K7SC@szxga05-in.huawei.com> for hokey@ietf.org; Thu, 29 Sep 2011 17:55:19 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSA00KCG3K5AP@szxga05-in.huawei.com> for hokey@ietf.org; Thu, 29 Sep 2011 17:55:19 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEF30845; Thu, 29 Sep 2011 17:55:18 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 29 Sep 2011 17:55:12 +0800
Received: from w53375q (10.138.41.130) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 29 Sep 2011 17:55:07 +0800
Date: Thu, 29 Sep 2011 17:55:07 +0800
From: Qin Wu <bill.wu@huawei.com>
X-Originating-IP: [10.138.41.130]
To: hokey@ietf.org
Message-id: <B524A026157341B4985D2CC8ED97CD04@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: multipart/alternative; boundary="Boundary_(ID_98p7d1CEYWS2GRoyCkomYw)"
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
Subject: [HOKEY] Change proposal for ERP-AAK - 4: Cryptosuite
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: Thu, 29 Sep 2011 09:52:31 -0000
Hi, I notice we didn't assign TLV type values from the registry of EAP Initiate and Finish Attributes for Cryptosuite. That is becos we reuse Cryptosuite TLV payload defined in the RFC5296, however it doesn't look clear about this in the new version of draft-ietf-hokey-erp-aak, therefore I propose to do the following change: OLD TEXT: " List of Cryptosuites: This is a sub-TLV payload. The Type is TBD. The value field contains a list of cryptosuites, each 1 octet in length. The allowed cryptosuite values are as specified in Section 5.2, above. The server SHOULD include this attribute if the cryptosuite used in the EAP-Initiate/Re-auth message was not acceptable and the message is being rejected. The server MAY include this attribute in other cases. The server MAY use this attribute to signal to the peer about its cryptographic algorithm capabilities. " NEW TEXT: " List of Cryptosuites: This is a sub-TLV payload defined in RFC5296 with the type 5. The value field contains a list of cryptosuites, each 1 octet in length. The allowed cryptosuite values are as specified in Section 5.2, above. The server SHOULD include this attribute if the cryptosuite used in the EAP-Initiate/Re-auth message was not acceptable and the message is being rejected. The server MAY include this attribute in other cases. The server MAY use this attribute to signal to the peer about its cryptographic algorithm capabilities. " Regards! -Qin