Subject: [Ietf-krb-wg] Rcache avoidance: use a GSS flag, or authz-data?

From: Nico Williams <[email-masked]>
Date: Sat, 13 Aug 2011 21:55:44 -0500

We need something in the Authenticator (not the AP-REP ap-options --
this needs to be integrity protected) to indicate whether the
client/initiator will be sending a per-message token (or
KRB-SAFE/PRIV) first thing after getting an AP-REP back.

We need a GSS flag, that's for certain, since we can use this
knowledge in other GSS mechanisms.

The question is: how do we handle this in the Kerberos GSS mechanism?
I see two basic options: 1) use a GSS flag in the 0x8003 "checksum",
and/or 2) use an authz-data element in the Authenticator.  (Either
way, the confirmation of the AP-REP implied by the client/initiator's
first data message will be in the form of the client/initiator using
only the acceptor's sub-session key.)

If (1) only then rcache avoidance cannot be used by non-GSS krb5 apps.

If (2) only then the GSS flag that could/will appear in the 0x8003
checksum would/will be redundant.

My preference is for (2) only, with the GSS flag redundantly appearing
in the 0x8003 checksum, but not checked by the acceptor.

My questions for the WG: is (2) too difficult for any implementors?
and if so, should we consider (1) only instead?  and if so, do we mind
not having rcache avoidance for non-GSS krb5 apps?

Thanks,

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

---

From: Jeffrey Altman <[email-masked]>
Date: Sun, 14 Aug 2011 22:51:53 -0400

> not having rcache avoidance for non-GSS krb5 apps?

I am in favor of (2) only.   I am aware of non-GSS krb5 application
protocols that are currently under development that would benefit from
rcache avoidance.  Even if I wasn't aware of such protocols, I wouldn't
want to penalize the use of raw krb5 protocol.

Jeffrey Altman

---

From: Greg Hudson <[email-masked]>
Date: Mon, 15 Aug 2011 11:09:25 -0400

> not having rcache avoidance for non-GSS krb5 apps?

I don't think authdata is too difficult for us.

I have some related questions.  A library can be conforming (implements
the spec) or not.  An application can be cooperating (sets the GSS or
equivalent krb5 flag) or not.  The authenticator can be flagged or not.
A conforming library, when used by a cooperating server application,
when receiving a flagged authenticator, may choose to use no replay
cache.

Two questions, then.

1. Conforming library + non-cooperating application + flagged
authenticator.  Is the authenticator rejected or accepted (with replay
cache)?  If accepted, does this open up attacks where you cut and paste
the authenticator from a cooperating app into a non-cooperating one?
(For example, steal an ssh authenticator and use it with
authentication-only rlogin.)  If rejected, how does new library + new
ssh client interoperate with new library + old ssh server?

2. Non-conforming library + flagged authenticator.  Should this
combination reject the authenticator (i.e. is the authdata going to be
critical)?  Realistically, I'm not sure any krb5 implementations obey
the criticality of authdata, so this may be a moot question.  If the
authdata is critical, though, we again need to ask how new library + new
ssh client interoperates with old library + old ssh server.

Basically, I'm trying to figure out the purpose of an authenticator flag
within the design.  The client's intent to send a message token after
establishing the context isn't all that interesting; that's usually a
property of the application protocol.  So I'm assuming the flag is there
to prevent non-replay-cached authenticators from being used to attack
servers which (due to their application protocol) need a replay cache.

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Aug 2011 13:18:38 -0500

> when receiving a flagged authenticator, may choose to use no replay

There's very little for the *application* on the server side to do
different than in any other case, but it is critical that it do
something: either tell the library that it expects an implied 3rd leg,
or check if the client indicated that it will use an implied 3rd leg
and then hold the client to it.  In practice this is what happens.
Apps that don't use per-message tokens / KRB-SAFE/PRIV have other
problems (unless they're using channel binding to a secure channel):
they're subject to active data modification attacks.  Old apps that
don't handle implied 3rd leg nego + new libraries that do *could*
worsen the problem: they become susceptible to replay attacks, which
do not require on-path active attack capability, just eavesdropping
capability.

> ssh client interoperate with new library + old ssh server?

If the library can determine whether the application is "old" then the
library can simply reject the authenticator.  This is no sweat for the
krb5 API: we can add a new function by which to indicate whether the
server app gets this.  It's a bit of a pain for the GSS case since we
have no krb5_context equivalent in GSS (see the other presentation I
made at KITTEN).

An explicit 3rd leg negotiation solution wouldn't have these problems
at all.  An explicit 3rd leg wouldn't necessarily add round-trips: the
client's first per-message tokens could be sent without waiting for
the server to ack the security context (depending on the app anyways).

Food for thought.  Thanks for your comments!

Nico

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Aug 2011 16:46:35 -0500

> Food for thought.  Thanks for your comments!

If we assume (bear with me) that *GSS* apps always have either an
implied 3rd leg or channel binding (bear with me) or know to check for
the new ret_flag (clearly this is not true), then we could treat this
flag as critical in "old" non-GSS, raw krb5 apps.  Of course, making
the flag critical in general would mean it'd be unsafe to use without
knowing a priori that the server/acceptor supports it -- a nasty
complication.

That assumption may be correct for GSS, non-SASL/GS2 apps (hmmm, I'd
have to look at FTP again).  But it's clearly incorrect for SASL/GS2
since the fact that GSS CB is used does not imply that there's a
secure channel, and the mechanism can't look in the CB data to
determine if there is.  Of course, if SASL/GS2 servers knew to fail
authentication when the new ret_flag is set and SASL CB were not used,
then it'd be OK, but only if the rest of the assumption is correct.

If we reject that assumption completely then we can only ever use
implied 3rd leg when:

a) all GSS and krb5 libs and server/acceptor apps on the server are "new",

which implies that we need a way for libgss and the mechs to know that
the apps are new, or else a locally global configuration setting
indicating whether they are (a bit of a leap of faith).

So we'd want b) the libraries know when the server/acceptor app
understands the new flag.

(b) is particularly difficult for GSS, and I don't want to have to
tackle the lack of a GSS call context just to tackle rcache avoidance!

We need to examine the above assumption.  It makes me quite
uncomfortable, but I don't want to reject it out of hand, if only
because otherwise we either have to rely on local configuration (that
could be wrong), do much more work to do for implied 3rd leg or
abandon it outright, and I'm not ready to do any of those yet.

I am willing to shelve implied 3rd leg and go instead for explicit 3rd
leg.  In many apps an explicit 3rd leg will not slow anything down
because the client/initiator's first data message can be sent without
waiting for an ACK from the server.  This is true of SSHv2 (IIRC, but
I'll double check later), NFS (RPCSEC_GSS), and others, but not of
SASL/GS2 (because the app needs to wait for the SASL outcome of
authentication message, which adds a round-trip in this case).

Note that IF we'd had implied 3rd leg negotiation from the get-go
(i.e., two decades ago), THEN it'd have been safe without having to
make any assumptions.

Also, of course, I take a very dim view of apps that use neither CB
nor have an implied 3rd leg.  But we know we need to support SASL/GS2
w/o CB (but often with TLS) at least during a transition period.

Thinking a little more about this...  If one always configures rshd
and rlogind to require encryption and to require the use of the
Authenticator checksum (all of which means fixing all the clients to
do the do the same, which is hard), and configured ftpd to require
protection of commands and data, and so on... or if one turned all of
those services off, then we could disable the rcache altogether for
apps like SSHv2, NFS, AFS, ...   Maybe this is just the better
approach, even though it requires much care on the part of the
administrator.

Nico