[kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04)

Nathaniel McCallum-5
This all looks good. Thanks!

On Mon, Feb 5, 2018 at 1:00 AM, Greg Hudson <[hidden email]> wrote:

> This option seems to have the most initial WG support.  So I have put
> together proposed changes to the spec:
>
> https://github.com/greghudson/ietf/pull/4/commits/77753ee1c901ff771cba46b8c16d801fd8c74676
>
> I have also updated my Python implementation to produce updated test
> vectors, and my C implementation (for MIT krb5) to verify them.
>
> Substantial bits of new text:
>
> [In the section "SPAKE Pre-Authentication Message Protocol":]
>   Each group definition specifies an associated hash function, which
>   will be used for transcript protection and key derivation.
>
> [In the section "Second Pass":]
>   The client and KDC will each initialize a transcript hash [xref]
>   using the hash function associated with the hosen group, and update it
>   with the concatenation of the DER-encoded PA-SPAKE messages sent by
>   the client and the KDC.
>
> [In the section "Optimizations":]
>   If the group chosen by the challenge message is supported by
>   the client, the client MUST skip to the third pass by issuing an
>   AS-REQ with a PA-SPAKE message using the response choice. In this case
>   no SPAKESupport message is sent by the client, so the first update to
>   the transcript hash contains only the KDC's optimistic challenge. If
>   the KDC's chosen group is not supported by the client, the client MUST
>   continue to the second pass. In this case both the client and KDC MUST
>   reinitialize the transcript hash for the client's support message.
>   Clients MUST support this optimization.
>
> [In the section "Transcript Hash":]
>   When the transcript hash is updated with an octet string input, the
>   new value is the hash function computed over the concatenation of the
>   old value and the input.
>
>   In the normal message flow or with the second optimization described
>   in [xref], the transcript hash is first updated with the concatenation
>   of the client's support message and the KDC's challenge, and then
>   updated a second time with the client's pubkey value. It therefore
>   incorporates the client's supported groups, the KDC's chosen group,
>   the KDC's initial second-factor messages, and the client and KDC
>   public values. Once the transcript hash is finalized, it is used
>   without change for all key derivations [xref].
>
>   If the first optimization described in [xref] is used successfully,
>   the transcript hash is updated first with the KDC's challenge message,
>   and second with the client's pubkey value.
>
>   If first optimization is used unsuccessfully (i.e. the client does
>   not accept the KDC's selected group), the transcript hash is computed
>   as in the normal message flow, without including the KDC's optimistic
>
>   challenge.
>
> [In the section "Key Derivation":]
>
>   [As the fourth field in the hash input:]
>   The PRF+ output used to compute the initial secret input w as
>   specified in [xref].
>
>   [As the ninth and final field in the hash input:]
>   A single-byte block counter, with the initial value 0x01.
>
>   If the hash output is too small for the encryption type's key
>   generation seed length, the block counter value is incremented and the
>   hash function re-computed to produce as many blocks as are required.
>   The result is truncated to the key generation seed length, and the
>   random-to-key function is used to produce the key value.
>
> The section "Update to Checksum Specifications" is removed, and with it
> the prohibition against using SPAKE with single-DES enctypes.
>
> For the pa-hint for authentication sets, I realized that we probably
> want to include second factor info as well as KDC group support, so I
> will address that in a separate update and thread.
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04

Nathaniel McCallum-5
In reply to this post by Benjamin Kaduk-2
Unless I'm missing something, I don't think this is necessary. When
the hash is associated with the group choice, the output size of the
hash is correlated to the strength of the group used. If a new enctype
arises with stronger keys, increasing the hash alone won't increase
the security of the SPAKE exchange itself. Therefore, an entirely new
group is needed.

On Sun, Feb 4, 2018 at 10:06 PM, Benjamin Kaduk <[hidden email]> wrote:

> I also think that we should probably go with one of the first two
> options.  There is some appeal to attaching the hash to the SPAKE
> group, since they both are things new in this spec and we don't have
> to awkwardly try to force enctypes to also include a new thing.
> The downside is of course that we might choose a hash that is "too
> small" for some hypothetical new enctype that uses large keys, but
> presumably we will notice the conflict if such a new enctype arises,
> and can make new group entries (even if they are the same underlying
> groups) with larger hashes.
>
> -Ben
>
> On Thu, Feb 01, 2018 at 03:15:58PM -0500, Nathaniel McCallum wrote:
>> I agree with Simo. The first two options are probably the best. I
>> don't have a strong opinion between them. However, I suspect that we
>> aren't worried about compatibility at this point (nobody ships this).
>>
>> On Thu, Feb 1, 2018 at 2:11 PM, Simo Sorce <[hidden email]> wrote:
>> > On Thu, 2018-02-01 at 12:17 -0500, Sam Hartman wrote:
>> >> > > > > > "Simo" == Simo Sorce <[hidden email]> writes:
>> >>
>> >>     Simo> It is a bit annoying to have to do this for each new enctype
>> >>     Simo> ... just for a pre-auth mechanism.  I wonder if we couldn't
>> >>     Simo> simply add a field in the first message that specifies the
>> >>     Simo> hash we are using.  The server can then just refuse operations
>> >>     Simo> if it doesn't want to use the hash the client selected.  This
>> >>     Simo> would allow smooths transitions from "current-hash" to
>> >>     Simo> "new-hash" in case current hash is not totally broken right
>> >>     Simo> away, but like SHA-1 gets weaker and weaker and we plan
>> >>     Simo> replacement.
>> >>
>> >> I think that the idea of combining the hash definition with the group
>> >> definition is about the same as this, only a bit simpler.
>> >>
>> >> My ranked options are:
>> >>
>> >> * Combine choice of hash with choice of group (Kerberos SPAKE groups
>> >>   include a hash function in their definition).  Requires changing the
>> >>   spec to restart the hash when a KDC rejects an optimistic group
>> >>   offer.  Greg and I believe the security of this is fine.
>> >>
>> >> * Registering a mapping of SPAKE hashes to enctypes.  The major
>> >>   advantage I see is that it can (I think) maintain interop with the
>> >>   existing protocol.  The down side is that in some cases you might have
>> >>   to register a new enctype or except a non-ideal SPAKE hash.
>> >>
>> >> * Use the PRF.  I think  that while the concerns are real, the security
>> >>   is fine
>> >>
>> >> * Your proposal of hash in first message
>> >
>> > I think the above options are all fine by me, maybe not in the same
>> > exact order, but they all work.
>> >
>> >> *  Get sufficient review and make RFC 3961 hashes deterministic
>> >>
>> >> * Find other options
>> >>
>> >> * Give up on SPAKE
>> >
>> > I'd rather not go into the last three, but I am open to other options
>> > that have substantial advantages and no big downside compared to the
>> > first 4 on the table that it is worth spending time on them.
>> >
>> > Simo.
>> >
>> > --
>> > Simo Sorce
>> > Sr. Principal Software Engineer
>> > Red Hat, Inc
>> >
>> > _______________________________________________
>> > Kitten mailing list
>> > [hidden email]
>> > https://www.ietf.org/mailman/listinfo/kitten
>>
>> _______________________________________________
>> Kitten mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04)

