Re: [kitten] Kerberos preauth negotiation techniques

[Nathaniel McCallum <[e-mail]>]

On Wed, 2015-02-18 at 14:43 -0600, Nico Williams wrote:
> On Wed, Feb 18, 2015 at 03:16:29PM -0500, Greg Hudson wrote:
> > On 02/17/2015 11:14 AM, Nathaniel McCallum wrote:
> > > 1 and 3 are also compatible workflows. In 3, the first AS-REQ is 
> > > exactly the same padata as the second AS-REQ in 1. That is to 
> > > say, 3 is an optimization of 1 where the first round-trip of 1, 
> > > which includes no meaningful data, is simply not used. Put 
> > > another way, 3 is just 1 with optimistic preauth.
> > 
> > That's an interesting way of looking at things.  It means we 
> > wouldn't have to amend RFC 6113, although we might be bending it a 
> > bit.  Here are some considerations, which all seem manageable:
> > 
> > * Traditionally, optimistic preauth is only done with some prior
> > knowledge of what the KDC wants (see RFC 6113 section 2.3 
> > paragraph 1).
> >  To get down to two round trips in the common case, an AS client  
> > needs
> > to do optimistic PA-PAKE by default.
> 
> When the client has only one pre-auth it's willing to do then it can 
> be optimistic.  That doesn't seem terribly likely in many cases, but 
> for environments where 2fa is used for protecting some resources and 
> not others, then it could be clear at AS-REQ time that the client 
> only wants to do 2fa.
> 
> Clients can also tell -sometimes- when they have credentials for 
> PKINIT.  And they can learn and cache -or have configured- whether a 
> realm's KDCs support FAST for protecting PA-ENC-TIMESTAMP, and so 
> on. It may not be such a stretch that a client will have just one 
> pre-auth method that it's willing to use in some cases.
> 
> > * Of course PA-PAKE would need to be specified such that the first
> > client message requires no knowledge from the KDC.  This is pretty 
> > simple; the first client message can be defined to contain only 
> > sub-negotiation parameters.
> 
> Yea, we're already there as to this proposal.
> 
> > * Most KDC implementations will ignore the client's PA-PAKE padata 
> > if
> > they don't implement it, and respond with PREAUTH_REQUIRED with 
> > METHOD-DATA.  Some older KDCs (like MIT krb5 pre-1.7) will instead 
> > respond with PREAUTH_FAILED.  Clients already need to deal with 
> > this behavior if they implement RFC 6112 encrypted padata 
> > negotiation or any similar extension, so this is not really a 
> > concern.
> 
> Good point.
> 
> > * An optimistic PA-PAKE message should be cheap to compute (it's 
> > just
> > parameters), but is still wasted bytes if the exchange winds up 
> > settling on a different mechanism or not using preauth at all.  
> > The more compactly we can represent client parameters, the less 
> > bandwidth we will waste and the fewer problems we will have with 
> > AS-REQs exceeding UDP limitations.
> 
> We can greatly "compress" it by using bit sets (which could be 
> compressed if there are many contiguous zero bits in the bit string).
> 
> The trade-off is requiring a registry.  For PAKEs and groups, an OID 
> would do just fine, or we could use an existing (or upcoming) 
> registry.
> 
> A middle of the road proposal would be to use a bit set for 
> registered PAKEs and groups and an optional set (sequence) of OIDs 
> for all others.
> 
> But all this to save a bit of space?  Before we go there we should 
> determine that this really is a problem we need to address.

On the call last week there was a general consensus to move forward 
with SPAKE2 and not make PAKEs negotiable. SPAKE2 has all the 
properties we care about. It:
* has a formal security proof that is well regarded
* takes only a single roundtrip
* supports elliptic curves
* has wide deployment (via Chromium/Chrome)

We also had a general consensus that there is no need to negotiate 
hashes. There are three hash uses:
1. Transcript for message integrity
2. Key derivation
3. Key validation

For #1, we can just use the checksum method implicit in the enctype.

For #2, we can just use a KDF.

For #3, Greg had an idea, but I've since forgotten it and can't find 
it in my email. Greg, perhaps you can remind me?

Enctype negotiation is implicit from the existing exchange. This 
leaves only groups and second factors.

We also discussed making group negotiation have a note in the RFC 
about being careful regarding the number of groups exposed. I suspect 
sensible defaults will be:
* P-256
* P-384
* P-521
* Curve25519

OpenSSL does not support Curve25519 (yet) so it won't be offered in my 
implementation.

One reason I don't think it will be a problem is that no other data is 
sent in the group negotiation packet from the client to the server. 
The response from the server will contain just one group OID along 
with the public key and the 2FA negotiation parameters.

I suggest an empirical approach here. I'll be developing the RFC in 
parallel with the application itself. If we see this becoming a 
problem, we can address it at that time. I am open even to bit set 
negotiation if space becomes a serious concern. I would simply like to 
avoid a registry if it is not needed.

> > * Can a client optimistically preauthenticate with multiple > > mechanisms?
> >  RFC 6113 doesn't really say either way.  Without going into 
> > detail on
> > the arguments pro and con:
> 
> A separate update to RFC6113 about this would be nice.
> 
> >   - If we assume no, then a client which does optimistic PA-PAKE by
> > default can't do the same thing with any other mechanism.  This 
> > could be a reasonable choice; the client implementation could 
> > always choose to drop back to three round trips for PA-PAKE if it 
> > wants to do optimistic PA-FUTURE-AWESOME by default in the future.
> 
> Well...  See above.  Also, a client could be somewhat abusive and 
> send N single-preauth AS-REQs concurrently, hoping one of them will 
> succeed.
> 
> >   - If we assume yes, then a client which does optimistic PA-PAKE 
> > is
> > still privileging that mechanism by choosing to spend bandwith on 
> > it before it is negotiated.  But it wouldn't necessarily have to 
> > exclude other mechanisms from doing the same thing.
> 
> Yes, but hopefully the client knows from context that it will need 
> this PA method.