Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec

[Jeffrey Hutzelman <[e-mail]>]

On Mon, 2014-03-10 at 20:27 +0000, Cantor, Scott wrote:

> [snip of TLS text]
> >This text places normative requirements on applications using this
> >mechanism.
> >That's not reasonable because applications may have no knowledge of this
> >mechanism.
> >What happens if these checks are not performed?
> 
> That text came from some iteration of the original wording borrowed from
> the SAML/OpenID mechanisms, and was basically adapted. Isn't that same
> text, or a variant, essentially what Simon is adding to GS2?
> 
> All this is saying is that if the mechanism doesn't signal mutual
> authentication to the initiator, then obviously it's up to the
> application. What else can you do?


That text was used in the SAML and OpenID mechanisms to attempt to
handwave around the need for a mechanism that _claims_ to have done
mutual authentication to actually _do_ mutual authentication.

Basically, what those mechanisms did was say "we're going to assert
mutual_state, but we don't actually do anything to verify the acceptor's
identity, so the application had better have done that even though we
claim to have done it".  They did that because GS2 as written fails on
mechs that don't assert mutual_state.

That's not an acceptable way for a GSS-API mechanism to behave.  It's
essentially trying to reach up through the abstraction boundary and
impose new requirements on the application depending on what mechanism
is used, and the API doesn't allow for that.



It's not necessary for a mechanism to say "if we didn't assert
mutual_state, then we didn't do mutual auth, and if the app cares, then
it had better do something about it".  That is a property of the
abstraction and is true for _every_ mechanism.



For the SAML and OpenID mechanisms, if the application does not perform
the checks in question, then badness ensues, because the application
sees mutual_state and assumes the acceptor has been authenticated, when
it really has not.  If _this_ mechanism only asserts mutual_state when
it has actually authenticated the acceptor (if ever), _and_ it doesn't
depend for its security on the application having already verified the
server's identity (as, for example, SASL PLAIN does), then there is no
problem.




> >Section 5.1 seems applicable to SASL as well.
> 
> Similar question as above; is there normative machinery that can be used
> in SASL to regulate and signal it? I didn't think so.

SASL unfortunately doesn't have a well-defined abstraction.  Not all
SASL mechanisms provide mutual authentication (for example, PLAIN does
not), and the base spec doesn't really talk about it.  Over time, I
think the community mostly accepted that the usual case was to run a
SASL application over TLS, relying on TLS to authenticate the server and
using SASL to authenticate the client.

However, we have introduced the notion of channel bindings.  It's only
safe for an application to rely on CB if mutual authentication has
happened.  This is why GS2 required mutual auth, and why a new version
of GS2 which relaxes this requirement must be careful to specify that
-PLUS mechanisms must not be advertised unless mutual auth is possible,
and must not succeed if mutual auth does not happen.

So no, in the abstract, there's not really any machinery in SASL to
signal whether mutual auth happened, except for the implied indication
when channel bindings are in use.



> >Section 5.3.  I note that this is the first time I'm aware of where
> >RFC 3961 enctypes' names are used in a protocol.  I'd like explicit
> >review of this from the Kerberos community.  Everything we have so far
> >uses numbers.
> 
> Ok, will await decision. I don't care for numbers in a text-based
> protocol, but if the strings aren't formalized, that's appropriate. I
> think I did look at the registry though and came to the conclusion they
> were.

The names of enctypes have never been protocol constants.  There have
frequently been inconsistencies in the spelling and punctuation of these
names.  There has also been confusion at various points as to what
particular names meant.  There is no formal definition of the syntax of
an enctype name, because they are never used in a case where that
matters.  Also, I think it is unwise to expect libraries which implement
RFC3961 to provide interfaces to look up enctypes by name, and
impractical and counterproductive for a mechanism implementation to
maintain a private table.

Please use the numbers; that's the namespace we've actually
standardized.



> >Section 5.4: RFc 4121 has multiple keys it can use: the session key, the
> >subsession key, and the acceptor subsession key.
> >The text in 5.4 is insufficiently detailed for interoperability.
> 
> I'd need feedback on that, I don't have the background (and it was more or
> less copied, again, from some other work).

A typical behavior would be to prefer an acceptor subkey if one was
sent, followed by an initiator subkey if one was sent, followed by the
Kerberos ticket session key.  However, this can get a bit complicated,
because an initiator does not know whether the acceptor sent a subkey
until it processes the acceptor's AP_REP.  That means you either need to
avoid the initiator having to choose until it has seen that message, or
having some way to know which key to use when.  Doing the first is not
bad, but can result in extra round trips depending on what you're doing.


-- Jeff