[secdir] Secdir review of draft-ietf-kitten-gss-loop-04
Tina TSOU <Tina.Tsou.Zouting@huawei.com> Sun, 15 February 2015 13:13 UTC
Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031371A1B66; Sun, 15 Feb 2015 05:13:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_skRbpR66PW; Sun, 15 Feb 2015 05:13:34 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FB91A1B64; Sun, 15 Feb 2015 05:13:33 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSQ69219; Sun, 15 Feb 2015 13:13:31 +0000 (GMT)
Received: from SZXEML432-HUB.china.huawei.com (10.82.67.209) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 15 Feb 2015 13:13:30 +0000
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.208]) by szxeml432-hub.china.huawei.com ([10.82.67.209]) with mapi id 14.03.0158.001; Sun, 15 Feb 2015 21:13:23 +0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Secdir review of draft-ietf-kitten-gss-loop-04
Thread-Index: AQHQSSEsFCDMb7qIck6QKsq/WsPnVQ==
Date: Sun, 15 Feb 2015 13:13:23 +0000
Message-ID: <DBEACD8F-3B2F-4C56-AC83-47EB6F55E8F9@huawei.com>
References: <05dd01d04831$7f1feb20$7d5fc160$@nict.go.jp>
In-Reply-To: <05dd01d04831$7f1feb20$7d5fc160$@nict.go.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_DBEACD8F3B2F4C56AC8347EB6F55E8F9huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/i759LjMrmZ50-8DSwTIHQlT9vF8>
Cc: "draft-ietf-kitten-gss-loop.all@tools.ietf.org" <draft-ietf-kitten-gss-loop.all@tools.ietf.org>, "kitten-chairs@tools.ietf.org" <kitten-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>
Subject: [secdir] Secdir review of draft-ietf-kitten-gss-loop-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Feb 2015 13:13:46 -0000
Dear all, I have reviewed current version of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. * Section 3.2, page 5: The initiator calls GSS_Init_sec_context(), using the input_context_handle for the current proto-security-context and its fixed set of input parameters, and the input_token received from the acceptor (if not the first iteration of the loop). Your use of proto-security-context would make it seem like this is a parameter specified in RFC2473 but it is not. So I'd recommend to remove the hyphens. (BTW, at times you refer to "proto-security-context" while at others to just "security context"... why?) * Section 3.2, Page 5: (if not the first iteration of the loop) Please rephrase as "(if this is not...)" * Section 3.2, page 5: However, there are some known implementations of certain mechanisms which do produce empty context negotiation tokens. For maximum interoperability, applications should be prepa It would be great if you could provide examples of such implementations. * Section 3.4, page 6 It is likely appropriate for the acceptor to report this error condition to the acceptor via the application's communication channel. It should say: It is likely appropriate for the acceptor to report this error condition to the initiator via the application's communication channel. * Section 3.5, page 7: The GSS acceptor calls GSS_Accept_sec_context(), using the input_context_handle for the current proto-security-context and the input_token received from the initiator Again, remove the hyphens * Section 4.1, page 10 Additional information can be available in GSS-API Naming Extensions, [RFC6680]. s/can be/is/ * Section 5.1: You should clarify what's the convention for the return codes of send_token() and receive_token(). Otherwise it's not clear whether, when you use these functions, you're checking the return codes correctly. Thank you, Tina
- [secdir] Secdir review of draft-ietf-calext-rscal… Takeshi Takahashi
- [secdir] Secdir review of draft-ietf-kitten-gss-l… Tina TSOU
- Re: [secdir] Secdir review of draft-ietf-kitten-g… Benjamin Kaduk