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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 10 Mar 2008 17:38:23 +0000

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
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Mar 2008 16:19:02 -0500

> GSS-API mechanisms). This should be specified in the header of the document.

I'm not sure that defining new functions qualifies as updating RFC2743.
Adding new status codes does, at least until the advent of the IANA
registry for GSS namespaces (that I-D will definitly update RFC2743 and
RFC2744, and maybe the Java bindings as well).

> reference to the document which describes what they are.

I'll add one.

> Who controls the parent OID?

http://www.iana.org/assignments/smi-numbers

And it's taken, actually.  I'll update the text to mention that IANA is
responsible for this allocation, and that ..._13_ appears to be
available.

> What is "initial authentication"?

I'll add text.  This is intended for LIPKEY, but this is potentially
controversial in that it's hard define.

Password-based mechanisms (e.g., SCRAM) would have this attribute.

One could argue that PKU2U would have it too when the initiator's
private key lives in a smartcard, but is there anything in the
certificate that allows the acceptor to verify that the key was
generated in an approved token?  And even if there was, what about using
a remote soft token (think SACRED)?  How can the acceptor know that's
not what's happening?

It might be easier to rename this to GSS_C_MA_INIT_PASSWORD and leave
the other issues to other mechanisms.

Thoughts?

> the underlying mechanisms negotiated by SPNEGO must also be returned as

SPNEGO is supposed to output the OID of the mechanism that was
negotiated.  I'll remove this text -- it's completely redundant.

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

Right, thanks.

> Secondly, I think the first function is missing the exclude list of

Will fix.

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

I think "probably" is a sure tip on a clue that the text is informative :)

But sure, it's not useful either.

> doesn't tell that. I suggest adding a sentence pointing to section 3.3 

I will add that.

Thanks!

Nico
--