Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06

[Benjamin Kaduk <[e-mail]>]

Hi Greg,

On Thu, Apr 23, 2020 at 01:32:52PM -0400, Greg Hudson wrote:
> Ben sent feedback on the SPAKE preauth draft a little over a year ago.
> I deferred acting on the smaller feedback items at the time, while
> observing the CFRG's progress on PAKE algorithms.

And that seemed wise at time time.  Sadly, I was not able to put much
energy into the CFRG SPAKE2 draft over the intervening period...

> The CFRG has selected CPace over SPAKE2 for a balanced PAKE.  As such I
> doubt there will be a need for a CFRG SPAKE2 document.  At this time I

This remains unclear to me -- at the CFRG interim session last week it was
mentioned that since Kenny had stepped down as chair, there was a need to
find a new shepherd for the CFRG SPAKE2 document.  That at least implies
that there is still an intent to publish it.

That said, given the delays that have already been incurred on that
document, it is seeming pretty reasonable to move ahead with the
krb-spake-preauth document without waiting for the CFRG one.

> don't think there would be sufficient interest in retooling the Kerberos
> preauth mechanism for CPace, or making breaking changes.  I have
> prepared changes to draft-ietf-kitten-krb-spake-preauth to drop its
> dependency on draft-irtf-cfrg-spake2, instead referring informatively to
> the Abdalla/Pointcheval paper and describing the group operations
> explicitly.
> 
> These changes, as well as updates addressing the smaller feedback items,
> are at
> https://github.com/greghudson/ietf/commit/6ecf1b9dfacc804692d858c726888855a512b8b7
> .  I will update the draft unless it seems like there isn't WG consensus
> on this direction.
> 
> Some responses to a few of the smaller feedback items:

Not too much left to say here (so skip almost to the end...)

