Subject: [kitten] On mutual auth; security considerations for the BrowserID mech

From: Nico Williams <[email-masked]>
Date: Sun, 6 Jan 2013 13:40:51 -0600

GSS_Init_sec_context() allows the initiator to specify what the
target's name is.  There's a constant, GSS_C_NO_NAME, that should
allow the initiator to indicate it doesn't care what the acceptor's
name is.

One would expect that specifying a target name implies desiring mutual
authentication, and that specifying GSS_C_NO_NAME for the target would
imply indifference to mutual authentication.  Why, then, would we need
a flag for indicating the desire for mutual authentication?

Meanwhile the mutual authentication flag's meaning is a bit confused,
even in RFC2743.  (I'm glossing over details).

Consider Kerberos: is it really the case that the half round trip
version of the AP exchange provides no mutual authentication?
Provided that the peers use per-message tokens afterwards the answer
can only be "no".  (If CB is desired instead of per-msg tokens then we
need key confirmation to confirm the CB to the initiator, but if we
don't we get the security considerations discussed further below.)

And if the application simply does an AP exchange and then uses no
further confidentiality/integrity protection, then how would it help
to have done a full round trip version of AP?  The answer is that if
we assume no active on-path attackers then the full round trip does
help.  But that is not the Internet threat model, so I'm tempted to
ignore this case, or rather, to write it up as a security
consideration.

This isn't to say that the full round trip AP exchange adds no value.
The point is that it doesn't add really "mutuality", and that it'd be
better to have a name for what it does do than to confuse the issue.

I could go on.  I think the bottom line is that we have a slight mess
on our hands.  Meanwhile we need to give guidance to apps that might
want to use mechanisms like Luke's BrowserID.  As well as guidance to
implementors of such mechanisms.

Here's my proposed guidance:

 - The BrowserID mechanism does not provide mutual authentication.  It
can provide key confirmation.

 - The BrowserID mechanism does not support naming acceptors at all.
Luke's implementation pretends to, but it's not really doing much
(remember, the acceptor will pass in GSS_C_NO_CREDENTIAL, or a
credential for GSS_C_NO_NAME, to GSS_Accept_sec_context(), so the
acceptor will tend to agree to any name that the initiator might have
called it by).

   It would be better to say that Luke's mechanism's
GSS_Init_sec_context() MUST fail if target_name != GSS_C_NO_NAME!
This would force the matter of surfacing to the application the need
to indicate that it doesn't need mutual authentication.

 - What we need is for SASL apps to deal with the security
considerations of lacking mutual authentication.  This means that a
SASL API like, say, CyrusSASL's, will need a way for the client
application to indicate that the server's name is irrelevant, or
otherwise that mutual authentication is not required.

 - How should an application decide if it wants mutual auth?  This is
the hard one.  For an IMAP application where the user will begin by
browsing their e-mail we clearly don't need mutual auth: the contents
of the mailstore will impliedly authenticate the server to the user.
For an application that uses TLS and is satisfied with the server's
cert mutual authentication in SASL will also not matter.

  But note that mutual authentication will matter in many apps too:
e.g., an IMAP app that begins by sending e-mail via creating messages
in an outbox, or most LDAP applications.

   To me this implies that the need for mutual authentication is often
something that should be specified by local policy, or even by the
user (though users are mostly not to be trusted to make such a
judgement, or even asked to).

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Mon, 7 Jan 2013 11:00:09 +1100

> to indicate that it doesn't need mutual authentication.

BrowserID requires that the name of the relying party (i.e. the acceptor) be included in the assertion, and that it be verified.

-- Luke

---

From: [email-masked] (Martin Rex)
Date: Tue, 8 Jan 2013 21:20:56 +0100 (CET)

(sorry for picking up these messages in the wrong order).

> allow the initiator to indicate it doesn't care what the acceptor's

Or, more importantly, that the initiator may not _know_ what the
acceptors name is.  The initiator might do the handshake first,
and when the context establishment succeeds, and inquire the
acceptors name and check it against an ACL.

There is also _no_ requirement that a gssapi initiator is also the
communication connection initiator.  It is certainly possible
to have reversed roles at different protocol layers.

> authentication,

I certainly do not expect that.

>
> and that specifying GSS_C_NO_NAME for the target would

The requirement for a target name upfront is a kludge/optimization
for Kerberos to enable 1-token and 2-token context establishment
rather than 3-token.

The existence of mutual flag should make it obvious that performing mutual
authentication and supplying a target_name are independent in GSS-API,
i.e. the presence of the latter will not imply the former.

> version of the AP exchange provides no mutual authentication?

Yup, definitely.

> can only be "no".

It takes more careful app design than "use one per-message token"
to be able to safely infer mutual authentication later on.

>
> (If CB is desired instead of per-msg tokens then we

Traditional gssapi CB includes much weaker information than tls-unique.

> ignore this case, or rather, to write it up as a security

The important thing to understand is that gssapi authentication and
the GSS_C_MUTUAL_FLAG is are security context attributes/properties.

If you take these attributes/properties out of (gssapi) context,
they might loose most if not all of their meaning and value.

rfc4559 is a particularly bad example where a gssapi context establishment
(exchange) is abused as an OTP scheme, and the result is a serious security
problem.  Limiting the Negotiate exchange to the inside of a TLS channel
plus using tls-unique channel bindings for the gssapi context establishment
seems to address the most serious (but not all) problems from such abuse.

> better to have a name for what it does do than to confuse the issue.

It certainly *does* add the "mutual authentication" context attribute
at the GSS-API abstraction level.  Some apps (or apps designers)
might be tempted to interpret this context attribute "out of context",
which would be inappropriate.  What might be lacking in rfc2743 is
a warning sign that apps (designer) ought not make flawed assumptions or
draw incorrect conclusions by taking information out of context.

-Martin