Subject: How do clients choose preauth mechanisms

From: [email-masked] (Sam Hartman)
Date: Fri, 16 Jul 2004 21:11:15 -0400 (EDT)

How does a client choose which preauth mechanisms to use?

For example if a server offers DH and encrypted timestamp which should
a client use?

The answer I'm assuming now is that the client performs all preauth
mechanisms it is capable of performing that do not conflict with the
requirements of previous mechanisms.

For example, the client would start DH.  It would then consider
encrypted timestap and fail to include it because encrypted timestap
would use the reply key and you cannot strengthen reply key after
you've already used it.

This assumption is quite complicated.  IT means that the client must
have an idea about what mechanisms will require in the future before
it starts other mechanisms.  It's possible to implement, but I think
we can come up with something better.

Another simple approach is that the client does at most one preauthy
thing per round trip.  People who want to minimize round trips will
not like this approach.

Another possibility is that the server gives the client sets of
preauth mechanisms that go well together and the client chooses the
first set for which it can support all the mechanisms.

Thoughts?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 19 Jul 2004 10:06:08 -0400

> [...]

> thing per round trip.  People who want to minimize round trips will

OK, but why does the client choose to do DH first instead of encrypted 
timestamp?  It's not just about avoiding conflicts; it's also about 
choosing the best set of non-conflicting preauths.

> first set for which it can support all the mechanisms.

This is still rather complex.  What's to prevent an attacker from telling 
the client to use DH and encrypted timestamp, or even just encrypted 
timestamp?

It seems that some amount of client configuration will be required.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 19 Jul 2004 10:03:57 -0500

> How does a client choose which preauth mechanisms to use?

Two choices: a) the first offering in the server-offered list that is
supported by the client, or b) the first item in the client's
configuration that is also offered by the server.

Either way is fine.  This could be configurable at the client.

> For example if a server offers DH and encrypted timestamp which should

DH would not do authentication, I presume, so a client interested in
authenticating as any non-anonymous principal wouldn't choose just DH.

I thought your proposal was to be about combining pre-auth mechanisms,
in which case we should speak of combinations.

So these make sense:

 - enc-timestamp
 - enc-timestamp + DH
 - host-ap-req + enc-timestamp
 - PKINIT
 - PKINIT + DH

Look at my stackable GSS pseudo-mech I-D.  One of the issues I had to
grapple was how to determine what features are offered by what mechs,
including composite mechs.

I think there is a similar issue here, with a possibly similar solution:
treat each pre-auth combination as a stack and ask the left/top-most
mechanism what features result when combined with the remaining
mechanisms (that lef/top-most mech may ask the combination of the
remaining mechanisms what its features are and so we recurse until we
hit the right-most mechanism).

Note: order matters.

We want to know whether a combination is complete (i.e., it can be used
without adding any more mechanisms to it) and what features it offers
(PFS, client auth w/ cert, server auth w/ cert, client auth w/ long-term
key, client auth w/ host TGT and client long term key, etc...), anon
client, etc...).

Surely we don't want to specify all possible combinations unless the
number is small; so a rules-based approach like the one I offer in the
stackable GSS pseudo-mech I-D makes sense to me.

> requirements of previous mechanisms.

See above.

> would use the reply key and you cannot strengthen reply key after

I see, a rules-based approach; good.

> we can come up with something better.

If we deal in pre-auth combinations this should not be a problem.  The
server says "I support these combos" and the client picks one that
satisfies its requirements without having to try the individual
pre-auths one by one until it hits a road-block or completes
successfully.

> thing per round trip.  People who want to minimize round trips will

See above.

> first set for which it can support all the mechanisms.

Yup, this is what I suggest.  I see no simpler approach.

Thus an offer of pre-auths could have this ASN.1 type syntax:

Pre-Auth-Combination ::= SEQUENCE OF Int32 -- pa-types are Int32's
Pre-Auth-Offer	     ::= SEQUENCE OF Pre-Auth-Combination

That is, negotiations is a matter of picking one element of a SEQUENCE
OF SEQUENCE OF INTEGER.  Not bad, plus it has a smallish encoding too.

Cheers,

Nico
--