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

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Mon, Mar 10, 2008 at 05:38:23PM +0000, Alexey Melnikov wrote:
> 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.

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

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

I'll add one.

> ><TBD> [1.3.6.1.5.5.12 appears to be available]
> 
> 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.

> >   | GSS_C_MA_AUTH_INIT_INIT | Indicates support for "initial"         |
> 
> 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?

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

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

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

Right, thanks.

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

Will fix.

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

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

But sure, it's not useful either.

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

I will add that.

Thanks!

Nico
-- 
_______________________________________________
Kitten mailing list
Kitten at ietf.org
https://www.ietf.org/mailman/listinfo/kitten