Greg Hudson
In reply to this post by Greg Hudson
On 02/05/2018 01:00 AM, Greg Hudson wrote:
>   [As the fourth field in the hash input:]
>   The PRF+ output used to compute the initial secret input w as
>   specified in [xref].
[...]
>   If the hash output is too small for the encryption type's key
>   generation seed length, the block counter value is incremented and the
>   hash function re-computed to produce as many blocks as are required.
>   The result is truncated to the key generation seed length, and the
>   random-to-key function is used to produce the key value.

Nathaniel wrote, in a different part of the thread responding to Ben:
> When
> the hash is associated with the group choice, the output size of the
> hash is correlated to the strength of the group used. If a new enctype
> arises with stronger keys, increasing the hash alone won't increase
> the security of the SPAKE exchange itself. Therefore, an entirely new
> group is needed.

Ben may have been thinking about the protocol working at all (easily
solved by hash extension), but Nathaniel's response made me think about
the possibility that the SPAKE exchange might reduce the work an
attacker would require to discover the reply key, in the case where the
initial reply key was high-entropy to start with.  As Nathaniel notes,
for this possibility we have to consider the group as well as the hash
function.

To make a long story short, I think to be excruciatingly correct we
should compute KRB-FX-CF2 of the derived key with the initial reply key,
in case w (as represented by the PRF output used to compute it) is
shorter than the initial reply key was and therefore contains lower
entropy.  So we would have:

  reply-key <- KRB-FX-CF2(initial-reply-key,
                          random-to-key(H(...|w|K|...)),
                          pepper1, pepper2)

That way we can't possibly make the reply key any worse.  This is only
really an issue for a future where attackers can do 2^128 brute force
work (enough to break ECDLP on edwards25519 or P-256), but we may as
well get it right.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04)

