Comments on draft-ietf-kitten-extended-mech-inquiry-03.txt

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 10 March 2008 17:40 UTC

Return-Path: <kitten-bounces@ietf.org>
X-Original-To: ietfarch-kitten-archive@core3.amsl.com
Delivered-To: ietfarch-kitten-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7F73A6B70; Mon, 10 Mar 2008 10:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.746
X-Spam-Level:
X-Spam-Status: No, score=-100.746 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK0KCcdCXsjc; Mon, 10 Mar 2008 10:40:58 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787973A6B2B; Mon, 10 Mar 2008 10:40:58 -0700 (PDT)
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DE63A6ADC for <kitten@core3.amsl.com>; Mon, 10 Mar 2008 10:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaqBMr-bOv3O for <kitten@core3.amsl.com>; Mon, 10 Mar 2008 10:40:53 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D94FD3A67F8 for <kitten@ietf.org>; Mon, 10 Mar 2008 10:40:52 -0700 (PDT)
Received: from [130.129.17.12] (dhcp-110c.ietf71.ietf.org [130.129.17.12]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <R9VyFQAMSSuI@rufus.isode.com>; Mon, 10 Mar 2008 17:38:31 +0000
Message-ID: <47D5720F.8070805@isode.com>
Date: Mon, 10 Mar 2008 17:38:23 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Comments on draft-ietf-kitten-extended-mech-inquiry-03.txt
MIME-Version: 1.0
Cc: kitten@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: kitten-bounces@ietf.org
Errors-To: kitten-bounces@ietf.org

Hi Nico,
Some quick comments on draft-ietf-kitten-extended-mech-inquiry-03.txt.

I think this document updates RFC 2743 (i.e. it defines a new error
code, new functions and section 4 puts additional requirements on new
GSS-API mechanisms). This should be specified in the header of the document.

Section 3.1 references pseudo-mechanisms for the first time. There is no
reference to the document which describes what they are.

> <TBD> [1.3.6.1.5.5.12 appears to be available]

Who controls the parent OID?

> 3.2.  List of Known Mechanism Attributes

[...]

>       | GSS_C_MA_WRAP           |    (20) | wap                     |

typo: wrap

>    | GSS_C_MA_AUTH_INIT_INIT | Indicates support for "initial"         |

What is "initial authentication"?

>    |                         | authentication of initiator to          |
>    |                         | acceptor.                               |

In section 3.3:

>    The attributes of mechanisms negotiated by SPNEGO are not modified by
>    the use of SPNEGO.

I am not sure on what you mean here. Are you saying that attributes of
the underlying mechanisms negotiated by SPNEGO must also be returned as
the SPNEGO attributes?


>3.4.2.  GSS_Inquire_attrs_for_mech()

[...]

>   GSS_Inquire_mech_attrs_for_mech() indicates the set of mechanism

The section title doesn't match the function name. Please fix.


In section 3.4.5:

>       OM_uint32 gss_inquire_mechs_for_mech_attrs(
>          OM_uint32         *minor_status,
>          const gss_OID_set  desired_mech_attrs,
>          gss_OID_set       *mechs);
>
>       OM_uint32 gss_inquire_mech_attrs_for_mech(
>          OM_uint32         *minor_status,
>          const gss_OID      mech,
>          gss_OID_set       *mech_attrs);

Firstly, the name of the function is duplicated once. (I think the first
one is incorrect.)
Secondly, I think the first function is missing the exclude list of
attributes.

> 5.  IANA Considerations
>
>    The namsepace

typo: namespace

>    of programming language symbols with names beginning
>    with GSS_C_MA_* is reserved for allocation by IESG Protocol Action
>    (probably in the specifications of future GSS-API mechanisms).

I suggest you delete text in (), as it is not binding on anyone.

Also, the document creates a new IANA registry. It looks like section 
3.3 provides initial registrations, but the IANA Considerations section 
doesn't tell that. I suggest adding a sentence pointing to section 3.3 
for IANA's sake.
_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten