Subject: [Ietf-krb-wg] rcache avoidance, take 3

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 11:12:53 -0600

[This post is intentionally terse.  I assume reader familiarity with
this subject.]

We have two kinds of GSS/Kerberos and raw Kerberos applications that
we need to worry about w.r.t. rcaches: those that need an rcache, and
those that don't.  For the latter we need to make sure that their
AP-REQs can't be played to acceptors/servers for applications that do
need an rcache -a critical requirement-, which means that for all
designs I describe below I assume that all Kerberos implementations on
the server support rcache avoidance.  This critical requirement I will call the
"non-mixing requirement".

Whether to use an rcache will often be context-specific.  For example,
forGS2 the question will depend on whether the Kerberos mechanism is
beingused and whether channel binding to a secure channel that
providesconfidentiality protection is being used.  The same thing goes
forHTTP/Negotiate.

Here I will assume throughout that all Kerberos acceptor/server mechanism
implementations on a given host will support rcache avoidance, at least on
a per-service name basis.  I.e., configuration will be required to enable
rcache avoidance, and for now it must be disabled by default.

I've come to conclude that we need the initiator's/client's help and
the acceptor's/server's help to decide when it's OK to avoid the
rcache.  For the GSS-API we could make a minimally invasive extension
based entirely on req_flags/ret_flags, but that would require that
rcache avoidance not be enabled until all GSS applications (not just
GSS implementations) on a host have been updated.  A GSS extension
based entirely on req_flags/ret_flags would be unacceptably insecure
by default, therefore I propose the use of a credential option
instead.

In the interest of generality I propose two cred options by which to
describe what's happening in the application protocol, as opposed to
one cred option by which to say "use an rcache" or "don't use an
rcache".  The two cred options would indicate whether the security
context is to be channel bound to a secure channel providing
confidentiality protection, and/or whether per-message tokens will be
used and if so that nothing of consequence will be done or sent by the
acceptor until after receiving a per-message token from the initiator.

For the GSS-API then the additions are just two cred option OIDs (TBD)
and symbols for them:

 - GSS_C_CO_BOUND_TO_CONF_SEC_CHANNEL
 - GSS_C_CO_IMPLIED_EXTRA_LEG

The initiator and acceptor applications would use the above cred
options to signal that the given security context is channel bound to
a secure channel and/or to indicate that pre-message tokens will be
used and that nothing of consequence will be sent by the acceptor
until at least one per-message token has been sent by the initiator.
Instead of GSS_C_NO_CREDENTIAL the application would acquire a
credential handle for GSS_C_NO_NAME then set the cred options.  The
two options would have boolean values, and could be turned on or off.

When the initiator and acceptor agree that an rcache is not needed (by
setting either of these options to true), then the mechanism should
not use an rcache.  Other GSS acceptors or Kerberos services running
on the same server MUST reject any AP-REQs with these options set when
the acceptor/server application fails to indicate that an rcache is
not needed (see assumptions above), thus meeting the critical
non-mixing requirement.

Raw Kerberos APIs would look similar to the credential option for GSS
and need not be discussed here in any detail.

In the GSS Kerberos mechanism and in raw Kerberos we would use
non-critical authorization-data (i.e., wrapped in AD-IF-RELEVANT) to
signal these two options.  The authorization-data elements would bear
no data, just the element type, and they would be named something
like:

 - AD-BOUND-TO-CONF-SEC-CHANNEL
 - AD-IMPLIED-EXTRA-LEG

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Nov 2011 14:47:40 -0500

On Thu, 2011-11-17 at 11:12 -0600, Nico Williams wrote:
> GSS implementations) on a host have been updated.

Why?  Remember that while there currently is a one-to-one correspondence
between the bits representing these flags as they appear in the RFC2744
C language bindings and as they appear on the wire in the Kerberos
mechanism, there is no requirement that this continue to be the case.
We are free to allocate flag bits on the wire in the Kerberos mechanism
to support rcache avoidance negotiation without exposing those bits to
the GSS-API (in any language).  Of course, we might want to avoid also
using the same bits for future unrelated flags in the C bindings, in
order to make life a bit easier for implementators.

> not needed (see assumptions above), thus meeting the critical

Hrm.  I'd be happier if this didn't require a non-critical extension to
be treated as critical by other acceptors.  The "everything must be
upgraded" requirement is tricky because it's hard for administrators to
tell if they've met it, and it's impossible for an application itself to
know the answer.

>  - AD-BOUND-TO-CONF-SEC-CHANNEL

So, why make these non-critical?  It sounds like they actually should be
critical, which guarantees that acceptors which have _not_ been upgraded
will always reject an AP-REQ which contains them, which is what we want.

-- Jeff

---

From: Greg Hudson <[email-masked]>
Date: Thu, 17 Nov 2011 15:16:49 -0500

> will always reject an AP-REQ which contains them, which is what we want.

"Guarantees" is overly strong here.  Implementations don't tend to
respect the RFC 4120 requirement of rejecting authenticators containing
unknown authorization data.  That said, I'm not sure what the point of
the AD-IF-RELEVANT wrapper is.

I think there's a more significant issue, though.  Once we've added
support to GSSAPI and krb5 implementations and client and server apps,
how do new clients interoperate with old servers?

The client doesn't have any meaningful input into whether an rcache is
required.  The server has all of the information to know that.  We would
like the client to produce an authenticator which won't be accepted by
an rcache-requiring server, but only if we know that the intended server
will accept it.  That's fodder for negotiation, not a client-side
application flag.  (Unfortunately, the only vehicles I can think of for
negotiation are a ticket flag or a new mech OID, neither of which are
very attractive.)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 14:20:19 -0600

On Thu, Nov 17, 2011 at 1:47 PM, Jeffrey Hutzelman <[email-masked]> wrote:
> [...]

Say we use only req_flags for this.  So the initiator sets one of
these flags, and the mechanism on the acceptor side honors it and
doesn't use the rcache.  But the acceptor application has to check the
ret_flags and reject authentication if the flags are inappropriately
present -- if it doesn't then a replay attack is possible.  Assuming
the mechanism implementations on a server are updated is one thing;
assuming all the apps on it are too is a bit too much for me.

> tell if they've met it, and it's impossible for an application itself to

We can't use a critical extension.  First because we'd have to
negotiate its use out of band, and that's not really an option.
Second, do all major Kerberos implementations treat critical
authz-data as critical?  I doubt it.

I don't think it's always hard for admins to know whether it's safe to
enable this, but that's why this option must default to disabled.

If we had always had an option for multiple round-trips, if we'd
always had critical authz-data, then we could have used that here.  As
it is we can't.  An approximation is the best I can see us achieving,
though we can also give up on rcache avoidance.

> will always reject an AP-REQ which contains them, which is what we want.

Ignoring the question of whether all mechanism implementations are
upgraded on the server, making this a non-critical option is exactly
the right thing to do.  It's only the possibility of legacy mechanism
implementations that should make you want this to be a critical
extension, and I do believe the best thing to do about that is to
disable this feature by default.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Nov 2011 16:49:05 -0500

> assuming all the apps on it are too is a bit too much for me.

OK, I can see how that applies to raw Kerberos, since only the app knows
enough to know whether it is safe to avoid the rcache.  But in the case
of the Kerberos GSS-API mechanism, this shouldn't actually be an
application-specific question, should it?  The application shouldn't
know anything about Kerberos, let alone whether it needs a replay cache.

> negotiate its use out of band, and that's not really an option.

Yeah, you're right.

> authz-data as critical?  I doubt it.

Greg pointed this out.  That's unfortunate, though, because it basically
means we can never have critical authz-data.

> enable this, but that's why this option must default to disabled.

It's hard.  Most admins don't understand the workings of everything on
their system.  They won't understand how to tell whether a particular
application is safe, and for services like "host", they may not even
know what applications are installed that share that principal.  Even if
they do, they won't know whether all of the applications sharing a
service are using Kerberos and GSS libraries that are new enough.  Even
supposedly single-application service often have multiple components
that share a principal.

And, turning this on when you shouldn't doesn't make services break; it
makes services become less secure without breaking.  That's exactly the
sort of knob you don't want to require admins to twist.  If we do this,
in a couple of years you'll be able to find "advice" on a dozen mailing
lists to blindly flip this switch to make your {imap,http,whatever}
server "faster", with no discussion of the consequences, which won't
even be understood by the person giving the "advice".

