Subject: [kitten] Review comments on draft-williams-kitten-channel-bound-flag-02

From: "Jim Schaad" <[email-masked]>
Date: Fri, 22 Feb 2013 19:48:43 -0800

Nico,

1.  In section 1.1 you say that it would be useless to allow security
context establishment if the acceptor provides context but the initiator
does not, but the converse is not true.  I need to have a greater
explanation that is present about why this would be true.  It seems to me
that the both of them are equally useful or useless.  The decision of which
to enable first would appear to be an arbitrary one and not one with solid
security reasoning.

2.  In section 1.4 - I think that I like this idea and want to bounce a
couple questions off of you.  

Would you expect that one could set mechanism specific security context
values as well as generic ones?  As an example, in ABFAB could this be used
as a method for setting an authorization context SAML statement in the
authenticator that the mechanism could later use in an appropriate manner.
Since this would be tagged as being mechanism specific it would be ignored
by any other mechanism.

Would you expect that one could query about context values used that are not
setup as return flags after authentication has completed?  Thus one could
ask if this security context value was used or not when establishing
security context?

3.  In section 1.4 - are the two required inputs supposed to be a security
context handle and a credential handle?  Currently it says a context handle
and an input context token.  This may be a deficiency on my part for
understanding.  It may also be that the word context should be removed and
it should just be 'an input token'

4.  In section 2 s/for setting a) creating/for a) creating/
    Same sentence.  There should be an and between the a)... and b)... as
the currently existing and is two sub-clauses in b)

5.  In section 2.2 - There is a problem with the text "Return flags
understood by the caller" in that this is an input but the text is written
as if it were an output.  Suggest "Specify return flags understood by the
caller"

6.  In section 2.2 - does it make more sense to do an override or to do an
OR on the request flags?  It seems odd that one would ignore them based on
passing in a value of 0, what if that is what they really want?  Without the
ability to query for them from the context it seems odd to potentially
ignore flags set elsewhere - and thus introduce a bug - while doing the or
(along with a query) might be more predictable.

7.  In section 3 - Should there be some type of error if an application
shall have a) not provided channel bindings to GSS_Init_sec_context() or
GSS_Accept_sec_context() and b) indicated support for the
ret-channel-bound-flag flag?  This would indicate to me that some type of
programming error occurred as the return should never have the flag set.

8.  In section 4 - I think that it is worthwhile documenting that if an
initiator passes in a channel binding and either you are in the current
state or the mechanism has not implemented this document then there is a
potential secrurity problem as the channel binding will not have occurred
and the initiator might assume that it had.  

Also, If the selected mechanism does not implemented this feature then it
will always appear as channel binding did not occur even if it did as the
mechanism would not return the appropriate flag.

Jim

---

From: Luke Howard <[email-masked]>
Date: Sat, 23 Feb 2013 15:43:52 +1100

> authenticator that the mechanism could later use in an appropriate manner.

