Re: [secdir] Secdir review of draft-ietf-kitten-gss-loop-04

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 18 February 2015 04:01 UTC

Return-Path: <kaduk@mit.edu>
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 DFE8B1A916F; Tue, 17 Feb 2015 20:01:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4ME1auxUTuAh; Tue, 17 Feb 2015 20:01:20 -0800 (PST)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C671A8AF6; Tue, 17 Feb 2015 20:01:19 -0800 (PST)
X-AuditID: 1209190f-f79546d000007593-d3-54e40e8d97ae
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 56.E9.30099.E8E04E45; Tue, 17 Feb 2015 23:01:18 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t1I41GSP009798; Tue, 17 Feb 2015 23:01:17 -0500
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1I41DSS011259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2015 23:01:15 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1I41DY3017027; Tue, 17 Feb 2015 23:01:13 -0500 (EST)
Date: Tue, 17 Feb 2015 23:01:13 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
In-Reply-To: <DBEACD8F-3B2F-4C56-AC83-47EB6F55E8F9@huawei.com>
Message-ID: <alpine.GSO.1.10.1502172248560.3953@multics.mit.edu>
References: <05dd01d04831$7f1feb20$7d5fc160$@nict.go.jp> <DBEACD8F-3B2F-4C56-AC83-47EB6F55E8F9@huawei.com>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0e3jexJisPQJi8XH+9tYLGb8mchs cejCcUaLDwsfslgc/b2W1YHVo+XIW1aPJUt+Mnl8ufyZLYA5issmJTUnsyy1SN8ugSvj/PM7 7AXrJSumz/vA3MDYKNLFyMkhIWAisXPCJTYIW0ziwr31QDYXh5DAYiaJA6fbmCCcjYwSf24d h3IOMUlcfPWdFcJpYJTYO20KE0g/i4C2xIMVH1hBbDYBFYmZbzaCzRUR0JHY1bYLbC6zwGdG iUszZzGDJIQFrCX2zJ7JAmJzCthJbNz2gB3E5hVwkFh08wuYLSSQJfHq8RmwBaJAg1bvn8IC USMocXLmEzCbWUBLYvn0bSwTGAVnIUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdE LzezRC81pXQTIyisOSX5dzB+O6h0iFGAg1GJh7eD6UmIEGtiWXFl7iFGSQ4mJVHepO+PQ4T4 kvJTKjMSizPii0pzUosPMUpwMCuJ8CqdAMrxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1O TS1ILYLJynBwKEnwFvMC7REsSk1PrUjLzClBSDNxcIIM5wEa/oUHqIa3uCAxtzgzHSJ/ilFR SpxXD6RZACSRUZoH1wtLO68YxYFeEebdB1LFA0xZcN2vgAYzAQ2e/+cRyOCSRISUVANj2VpJ 36vBZv9OTqxdsGfhogYOybXtTUavV63MbD68+cM6jqtvd76957y/p+Wh0K69t8uKpJc6/1/D Ja6SO3vu2p//qiPFV916x84ordm8XyHhaNDV6M4TuwUv7uj4nKqQcUfsCWuXQKIVg1gabxjP rQ+f1t3VC2bmmyu0ftvb+pVcczaeu5yprMRSnJFoqMVcVJwIAGqPff8WAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/0kiix8e7H2YLwhBomvpIDZ-_iUw>
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>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [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: Wed, 18 Feb 2015 04:01:26 -0000

On Sun, 15 Feb 2015, Tina TSOU wrote:

> 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.

Thank you for the review.

> * 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?)

The use of "proto-" was to indicate that this was a security context which
is not fully established; that is, one for which the establishment process
is still under way.  Since this is confusing, I think I would rather
change it to "security context being established" instead of just removing
the hyphens.

> * Section 3.2, Page 5:
>
> (if not the first iteration of the loop)
>
> Please rephrase as "(if this is not...)"

Okay.

> * 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.

I believe the NTLMSSP mechanism is the main example.  I am not sure what
the best reference to use for it is, though.

> * 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.

Thank you for spotting this (Gen-ART did as well).

> * 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

As above.

> * Section 4.1, page 10
> Additional information can be
>   available in GSS-API Naming Extensions, [RFC6680].
>
> s/can be/is/

I believe that "can be" is appropriate, since the naming extensions from
RFC 6680 are not universally deployed.

> * 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.

I think that the intent is clear from the return code checking where they
are used, but will add a comment above the implementations, "Returns 0 on
success, non-zero on failure."

Thank you,

Ben