[saag] Re: [skex] Re: Re: SKEX bof comment

Eric

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

You seem to be *proposing* a protocol that uses Kerberos is one of its
components, not telling us that Kerberos implements this protocol.  By
"would", which do you mean: "could" or "already do"?  I will take it as the
former.  Are you proposing to suggest this to the SKEX WG for
standardization?  Your proposal partially mimics the DSKE protocol, and
indeed seems to directly draw on it.  It has the disadvantages of Kerberos,
of course: it requires multiple back-and forth messages to retrieve the
tickets, and requires that Bob be an internet server publicly receiving
incoming communication (remember, Kerberos is built to support only a
client–server model).  It also would need embellishment for Bob to be sure
that he had produced the same final key that Alice has (i.e., you have not
ensured the property of correctness, which is necessary for it to be
considered secure).

DSKE can be readily modified to replace the pre-shared random data with a
key stream generator without modifying the protocol, aside from the
setting-up.  This is exactly what I would propose to support constrained
embedded environments.

So, I am mystified at what your point is.  It could have been meant that we
already have something that is better for all use cases, but it clearly
fails to show that.  Instead, all it is actually seems to point out is that
the shares-based scheme of DSKE might be worth considering as part of a
potential SKEX protocol.

Manfred

On Mon, Mar 17, 2025 at 2:12 PM Eric Rescorla <[email protected]> wrote:

>
>
> 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
>
> --
> skex mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

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