> the right thing to do.

Yeah, you've convinced me it needs to be for negotiation to work.

Unfortunately, that means you haven't gained anything.

I don't see why the client needs to be involved here at all.  The app
server knows whether the protocol supports rcache avoidance or not.  The
only reason to involve the client is to meet the non-mixing requirement,
by insuring that an application which cannot support rcache avoidance
does not accept an AP-REQ intended for an application which may be doing
rcache avoidance.  But if you can't include non-upgraded applications in
that set, you lose anyway.

I'm beginning to think the right answer is to always use different
principal names for rcache-avoiding and rcache-requiring services.

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 15:52:34 -0600

I would like to remind you all that we have:

 - sites that disable the rcache or use MEMORY rcache implementations
to the same effect

   If we do nothing to help them, they'll continue doing this.  Yes,
we can implement fast rcaches (I've done it, so I know it's possible,
but then there's:

 - sites that use clustering but without any sort of distributed rcache

   I don't know of any distributed rcache implementations, much less
*fast* distributed rcache implementations.  (I know of at least one
fast local rcache implementation.)  Barring a sudden rush of interest
in developing such a thing, only rcache avoidance would really work
for clusters.

Nico

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 16:05:59 -0600

> know anything about Kerberos, let alone whether it needs a replay cache.

Consider SASL/GS2 with the Kerberos mechanism.  The only way it's safe
to not rcache in that case is if the application is doing channel
binding to a secure channel that provides confidentiality protection.

There's nothing about GSS that makes it fundamentally not need an
rcache.  The situation is the same as for raw Kerberos.

> ...

Admins often already have options for disabling the rcache.  And they
have no secure rcache for clusters option.

You effectively assert that this proposed option makes things worse,
but have you considered the options that users have now (or don't have
now, as in the case of clusters)?  If so, please explain how this
option is worse than those.

> Unfortunately, that means you haven't gained anything.

I don't agree.  We gain a solution that works for clusters.

> only reason to involve the client is to meet the non-mixing requirement,

So you do see why the client needs to be involved.

But I also think that adding context-descriptive elements is a good
thing -- I can't see how they cause harm, even if you think their
benefit in this case is marginal.

> that set, you lose anyway.

Given the situation in the field, I disagree.

> principal names for rcache-avoiding and rcache-requiring services.

That would be too disruptive.  You're letting perfection be the enemy
of good enough, thus risking a result that is worse than good enough
would be.  Moreover, over time my "good enough" becomes perfect.

Nico

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 16:54:27 -0600

[resend]

> how do new clients interoperate with old servers?

New clients/initiators set the authz-data (in AD-IF-RELEVANT); old
servers ignore it (and use the rcache).  New servers shazring the same
credentials as still-in-use old servers disable this feature and
therefore ignore the authz-data and use the rcache.  Nothing changes.

> required.  The server has all of the information to know that.  We would

The initiator/client knows some contextual information and asserts it
(non-critically).  The acceptor/server application does the same.  The
acceptor mechanism decides if that means that the rcache is to not be
used.

This is why I propose *descriptive* options, not prescriptive ones.

> negotiation are a ticket flag or a new mech OID, neither of which are

The only reason to negotiate anything here is old Kerberos
implementations mixed with new ones and wanting to still avoid the
rcache.  We don't have negotiation in the Kerberos AP exchange, nor in
the Kerberos GSS mechanism.  Therefore we can only say "don't do
that".

Nico

---

From: Greg Hudson <[email-masked]>
Date: Thu, 17 Nov 2011 17:55:09 -0500

> therefore ignore the authz-data and use the rcache.  Nothing changes.
Let me see if I understand the proposal correctly.  For the sake of
argument, assume that the Kerberized telnet protocol needs a replay
cache but the gssapi-with-mic ssh protocol does not.  Then:

(1) New ssh + new client lib + new server lib + new sshd + configured-on
--> success without rcache

(1a) #1 except old ssh and/or old client lib --> success with rcache
(authz data isn't sent, authenticator might be used against telnet)
(1b) #1 except old server lib --> success with rcache (authz data isn't
recognized)
(1c) #1 except configured-off --> success with rcache (authz data isn't
honored)
(1d) #1 except old sshd and configured-off --> success with rcache
(authz data isn't honored)
(1e) #1 except old sshd --> failure (admin wasn't supposed to configure
this on until sshd is updated)