> On 4/4/19 7:58 PM, Benjamin Kaduk wrote:
> >    The client and KDC will update the transcript hash with the pubkey
> >    value, and use the resulting hash for all encryption key derivations.
> > 
> > Isn't it the whole message and not just the pubkey value?
> 
> It's just the pubkey value.  The rest of the message is an encrypted
> field, and we need to finalize the transcript hash before deriving a key
> to encrypt with.
> >    1.  Determine the length of the multiplier octet string as defined in
> >        the IANA "Kerberos SPAKE Groups" registry created by this
> >        document.
> > 
> > If this multiplier length ended up being smaller than the key width for
> > the initial reply key, it seems like we'd end up losing security
> > strength.
> 
> Key derivation does a KRB-FX-CF2 with the initial reply key, for exactly
> this reason.  I don't think we need to call it out.
> 
> >    First, the hash function associated with the selected group is
> >    computed over the concatenation of the following values:
> > 
> > Do we want to include the client/server principal names here as well, as
> > suggested by draft-irtf-cfrg-spake2-08?
> 
> Client and server principal names are included in the KDC-REQ-BODY,
> which is one of the hashed elements.
> 
> >    o  The SPAKE result K, converted to an octet string as specified in
> >       Section 5.
> > 
> > I failed to convince myself that I saw where this conversion was
> > specified in Section 5.  Could you help me out?
> 
> First paragraph.  Admittedly it's just subcontracting out to the registry.
> 
> >                         The KDC-REQ-BODY contents are also incorporated
> >    into key derivation, ensuring their integrity.  The unauthenticated
> >    plaintext in the KDC-REP message is not protected by this mechanism.
> > 
> > Do we want to have a short note about how this is not expected to cause
> > problems (as it's the default state for all KDC exchanges)?
> 
> I think it would be hard to say anything correct without descending into
> a rathole.  There are some problems with unauthenticated plaintext in
> KDC-REP, which are addressed by implementations in kind of a patchwork
> way, and this preauth mechanism does not improve on that situation.
> 
> >    Subsequent factor data, including the data in the response, are
> >    encrypted in a derivative of the shared secret K.  Therefore, it is
> >    not possible to exploit the untrustworthiness of the challenge to
> >    turn the client into an encryption or signing oracle, unless the
> >    attacker knows the client's long-term key.
> > 
> > I'd consider adding a note "in which case the attacker does not need an
> > external oracle to encrypt or sign using that key".
> 
> That would be incorrect; as this section is talking about the factor
> challenge, it is talking about an encryption or signing oracle for the
> factor credentials, not for the long-term key.
> 
> > We discuss replay of cookie values by attackers, but don't really talk
> > about the related possibility of splicing cookie values across SPAKE
> > exchanges.  E.g., if an attacker observes two simultaneous requests and
> > swaps the cookies between the two before forwarding to the KDC.
> 
> It does talk about that ("SHOULD prevent cookie values from being
> applied to other pre-authentication mechanisms or other client
> principals"), but I made it a little more explicit.
> 
> >    Although this pre-authentication mechanism is designed to prevent an
> >    offline dictionary attack by an active attacker posing as the KDC,
> >    such an attacker can attempt to downgrade the client to encrypted
> >    timestamp.  [...]
> > 
> > Maybe "or similar preauthentication mechanisms"?
> 
> There isn't a big unknown supply of Kerberos preauth mechanisms.  This
> is specifically about encrypted timestamp.
> 
> > Section 10.6
> > 
> > Is there much that a KDC can do in the face of such an attack?  Will
> > forcing fallback to the full SPAKE exchange help at all (e.g., with
> > proof of return routability)?  We can't really suggest reusing ephemeral
> > key shares to reduce that part of the load.
> 
> draft-irtf-cfrg-spake explicitly forbade all reuse of ephemeral values,
> but I think it is actually safe to reuse a public key for a client.
> (That is, reusing the private multiplier x across clients is bad, but
> reusing T=xP+wM for a specific client is okay.)  I didnt change this
> section, but with the CFRG draft out of the picture, we could perhaps
> suggest public key reuse as a load mitigation strategy.
> 
> > In addition to potentially allocating a new value for the RFC version of
> > this spec, we probably also want to say a bit more about the
> > registration procedures.  Should requestors send the request directly to
> > the list, or to IANA first and IANA sends to the list?  Is the list
> > publicly archived (and can anyone sign up as a member)?
> 
> I'm a little lost here.  The mailing list was Nathaniel's idea and I am
> not attached to it.  There are hundreds of IANA registries; it seems
> like we should be picking from a few best practices for update
> procedures rather than breaking ground.

Unfortunately (from my vantage) the current field is pretty fragmented and
does not have a clear best practice to pick from.  E.g., the TLS and JWT
registries generally operate on a "requestor sends mail to the designated
list without involving IANA", but for things like ports and media-types
there's a request form that goes through IANA and then generates discussion
on the experts' mailing list.  I've been through the creation process for a
few registries now where we had to go back and forth with IANA several
times after the RFC was approved in order to figure out how the registry
was actually supposed to operate, and was hoping to have more of it written
down from the start, this time.

> >    o Serialization: [SEC1] section 2.3.3 (compressed).
> > 
> > I'd use a couple more words, e.g., "this specification uses the
> > 'compressed' point format". (multiple occurrences)
> 
> Is there really any ambiguity in just saying "compressed"?  Terseness is
> of value here.

Maybe "compressed format"?  I don't want a reader to have to pull the
reference to know that the parenthetical is clarifying the section
reference as opposed to being a verb indicating some additional procedure
applied after the referenced one.
That said, I'm not tied to anything specific here and don't insist on a
change.

> [Regarding test vectors:]
> > We use lowercase 'w' for both the PRF+ output and the reduced
> > multiplier; could we maybe use the majuscule form for one to
> > disambiguate?
> 
> We use uppercase letters for group elements, so that would be confusing.
>  The PRF+ output is an intermediate value that I thought would be useful
> to implementors.  I think the test vectors are pretty clear in their
> current form.

Okay.

Thanks for picking this up again,

Ben