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

From: Greg Hudson <[email-masked]>
Date: Thu, 23 Apr 2020 13:32:52 -0400

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.

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

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.

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

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 26 Apr 2020 14:14:35 -0700

Hi Greg,

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

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

> Some responses to a few of the smaller feedback items:

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

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

> Is there really any ambiguity in just saying "compressed"?  Terseness is

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.

> to implementors.  I think the test vectors are pretty clear in their

Okay.

Thanks for picking this up again,

Ben

---

From: Robbie Harwood <[email-masked]>
Date: Tue, 28 Apr 2020 19:53:31 -0400

Greg Hudson <[email-masked]> writes:

> 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 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
> .  I will update the draft unless it seems like there isn't WG
> consensus on this direction.

Appreciate you being proactive about picking up work on SPAKE again.

>> 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)?
>

CCing Nathaniel - anything to add?

I accept some of the blame for this - I think I wrote the language - but
the mailing list was Nathaniel's request.  I believe I modeled what it
specifies after RFC 7517 (there's no particular reason for that one,
just what we happened to be working on at the time).

Is it normal for requests to be sent to IANA at all when Designated
Experts are used?  Is the mailing list registration normally specified
in this fashion?  I can't find anything in RFC 8126 about it, but I'm
happy to make changes / accept changes to this document regardless.

Thanks,
--Robbie

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 28 Apr 2020 18:23:33 -0700

> happy to make changes / accept changes to this document regardless.

I think that the mailing list thing gained traction with a group of folks
in the OAuth community and expanded through to JOSE+JWT and then the IoT
analogues (COSE+CWT), at which point it was large enough that other
unrelated groups started picking up on it (including TLS).  There's nothing
that requires having a mailing list, though it does give the community some
visibility into the workings of the DE review process (as well as,
depending on list permissions, a way to get notified about pending
allocations).

That said, the default behavior you get for a registry if you don't say
otherwise, is that IANA is the first point of contact.  That is, you ask
IANA to allocate a value (usually via a webform), and behind the scenes
IANA goes off and talks to the Experts, before acting on the decision of
the Experts.  Sometimes IANA has to relay questions and answers back and
forth and it feels a bit silly, but that's the way it's historically been
done.

As a couple examples, RFC 7519 (JWT) creates [email-masked], and
https://datatracker.ietf.org/list/nonwg lists a few more.  I don't think
there is a perfect example yet of what text to use in the RFC when using
this sort of review process, though -- the examples that come to mind still
leave some ambiguity about what requestors and IANA are supposed to do.

-Ben

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 29 Apr 2020 10:26:49 -0400

> happy to make changes / accept changes to this document regardless.

I have no strong preference. I'd rather see movement on the document
than be held up in debates about this.

---

From: Robbie Harwood <[email-masked]>
Date: Wed, 29 Apr 2020 13:50:47 -0400

Benjamin Kaduk <[email-masked]> writes:

>>> 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.
>>>
>>> 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 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.
>>>
>>>> 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
>> I accept some of the blame for this - I think I wrote the language -
>> but the mailing list was Nathaniel's request.  I believe I modeled
>> what it specifies after RFC 7517 (there's no particular reason for
>> that one, just what we happened to be working on at the time).
>> 
>> Experts are used?  Is the mailing list registration normally
>> specified in this fashion?  I can't find anything in RFC 8126 about
>> it, but I'm happy to make changes / accept changes to this document
>> regardless.
>
> I think that the mailing list thing gained traction with a group of
> folks in the OAuth community and expanded through to JOSE+JWT and then
> the IoT analogues (COSE+CWT), at which point it was large enough that
> other unrelated groups started picking up on it (including TLS).
> There's nothing that requires having a mailing list, though it does
> give the community some visibility into the workings of the DE review
> process (as well as, depending on list permissions, a way to get
> notified about pending allocations).
>
> That said, the default behavior you get for a registry if you don't
> say otherwise, is that IANA is the first point of contact.  That is,
> you ask IANA to allocate a value (usually via a webform), and behind
> the scenes IANA goes off and talks to the Experts, before acting on
> the decision of the Experts.  Sometimes IANA has to relay questions
> and answers back and forth and it feels a bit silly, but that's the
> way it's historically been done.
>
> As a couple examples, RFC 7519 (JWT) creates [email-masked],
> and https://datatracker.ietf.org/list/nonwg lists a few more.  I don't
> think there is a perfect example yet of what text to use in the RFC
> when using this sort of review process, though -- the examples that
> come to mind still leave some ambiguity about what requestors and IANA
> are supposed to do.

Thanks, that's helpful background.

Ben, how would you feel about changing the language to read something
like:

    Registry entries are to be evaluated using the Specification
    Required method.  All specifications must be be published prior to
    entry inclusion in the registry.  Once published, they can be
    submitted directly to the [email-masked] mailing list,
    where there will be a three-week long review period by Designated
    Experts.

    Prior to the end of the review period, the Designated Experts must
    approve or deny the request.  This decision is conveyed to both IANA
    and the submitter.  Since the mailing list archives are not public,
    it should include both a reasonably detailed explanation in the case
    of a denial as well as whether the request can be resubmitted.

(I'm not particularly attached to the mechanics of this.  My concerns
are first requiring that a specification exists, and second that it be
checked for reasonableness without being too arduous for submitters.)

Thanks,
--Robbie

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 29 Apr 2020 13:32:05 -0700

> Ben, how would you feel about changing the language to read something

That seems fine to me.  I care approximately zero about the details of the
procedure, and just want it to be clear to everyone (especially the experts
and IANA) what the procedure is.

-Ben