Re: [kitten] Kerberos preauth negotiation techniques

[Nico Williams <[e-mail]>]

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?

> 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.

Nico
--