Subject: [kitten] WGLC of draft-ietf-kitten-gss-loop-01

From: ⌘ Matt Miller <[email-masked]>
Date: Fri, 21 Nov 2014 08:46:04 -0700

This message begins the second Working Group Last Call (WGLC) of
"Structure of the GSS Negotiation Loop" <
draft-ietf-kitten-gss-loop-01 >.  WGLC will end in two weeks, on
December 5.  The draft is available at:

http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-01

Because the changes between -00 and -01 are substantial, the Chairs
decided to issue a second last call.

Please review the document and send comments to the Working Group
mailing list < kitten at itef.org > or the co-chairs < kitten-chairs
at tools.ietf.org > before the end of the WGLC.  Any and all comments
on the document are sought in order to access the strength of
consensus.  Even if you have read and commented on this or earlier
versions of the draft, please feel free to comment again.  This is
particularly important if you found issues with the previous version.

As a reminder, comments can be anything from "this looks fine" to
"this is a horrible idea"; they can include suggestions for minor
editorial corrections to significant editorial changes.

- - Your Kitten Chairs

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 15:09:44 -0600

> decided to issue a second last call.

Comments:

 - Section 2, nit: this should be a list with bullets.

 - Section 2, think there's no need to frame initial security context
   tokens differently than others, except asynchronous (error, deletion)
   context tokens, but the first and second list items give this
   impression...

   The node producing the error token doesn't know whether the peer
   thinks the context is fully established, therefore the second item in
   the list is... not workable.

   And whether an application needs to frame the initial security
   context token differently from others is really dependent on the
   application protocol.  E.g., the initiator might need to say "I'm
   starting the GSS login procedure", but for some protocols, such as
   'knc' the client just starts sending context tokens from the start,
   with no special framing beyond the token length, so there's no
   generic need.

   Proposed fix:

OLD:
      A way to frame and identify the initial context negotiation tokens
      in the loop.

      A way to frame and identify subsequent context-level tokens (e.g.,
      error tokens) after a GSS_S_COMPLETE return.

NEW:
      A way to frame and identify security context negotiation tokens in
      the loop.

      Error tokens should generally also get special framing, as the
      recipient may have no other way to distinguish unexpected error
      context tokens from per-message tokens.

 - Section 2, the application protocol may need to provide something
   like a "username" to authorize access to.  (E.g., SSHv2 does.)

OLD:
      The application (not the protocol) should provide for
      authorization checks in the acceptor.  The GSS-API authenticates
      the initiator, but does not make any claim about whether the
      initiator is authorized for any given operation.  In particular,
      the initiator may be from a different portion of a federated
      identity scheme.

NEW:
      The GSS-API provides for authentication of mechanism-specific
      principals (which have names).  Applications are responsible for
      authorization of authenticated peer principal names.

 - Section 4.2, last para, should be "in particular" "mutual
   authentication" and "replay protection" "are not available"...  And
   even "other services".  (E.g., if/when we add a GSS_C_PFS_FLAG, that
   may not be available at the same time as early PROT_READY.)

 - Section 4.3, second para, first sentence, nit: s/, but/; /

 - Section 4.3 and section 7, add reference to erratum 4151 (which we
   should revise with text like what I proposed today and do a consensus
   call on to get it or acceptable alternatives accepted as a valid
   erratum).

 - Section 6, Add text to the effect that "all security considerations
   from RFCs 2743 and 2744 apply".

 - Section 6, last para, the last two sentences should probably be
   swapped, or else in the next to last sentence s/existing
   software/implementations protocols intended to produce a secure octet
   stream/.

And that's it for me.  Most of the above are nits, really.  With those
nits fixed this I-D will be ready to be published.

Thanks for seeing this through!

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 25 Nov 2014 21:36:22 -0500 (EST)

> > decided to issue a second last call.

Thanks for the review.

>  - Section 2, nit: this should be a list with bullets.

Sure; I think that was my intention, but my xmlrfc was rusty.

>    context tokens, but the first and second list items give this

Sure, I can see how that is misleading.  I think I can just combine them
into a single bullet point,

% A way to frame and identify all context-level tokens, whether in the
% initial context negotiation loop or subsequent traffic (e.g., error or
% deletion tokens).

>    the list is... not workable.

Well, in many cases is could; certain mechanisms only use a given number
of tokens.  But yes, in the general case the node can't know the peer's
state, especially after your extra round trips stuff is done.

>       context tokens from per-message tokens.

Hmm, I like your version better than mine (above).

>    like a "username" to authorize access to.  (E.g., SSHv2 does.)

(as the last item)

% To facilitate those authorization checks, the application protocol may
% need to provide a name of a resource to be accessed, e.g., as the SSHv2
% protocol passes a username.

>       authorization of authenticated peer principal names.

I don't think I like this text as-is, since it starts off with a generic
statement about the GSS-API, not an application protocol requirement.

How about turning it around, as

% Applications are responsible for authorization of the authenticated peer
% principal names which are supplied by the GSS-API.  Such names are
% mechanism-specific, and may come from a different portion of a federated
% identity scheme.  Application protocols may need to supply additional
% information to support the authorization of access to a given resource,
% such as the SSHv2 "username" parameter.

>    may not be available at the same time as early PROT_READY.)

Sure, that was one of the bits I was least confident about in the new
content.

"""In particular, mutual authentication, replay protection, and other
services (if requested) are services which will be active when
GSS_S_COMPLETE is returned, but which are not necessarily active
before the security context is fully established."""

I went back and looked at RFC 2743 to get the "will be active" wording
(section 2.2.1, buried in the middle in the paragraph starting with "Not
all of the optionally-requestable features".

>  - Section 4.3, second para, first sentence, nit: s/, but/; /

I think this is the first paragraph, third sentence?
I am fine with the change.

>    call on to get it or acceptable alternatives accepted as a valid

I guess this will go in the third paragraph of section 4.3
("GSS_Process_context_token() may indicate an error in its major_status
field [...]").  I confess I'll need to look up how to cite a specific
erratum, but agree it should be there.

>    from RFCs 2743 and 2744 apply".

Sure.  I guess we should mention the security considerations of RFC 5653
as well, thought there does not seem to be anything especially relevant
there.

>    software/implementations protocols intended to produce a secure octet

I'm happy to swap the sentences.

> nits fixed this I-D will be ready to be published.

Thanks!

-Ben

---

From: Nico Williams <[email-masked]>
Date: Tue, 25 Nov 2014 21:09:20 -0600

On Tue, Nov 25, 2014 at 09:36:22PM -0500, Benjamin Kaduk wrote:
> [...]

Excellent.  I like all your suggestions.

> I think this is the first paragraph, third sentence?

Oops, yes.

> as well, thought there does not seem to be anything especially relevant

RFC2744's sec cons apply because 2744 is not just the C bindings, but
actually fills in some gaps in 2743 (e.g., channel bindings, though
badly), and its security considerations text is generic.

> Thanks!

Thank you!  This will be a very helpful RFC to have to point people to.

Nico
--