You can do something similar today by calling GSS_Set_name_attribute() on a name passed to GSS_Acquire_cred(). I implemented something like this a while ago, so that you could pass a SAML assertion in when doing protocol transition (see http://k5wiki.kerberos.org/wiki/Projects/SAMLInKerberos).

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 Feb 2013 23:18:41 -0600

> context establishment if the acceptor provides context but the initiator

s/context/CB/ ?  I'll assume so.

> to enable first would appear to be an arbitrary one and not one with solid

Well, no, it'd be useless if the acceptor provides CB, the initiator
doesn't, and the acceptor doesn't find out.

The way RFC2743 specifies the handling of CB callers only get to find
out that both peers provided CB is when the CB did not match.  There's
no way for them to find out that both peers used CB and that the CB
matched -- this is terrible!

Fortunately the way implementations of RFC1964/4121 work acceptors
fail when the acceptor provides CB and the initiator doesn't.  But
this creates problems for migration from not using CB to using CB: the
acceptor needs to know early on if the initiator will be using CB, and
in some application protocols that's not easy to do.

The way to fix this, in the GSS tradition, is to have had a ret_flag
to indicate whether both parties used CB and the CB matched.  But we
can't just add this ret_flag and otherwise revert to RFC2743 behavior,
not safely.  We need the acceptor mechanisms to know whether the app
understands the new ret_flag.

> Since this would be tagged as being mechanism specific it would be ignored

Sure.  Some such extensions strike me as more closely associated with
credential handles, and some as more closely associated with security
contexts.  Therefore I think there's still room to standardize a
GSS_Set_cred_option().

> ask if this security context value was used or not when establishing

Yes, but the goal here is to discover what results at the end of
successful security context establishment.

Ah, I now understand your comment about getter functions.  Yes,
anything that can result beyond what the application provided as
inputs, and particularly those inputs that are provided by the other
peer, should be made available via an inquiry function like the
existing GSS_Inquire_context().

> it should just be 'an input token'

Credential handles can be defaulted, so they're not required as such.
But context handles and input (and output) tokens are a sine qua non
of GSS security context establishment.  All other inputs to
GSS_Init/Accept_sec_context() take default values, even the mech_type
and target_name arguments -- all of them but context handle and input
token.

> the currently existing and is two sub-clauses in b)

Will be fixed.

> as if it were an output.  Suggest "Specify return flags understood by the

You're right, I intended "return flags" to be read as a noun phrase --
i.e., "return" is not a verb here.  I'll fic it as "The set of return
flags understood by the caller".

> (along with a query) might be more predictable.

Ah, here I'm looking forward to the simplified API I-D and so we end
up with a case where the caller can set req_flags with this function
*and* in GSS_Init_sec_context() (i.e., not using the rest of the
simplified API).  I needed to say something about this redundancy.  I
figured that allowing an empty req flag set in the call to
GSS_Init_sec_context() to mean "use the req_flags specified in the
GSS_Set_context_flags() call" would be useful in that it would allow
call sites for GSS_Init_sec_context() to get lexically shorter.

Perhaps I could re-phrase this better?

> programming error occurred as the return should never have the flag set.

Whether there are CB data may vary contextually, but whether the app
understands the new flag should not.  Since it's useful to be able to
use a constant set of req_flags I think it's best to not consider this
case an error.

> and the initiator might assume that it had.

The Kerberos mechanism has no way for an acceptor to indicate CB
success to the initiator.  Is this a security problem?  Back when we
were designing RFC4121 I argued that it was, but Sam made a better
argument that it wasn't.  I still have misgivings about that, but I'll
let Sam explain his argument.

In any case, what I'll do is add a note (in section 2.3) that "some
mechanisms have no way for the acceptor to signal CB success to the
initiator, in which case GSS_Init_sec_context() MUST NOT output the
ret_channel_bound_flag".

> mechanism would not return the appropriate flag.

True, but here we fall back on the as-currently-implemented behavior
rather than the RFC2743 behavior, and that happens to work well
enough.  Migration is complicated, but then you just implement this
and upgrade :)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 Feb 2013 23:22:52 -0600

> You can do something similar today by calling GSS_Set_name_attribute() on a name passed to GSS_Acquire_cred(). I implemented something like this a while ago, so that you could pass a SAML assertion…

Right.

Is some extension best represented as a name attribute, credential
option, or security context option?  It's a somewhat subjective call.

Authorization data is seen as attributes of the NAME of the peer (and
the local principal too), given the API we have, and this seems
reasonable to me.

I would say that things like "cryptographic profiles" should be
attributes of credentials, but in some cases (e.g., when public keys
are principals' names) they could also be attributes of names.

Whether the app support the new ret_channel_bound_flag is... something
I'd associate with a library context handle, if the GSS-API had one,
but since it lacks it the only reasonable places to set it are: cred
handles, or "empty" (primitive?) security context handles.

Nico
--