Re: [Fwd: Kitten doc reviews]

[Nicolas Williams <[e-mail]>]

On Tue, Nov 07, 2006 at 08:11:56AM -0800, Jeffrey Altman wrote:
> From: Derek Atkins <[e-mail]>
> To: [e-mail]
> Subject: Kitten doc reviews
> Date: Tue, 07 Nov 2006 11:01:04 -0500
> 
> Here are my reviews for you..
> 
> -derek
> 
> draft-ietf-kitten-stackable-pseudo-mechs-02.txt
> 
> Abstract:
> 
>    This document defines and formalizes the concept of stackable pseudo-
>    mechanisms, and associated concept of composite mechanisms, for the
>    Generic Security Service Application Programming Interface (GSS-API),
>    as well as several utility functions.
> 
> This first sentence is awkward.  I think you should remove the first
> comma and add a "the", so it reads:   ... stackable pseudo-mechanisms and
> the associated concept ...
> 
> 
> 3. Mechanism Composition Issues
> 
>  What about mechanism ordering?  Security Modules cannot necessarily
> get transposed, or the ordering matters.

Correct.  This is why composition rules matter, see section 4.2.

>                                           Also, send vs. receive order
> might need to be different.

I don't understand this comment.

> 
> 4.4.  Compatibility with the Basic GSS-APIv2u1 Interfaces
> 
>    o  Which composite mechanisms, if any, are indicated through
>       GSS_Indicate_mechs() SHOULD be configurable.
> 
> This reads awkwardly.  A better sentence would read:
> 
>      Any composite mechanisms indicated through GSS_Indicate_mechs()
>      SHOULD be configurable.

Your version is ambiguous.  What should be configurable?  The
mechanisms?  Or the set of mechanisms?  :)

How about:

    o  The set of composite mechanisms indicated by GSS_Indicate_mechs()
       SHOULD be configurable.


> 5.1.  New GSS-API Function Interfaces
> 
> This section looks like it uses the exact same text as 4.4, but
> just in a paragraph instead of bullet-items.  What's the point
> of that?  It also has the same syntactic issue as 4.4:

Good point.  I think most of section 5.1 can be replaced with a
reference to section 4.4.

>                                                 GSS_Indicate_mechs()
>    MAY indicate support for some, all or none of the available composite
>    mechanisms; which composite mechanisms, if any, are indicated through
>    GSS_Indicate_mechs() SHOULD be configurable.  
> 
> should probably get re-written in the same way as 4.4:
> 
>   ...  any composite mechanisms indidicated through GSS_Indicate_mechs()
>    SHOULD be configurable.
> 
> 
> 5.1.4.  GSS_Indicate_negotiable_mechs()
> 
> 
>    o  peer_type_known BOOLEAN, -- indicates whether the peer is known to
>       support or not supprot the stackable pseudo-mechanism framework.
> 
> supprot -> support

*nod*

> 
>    GSS_Inquire_cred()), but composite mechanisms will be included either
>    implicitly or implicitly as per the following rules:
> 
> "implicitly or implicitly"?  I think it should be "explicitly or implicitly"

Come to think of it, those three words should be removed altogether.

> General Comments...
> 
> This document talks about "rules for mechanism composition" but
> nowhere does it discuss a way to encode these rules.  How do I express
> these rules?  The draft mentions a means to upgrade these rules, but
> not where these rules need to get stored.

There is no need to encode these rules.

The intention is that SPIs between framework and plug-in mechanisms
should be used so that mechanisms evaluate proposed compositions
themselves.

Since existing pluggable GSS framework implementations tend to have SPIs
derived from the GSS-API itself, then, the where the extended mechanism
inquiry APIs are available stackable mechanisms would be expect to use
them to discover the attributes of mechanisms stacked below and evaluate
whether a composition is valid.

E.g., the framework would call a stackable mechanism's
GSS_Inquire_attrs_for_mech() function on a composite mechanism's OID --
the result would be GSS_S_BAD_MECH for bad compositions, or
GSS_S_COMPLETE and a set of mechanism attributes for good compositions.

Where the extended mechanism iquiry APIs are not available the set of
valid composite mechanisms has to be constructed by hand as there would
then be no way to dynamically evaluate proposed compositions.


> draft-ietf-kitten-extended-mech-inquiry-02.txt
> 
> 
> No Introduction?

Is one always needed?

> 
> 3.  New GSS-API Interfaces
> 
> The opening sentence is awkwardly composed.  I recommend changing it to:
> 
>    Today GSS-API applications face the problem of how to select from
>    multiple GSS-API mechanisms that may be available.

OK.

> 
> 3.5.  New GSS-API Function Interfaces
> 
> This section uses similar text to the other draft.  In particular:
> 
>    support for any stackable pseduo-mechanisms.  GSS_Indicate_mechs()
>    MAY indicate support for some, all or none of the available composite
>    mechanisms; which composite mechanisms, if any, are indicated through
>    GSS_Indicate_mechs() SHOULD be configurable.  GSS_Acquire_cred() and
> 
> The 'which' portion should be re-written as suggested for the previous
> draft.

See above.

> 
> 
> General comments:
> 
> Again, the document mentions the composition rules but doesn't
> specify them or how to use them.

It cannot and so won't specify them.  Stackable mechanisms must specify
their own composition rules.  No formal composition rule language is
needed because the API/SPI allows for stackable mechanisms to implement
their rules as code.  A formal composition rule language could be worked
out, but it does not seem necessary.  We describe lots of normative
things in English now throughout IETF documents, and there is a real
tension between too much use of formal specification languages and too
little (see KRB WG threads on use of advanced ASN.1 techniques to
increase formalism).

> This document has no security considerations.

Good point.  I'll write one up.

Nico
-- 

_______________________________________________
Kitten mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/kitten