[saag] Re: SKEX bof comment

On Mon, Mar 17, 2025 at 10:13 AM Melchior Aelmans <[email protected]>
wrote:

> Hi Eric,
>
> Some replies inline.
>
> Best,
> Melchior
>
> On Mon, Mar 17, 2025 at 4:21 PM Eric Rescorla <[email protected]> wrote:
>
>>
>>
>> On Sun, Mar 16, 2025 at 11:19 PM Michael Richardson <
>> [email protected]> wrote:
>>
>>>
>>> {not a BOF proponent. Speaking out of my ass based upon the IETF119 side
>>> meeting contents}
>>>
>>> Stephen Farrell <[email protected]> wrote:
>>>     > My first thought based on the intro/problem statement was: "why
>>> isn't
>>>     > kerberos enough?" and if it's not, "why not extend it to make it
>>> good
>>>     > enough?" (Or at least, say why that doesn't work.)
>>>
>>> Kerberos is enough within an enterprise, but it does not presently work
>>> well
>>> between enterprises.  This is mostly because they don't bother, but also
>>> looking forward, because inter-enterprise use involves "pkinit", that is,
>>> using RSA or ECDSA to initialize a ticket generating ticket between
>>> enterprises.
>>>
>>
>> The reason that this is needed is because each enterprise wants to run
>> its own KDC. If there was just one global KDC then you wouldn't need
>> this. That's effectively the topology that SKEX assumes. It's true that
>> they contemplate multiple KDCs, but those KDCs don't federate like
>> with Kerberos, they're just run in parallel.
>>
>
> Correct.
>
> We could (and should) make this quantum-safe, but if one is
>>> pessimistic about long-term safety of the quantum-safe algoritms, then it
>>> becomes the weak point, while the rest of the enterprise is safe.
>>>
>>
>> See above: you can  just run Kerberos in a pure symmetric mode.
>>
>
> That still doesn't solve the challenge that all KDC have knowledge of at
> least part of the key material.
>

See below.


>
>>
>> (Kerberos within the enterprise is essentially bootstrapped on a new
>>> desktop
>>> by the admin sitting down and enrolling the desktop using an admin
>>> password.
>>> That's an important point to consider.  It works well on the campus.
>>> But,
>>> it's why new laptops for new employees visit IT first...)
>>>
>>> SKEX won't be cheap in my opinion.  Possibly including bonded couriers.
>>> The model you might think about is Johnny Nmemonic :-)
>>> (Go watch the movie if you never have.  Especially when he "logs in" to
>>> the
>>> Internet...  And remember that Gibson wrote that book on a typewriter)
>>>
>>
>> It seems to me that from a practical perspective, Kerberos and SKEX are
>> isomorphic here. In both cases you need to share some symmetric keying
>> material. Kerberos is designed with a short key and then you use KDFs
>> to produce traffic keys, whereas KEX assumes you share a large key
>> and send out pieces of it, providing some element of FS, but I imagine
>> we could invent some kind of Kerberos ratcheting thing if we wanted to.
>>
> A potential protocol for SKEX to work on, DSKE
> <https://datatracker.ietf.org/doc/draft-mwag-dske/>, does not share any
> key material, only random data is shared between the central nodes and
> KMEs.
>
I don't see that there is any material difference between "random data" and
"key material". See below.

I uploaded the BoF slides
> <https://datatracker.ietf.org/meeting/122/session/skex/> earlier today,
> so you may want to check out the DSKE section (starting slide 25), which @Mattia
> Montagna <[email protected]> will be presenting during the BoF.
>
>
>>
>>
>>> A problem with Kerberos is that the KDC knows all the keys!
>>>
>>
>> This is just as true for SKEX.
>>
>
> No, see above.
>
>
>>
>>
>>> The description of the possible SKEX protocols from the side meeting last
>>> year suggested that by using/mixing keys from multiple "KDC" that it
>>> reduces
>>> the value/impact of capturing the "KDC".  An attacker would have to
>>> capture
>>> multiple key distribution systems.
>>
>>
>> Right, but you could use Kerberos the same way.
>>
>
> It seems there may have been some misunderstanding. One of the potential
> SKEX protocols, DSKE, utilises pre-shared random data to locally derive key
> material from it. Each ‘DSKE KDC’ only stores a portion of this pre-shared
> random data, meaning that even if a ‘DSKE KDC’ is compromised, an attacker
> would not have enough information to construct any keys.
> The point that an attacker would need to compromise multiple 'DSKE KDCs'
> in order to have enough pre-shared random data to successfully construct
> key is correct.
>

I agree with this claim, but I don't see any meaningful difference with
Kerberos. To recap, in DSKE, each client i shares some set of random data
R_i_j with KME j.

* In order to communicate with Bob, Alice generates a new random key R_ab
and splits it into M secret shares, denoted R_ab_j, with a threshold of M.
* Alice sends R_ab_j to KME j enciphered under some keying material derived
from a portion or R_a_j.
* KME j decrypts R_ab_j and then reencrypts it for Bob under keying
material derived from R_b_j.
* Bob takes the received values, decrypts them, and recovers R_ab.

An attacker who knows the R_a (or R_b) values for N KMEs can decrypt R_ab
and attack the encryption between Alice and Bob.


The way you would execute this with Kerberos is similar:

* Alice generates a new random key R_ab and splits it into M secret shares,
denoted R_ab_j, with a threshold of M.
* Alice contacts each KDC j and gets a ticket T_j for Bob. She then
enciphers R_ab_j to Bob under the key in that ticket.
* Bob decrypts the ticket, recovers R_ab_j, and then recovers R_ab

This has the same property that it's secure unless the attacker compromises
the keys of M KDCs.



This brings us back to the FS question. As hinted at above, and stated in S
11.4, in DSKE the client and the KME share a large stream of random data,
and each transaction uses a new section of that (presumably with both sides
discarding sections after they are used). This provides FS for
communications with the KME. By contrast in Kerberos, there is a single
fixed key between the client and the KDC. Perhaps this is what you are
referring to above? However, it's straightforward to recover FS in this
case by hashing the keys forward after each use, as MLS does.

-Ekr

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]