Nathaniel McCallum-5
Agreed.

On Feb 5, 2018 3:32 PM, "Greg Hudson" <[hidden email]> wrote:
On 02/05/2018 01:00 AM, Greg Hudson wrote:
>   [As the fourth field in the hash input:]
>   The PRF+ output used to compute the initial secret input w as
>   specified in [xref].
[...]
>   If the hash output is too small for the encryption type's key
>   generation seed length, the block counter value is incremented and the
>   hash function re-computed to produce as many blocks as are required.
>   The result is truncated to the key generation seed length, and the
>   random-to-key function is used to produce the key value.

Nathaniel wrote, in a different part of the thread responding to Ben:
> When
> the hash is associated with the group choice, the output size of the
> hash is correlated to the strength of the group used. If a new enctype
> arises with stronger keys, increasing the hash alone won't increase
> the security of the SPAKE exchange itself. Therefore, an entirely new
> group is needed.

Ben may have been thinking about the protocol working at all (easily
solved by hash extension), but Nathaniel's response made me think about
the possibility that the SPAKE exchange might reduce the work an
attacker would require to discover the reply key, in the case where the
initial reply key was high-entropy to start with.  As Nathaniel notes,
for this possibility we have to consider the group as well as the hash
function.

To make a long story short, I think to be excruciatingly correct we
should compute KRB-FX-CF2 of the derived key with the initial reply key,
in case w (as represented by the PRF output used to compute it) is
shorter than the initial reply key was and therefore contains lower
entropy.  So we would have:

  reply-key <- KRB-FX-CF2(initial-reply-key,
                          random-to-key(H(...|w|K|...)),
                          pepper1, pepper2)

That way we can't possibly make the reply key any worse.  This is only
really an issue for a future where attackers can do 2^128 brute force
work (enough to break ECDLP on edwards25519 or P-256), but we may as
well get it right.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04)

Benjamin Kaduk-2
In reply to this post by Greg Hudson
On Mon, Feb 05, 2018 at 03:32:05PM -0500, Greg Hudson wrote:

> On 02/05/2018 01:00 AM, Greg Hudson wrote:
> >   [As the fourth field in the hash input:]
> >   The PRF+ output used to compute the initial secret input w as
> >   specified in [xref].
> [...]
> >   If the hash output is too small for the encryption type's key
> >   generation seed length, the block counter value is incremented and the
> >   hash function re-computed to produce as many blocks as are required.
> >   The result is truncated to the key generation seed length, and the
> >   random-to-key function is used to produce the key value.
>
> Nathaniel wrote, in a different part of the thread responding to Ben:
> > When
> > the hash is associated with the group choice, the output size of the
> > hash is correlated to the strength of the group used. If a new enctype
> > arises with stronger keys, increasing the hash alone won't increase
> > the security of the SPAKE exchange itself. Therefore, an entirely new
> > group is needed.
>
> Ben may have been thinking about the protocol working at all (easily
> solved by hash extension), but Nathaniel's response made me think about
> the possibility that the SPAKE exchange might reduce the work an
> attacker would require to discover the reply key, in the case where the
> initial reply key was high-entropy to start with.  As Nathaniel notes,
> for this possibility we have to consider the group as well as the hash
> function.

Right, I mean the case where the group size matches the SPAKE hash, but
the enctype is bigger than both, though you have taken this even a
little further than I had in mind.  (But it still makes sense!)

> To make a long story short, I think to be excruciatingly correct we
> should compute KRB-FX-CF2 of the derived key with the initial reply key,
> in case w (as represented by the PRF output used to compute it) is
> shorter than the initial reply key was and therefore contains lower
> entropy.  So we would have:
>
>   reply-key <- KRB-FX-CF2(initial-reply-key,
>                           random-to-key(H(...|w|K|...)),
>                           pepper1, pepper2)
>
> That way we can't possibly make the reply key any worse.  This is only
> really an issue for a future where attackers can do 2^128 brute force
> work (enough to break ECDLP on edwards25519 or P-256), but we may as
> well get it right.

Yup.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04)

Sam Hartman-5
In reply to this post by Nathaniel McCallum-5
>>>>> "Nathaniel" == Nathaniel McCallum <[hidden email]> writes:

    Nathaniel>    Agreed.

The changes, including the discussion of  using krb-fx-cf2 to protect
initial high-entropy reply keys.
I agree that high entropy reply keys are unlikely in cases where SPAKE
is valuable, but it's relatively easy to do.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
12