Re: [kitten] Kerberos preauth negotiation techniques

[Nathaniel McCallum <[e-mail]>]

On Mon, 2015-02-23 at 15:12 -0600, Nico Williams wrote:
> On Mon, Feb 23, 2015 at 2:13 PM, Nathaniel McCallum <
> [e-mail]> wrote:
> > 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:
> 
> Sure, a PAKE per-pre-auth.  If we want new PAKEs, we clone this pre-
> auth, change the PAKE, give it a new number.
> 
> > 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?
> 
> Just use the enctype's authenticated encryption, natch.
> 
> > Enctype negotiation is implicit from the existing exchange. This 
> > leaves only groups and second factors.
> 
> Making second factors negotiable is going to make the UI very fun :/ 
> But it probably has to get done anyways.
> 
> > 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
> 
> Sure.
> 
> > OpenSSL does not support Curve25519 (yet) so it won't be offered 
> > in my implementation.
> 
> OpenSSL needs to add Curve25519 support ASAP (particularly now that 
> there is consensus in CFRG for Curve25519 as an RTI at the 128-bit 
> security level), but is a subject for a different list.
> 
> > One reason I don't think it will be a problem is that no other 
> > data is
> 
> What won't be a problem?

OID bloat.

> > 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.
> 
> Eh, if I understood correctly you're saying that the client 
> shouldn't send a list/set of groups.
> 
> Either the client does send a set/list of groups or the server must 
> return a PAKE message for each group.  The latter is not going to 
> work well for every PAKE.  Having the server choose one without any 
> idea of what the client supports just won't do.
> 
> Just have the client send a set (SEQUENCE) of OIDs.  If you really 
> hate the wire bloat, then send both, an enum bit string and a 
> sequence of OIDs, with the latter absent when only registered groups 
> are proposed and the former absent when no registered groups are 
> proposed.

No. I'm saying that the first message from the client to the server 
contains ONLY a SEQUENCE OF OBJECT IDENTIFIER. The reply contains the 
server's choice from that list, the public key from that chosen group, 
and 2FA parameters.

I'm saying the OID bloat isn't really a problem.

Nathaniel