(2) New or old telnet + new or old client lib + new server lib + new
telnetd + configured-on --> success with rcache (authz data isn't sent)

(2a) #2 except buggy/rogue telnet client setting flags --> failure
(authz data sent, appears as if a replayed ssh authenticator)

The requirements of this proposal are:

* GSS implementors must implement it (obviously)

* Developers must identify when the protocol variation doesn't require
an rcache and set flags on the client and server as appropriate.
  - Clients inappropriately setting the flags will get #2a auth failures
against updated and servers on configured-on hosts.
  - Clients inappropriately failing to set the flags will get #1a
successes with rcache use (possible DOS issue, but no worse than today).
  - Servers inappropriately setting the flags will mostly behave as in
#2, but become vulnerable to replays in combination with buggy clients
used by legitimate users, on configured-on hosts (however, buggy clients
should be rare since they won't work against correct servers on
configured-on hosts).
  - Servers inappropriately failing to set the flags will get #1e auth
failures against updated clients on configured-on hosts.

* Server admins must only enable the feature after all servers
implementing rcache-avoidable protocols have been updated to set the flags.
  - Configuring the feature prematurely will result in #1e auth failures
from updated clients.

Is that all correct?  (All of this is intended as description, not
judgement.)

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 18:09:06 -0600

> cache but the gssapi-with-mic ssh protocol does not.  Then:

Sure.  This is not the most interesting case though because ssh will
send its security context tokens over a confidentiality-protecting
channel.  A better example would be to posit SASL/GS2 service that
accepts non-channel-bound contexts, and to make it interesting make it
two SASL/GS2 services using the same credentials.  But let's use the
example you give for now.

(Of course, your example is close to good enough because you could
configure telnetd to not require encryption and some clients might not
request it.  It's only the fact that ssh has a secure channel that
makes the example not so interesting.  Note too that an active
attacker impersonating the ssh server could play the client's AP-REQ
to telnetd, and if telnetd does not require encryption then they're
in, but they have to slam the door on the ssh client since the
attacker will be detected as a MITM otherwise.)

> --> success without rcache

Yes.

> (authz data isn't honored)

Also, even if configured on, if sshd is old then the rcache will be
used (because sshd won't set the new cred options).

> this on until sshd is updated)

Yes.

There's also (1f), the case where telnetd is linked with an old
library but sshd is new and linked with a new library.  In that case
the failure is that sshd will not use an rcache, allowing a replay to
telnetd.

> telnetd + configured-on --> success with rcache (authz data isn't sent)

Yes.

> (authz data sent, appears as if a replayed ssh authenticator)

Yes.

> * GSS implementors must implement it (obviously)

Yes :)

> an rcache and set flags on the client and server as appropriate.

No.  Developers must describe the context.  If the app is using
channel binding to TLS with encryption then the app should set
GSS_C_CO_BOUND_TO_CONF_SEC_CHANNEL.  If the app protocol is such that
the client will send the first consequential per-message token, and
all consequential data will be protected, then the app should set
GSS_C_CO_IMPLIED_EXTRA_LEG.

I specifically want descriptive, not prescriptive options because I
don't think application developers should be deciding when an rcache
is needed or not.  They should describe what is or will happen and let
the mechanism decide when that means that the rcache is not needed.

> against updated and servers on configured-on hosts.

Yes, but such clients should not get deployed -- interop testing will find them.

(1e) is a very interesting case, but sysadmins will react to it by
disabling rcache avoidance, or not enabling it too soon in the first
place.

> successes with rcache use (possible DOS issue, but no worse than today).

Right.

> should be rare since they won't work against correct servers on

Yes.  But again, this is why the flags have to be descriptive, not prescriptive.

There's other mistakes that a developer could make that destroy
security -and that we could not stop them from making- that bother me
as much as or more than this one.

> failures against updated clients on configured-on hosts.

Yes.  Servers and libraries have be upgraded both before enabling the feature.

> implementing rcache-avoidable protocols have been updated to set the flags.

It's a bit more subtle: all raw Kerberos and Kerberos GSS mech
libraries/providers must be upgraded, and all server applications that
should be setting these options (either always or sometimes) must be
upgraded, before enabling the feature.  And this is a host-wide
requirement, not a realm-wide requirement.

>  - Configuring the feature prematurely will result in #1e auth failures

Yes.

> Is that all correct?  (All of this is intended as description, not

With the above minor corrections/nits, yes.  Thank you for listing all
those cases!

Nico

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 20:15:07 -0600

Something else that bears repeating is that practically all uses of
Kerberos AP exchanges or the Kerberos GSS mechanism don't need an
rcache or can be configured to never need an rcache:

 - No Internet protocol that uses the GSS-API other than SASL/GS2 and
HTTP/Negotiate needs an rcache except to protect other protocols that
do need an rcache;

 - No Internet protocol that uses raw Kerberos other than TELNET needs
an rcache except to protect other protocols that do need an rcache;

 - Most if not all proprietary protocols that use GSS that I've seen
so far don't need an rcache except to protect other protocols that do
need an rcache;

 - Protocols like rsh and TELNET don't need an rcache if configured
correctly (i.e., to always require encryption);

 - SASL/GS2 can be configured to not need an rcache (i.e., always
require channel binding to a channel that provides confidentiality
protection or unique CB);

 - HTTP/Negotiate can be used with channel binding, so it too can be
configured to not need an rcache;

To the extent that we need an rcache, we need it only during
migrations, until we can configure all services to not need an rcache
(or decommission services that can't be so configured).

In light of this, and of the fact that people regularly disable the
use of rcaches altogether (explicitly and implicitly), I don't think
the risk of admins accidentially enabling rcache avoidance too soon is
a big deal.

Independently of rcache avoidance (thoug perhaps accidentally because
of it), we should also explore the potential benefits of having
applications describe application protocol context to GSS mechanisms.

Nico

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Nov 2011 05:02:40 +0100 (MET)

> HTTP/Negotiate needs an rcache except to protect other protocols that

HTTP/Negotiate channel binding is optional, probably because
roughly half of the installed base (everything prior to Windows 7)
will _not_ send tls-unique channel bindings according to how
I understand Microsoft's Online documentation:

http://msdn.microsoft.com/en-us/library/dd919960%28v=vs.85%29.aspx

Btw. MIT Kerberos does not seem to support a smooth migration
for channel bindings.  If the server asserts channel bindings,
and the client didn't have channel bindings, security context
establishment will fail.  So you can not use MIT Kerberos in a
heterogeneous environment (=where only a fraction of the clients
is able to send channel bindings) unless no-one uses channel-bindings.

If you do not use a replay cache on the HTTP/Negotiate server at all,
then a passive observer could easily pick a non-channelbindings
plain Kerberos AP_REQ (like from an CIFS authentication) with that
server, insert it into an HTTP/Negotiate request and get served.

So all Authenticators from gssapi context establishments without
channel bindings need to be replay cached.

Even with replay cache in place, an attack might still be able
to observe a non-channel-bound Kerberos authentication on a shared
communication media (like ethernet) he could kill/corrupt the ethernet
frame before it has been completely sent and then insert the observed
AP_REQ into a HTTP-Negotiate request (while hogging the ethernet by
not leaving enough silence between his own ethernet frames for the
original sender to successfully resent the corrupted frame that
contained the orignal AP_REQ.

Does Microsoft really use at least SMB signing for CIFS and RPCs
by default?  I don't know the SMB/CIFS protocol details, how do both
ensure that signing is used (or code an MITM simply strip that)?
And what about the performance impact, is it really so insignificant
that nobody minds?

-Martin

---

From: Luke Howard <[email-masked]>
Date: Sat, 19 Nov 2011 01:01:21 +1100

> is able to send channel bindings) unless no-one uses channel-bindings.

In SSPI this is just a flag to allow missing bindings, but GSS doesn't let the acceptor pass in a flag. But it could be done with a context or credential option.

> And what about the performance impact, is it really so insignificant

MS RPC avoids a replay cache (GSS_C_DCE_STYLE). Not for SMB AFAIK.

-- Luke