Subject: [Ietf-krb-wg] OTP server nonce verification using FAST cookies

From: Linus Nordberg <[email-masked]>
Date: Wed, 17 Aug 2011 22:06:35 +0200

Hi,

While implementing draft-ietf-krb-wg-otp-preauth I'm trying to figure
out whether it's safe or not to verify the KDC-generated nonce the way
I'm planning to.

But first let me take a step back to see if I understand why this is
necessary.  I found Greg's posting[0] to this list on July 20 helpful
when trying to grasp all of this.

AFAICT the verification of the server nonce is there to ensure that a
given request is really a response to a given challenge.  Is it so and
is it perhaps even more than so?

I guess the consequences of a KDC not catching a replay of an OTP
request might be problematic for an OTP mechanism which for some reason
needs protection against that (TOTP?).  Another problem could be
de-synchronisation of counters (in tokens and the verification server).
The draft mentions reflection attacks too.  Are these threats valid?
Are there more?

The idea (from a comment by Sumit Bose) is to have the KDC put the nonce
in a PA-FX-COOKIE in the KRB-ERROR message with the PA-OTP-CHALLENGE
containing the nonce.  The client will copy the cookie to the AS-REQ
containing the PA-OTP-REQUEST and the KDC can then verify the nonce
against it.

I guess this won't help against replay unless the KDC's either remembers
used nonces.  Could a general replay cache help here?  MIT has one but
isn't this local to each KDC?  Or maybe using a (strictly increasing)
sequence number included in the nonce, as suggested in Greg's posting?

A related question is whether the cookie needs protection from
tampering?  Not for protecting against replay but rather from someone
with knowledge of the Client key.  If so, what key would be a good
candidate for this?

Part of my confusion might come from my weak understanding of how much a
FAST armor key can be trusted?  It seems to me that it might be
problematic to guarantee that it's known to only one single user -- if
it's a host key, wouldn't all users on the client host have access to
it?  And if it's from anonymous PKINIT there's apparently a risk for
MITM.

Lots of question, few answers.  Light appreciated.

[0] http://permalink.gmane.org/gmane.ietf.krb-wg/7857

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

---

From: Greg Hudson <[email-masked]>
Date: Wed, 17 Aug 2011 18:30:01 -0400

On Wed, 2011-08-17 at 16:06 -0400, Linus Nordberg wrote:
> given request is really a response to a given challenge.

That's the immediate intent.  But we don't directly care whether a
request is a response to a challenge.  We care about whether attackers
can get credentials they're not entitled to, or generate audit events
for successful authentications they're not entitled to generate.

> containing the nonce.

Although recommended by the OTP draft, I don't think cookies are
particularly valuable for OTP preauth.  Any mechanism to ensure
non-reuse of cookies would also work for ensuring non-reuse of encrypted
nonces.

>From a layering perspective, it would be nice if preauth mechanisms
could rely on a replay-proof, integrity-protected, confidential cookie
facility.  Then they would never have to worry about replay attacks in
multi-hop exchanges.  But we can't implement a replay-proof cookie
facility in MIT krb5 since we can't easily implement a realm-wide replay
cache.

> Or maybe using a (strictly increasing)

I think using a counter would create a lot of complexity.  Requests
aren't necessarily received in the same order as challenges are sent;
requests may be sent to different KDCs than generated challenges; KDCs
may be restarted suddenly.

> The draft mentions reflection attacks too.  Are these threats valid?

I wouldn't worry about reflection attacks for OTP preauth.  It's a
concern for bidirectional challenge-response protocols, but OTP preauth
is unidirectional.

> it?  And if it's from anonymous PKINIT there's apparently a risk for

MIT krb5 does not implement MITM-vulnerable anonymous PKINIT (we require
the KDC to be verified by the client via certificate).

Ticket-based armor is typically expected to be derived from a key known
only to the host, or in some cases a key known only to the user (a
previous TGT).  When possible, we would like to separate the
entitlements of the armor key from the entitlements of the user; for
instance, if you know a host key and observe an encrypted challenge
exchange, you don't get the user's credentials unless you can
dictionary-attack the user's key.

But the reality of OTP preauth is that for most OTP schemes, knowing the
armor key will get you the credentials.  Because the KDC will not have
access to the OTP value, KDCs will not set the (misnamed)
must-encrypt-nonce flag and the reply key will be the same as the armor
key.  It's only in the must-encrypt-nonce case that there is any
separation of entitlements.  This is not so bad because someone who
knows the host key (from which the armor key was derived) generally
controls the host, and could simply steal the user's credentials from
the credential store.

> Lots of question, few answers.  Light appreciated.

Here is what I would like to see implemented:

1. Compose a nonce value by concatenating a random value (of length
equal to the armor key length) and a timestamp.  No need for fancy
encoding here; just use binary concatenation and four-byte big-endian
encoding of the timestamp second and usec fields.

2. To validate, decrypt the nonce and check the timestamp against the
KDC time within the usual five-minute clock skew window.  Don't worry
about whether the random value bore any correlation to the challenge.

This prevents a request from being replayed (if the OTP scheme does not
already protect against this) more than five minutes after the challenge
was generated.  This is the same guarantee as encrypted challenge
preauth provides.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Aug 2011 19:12:17 -0400

>>>>> "Linus" == Linus Nordberg <[email-masked]> writes:

    Linus> A related question is whether the cookie needs protection
    Linus> from tampering?  Not for protecting against replay but rather
    Linus> from someone with knowledge of the Client key.  If so, what
    Linus> key would be a good candidate for this?

The cookie should always be modifyable only by the KDC.
Ways to accomplish this include:

1) Using constant strings that convey no information--the I don't really
need a cookie cookie

2) Using pseudo-random strings that are indexes into distributed
databases

3) encrypting a cookie in a key known only to the KDC.

When we wrote RFC 6113 we assumed 3 was the right answer.  These days I
think I'd tend towards 2.  There are a lot of distributed databases
floating around. Particularly if there is some locality to keys--that is
most of the time only one KDC will need to reference a record, there are
reasonable strategies for addressing this problem.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg