Subject: [Fwd: Kitten doc reviews]

From: Jeffrey Altman <[email-masked]>
Date: Tue, 07 Nov 2006 09:08:15 -0800

Subject: Kitten doc reviews
From: Derek Atkins <[email-masked]>
To: <[email-masked]>
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.  Also, send vs. receive order
might need to be different.

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.

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:

                                                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

   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"

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.

draft-ietf-kitten-extended-mech-inquiry-02.txt

No Introduction?

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.

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.

General comments:

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

This document has no security considerations.

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant
_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Nov 2006 11:00:24 -0600

On Tue, Nov 07, 2006 at 08:11:56AM -0800, Jeffrey Altman wrote:
> To: [email-masked]
> get transposed, or the ordering matters.

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

>                                           Also, send vs. receive order

I don't understand this comment.

>      Any composite mechanisms indicated through GSS_Indicate_mechs()

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.

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

>       support or not supprot the stackable pseudo-mechanism framework.

*nod*

> "implicitly or implicitly"?  I think it should be "explicitly or implicitly"

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

> 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

Is one always needed?

>    multiple GSS-API mechanisms that may be available.

OK.

> The 'which' portion should be re-written as suggested for the previous

See above.

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