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

On Mon, Mar 17, 2025 at 1:30 PM Manfred von Willich <
[email protected]> wrote:

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

The way (IETF) we should be evaluating a potential SKEX WG is:

- Is there a problem here worth solving?
- What is the best technical approach to solving it?

In this thread, I'm looking at the second question--which is not to
say I am convinced on the first--and part of that involves looking at
what already exists.

A huge part of the complexity of designing a system like this is the
protocol you use for talking to the KDC/KME, as well as integrations
into the relevant application protocols. We have an off the shelf
protocol for this (Kerberos) that is already fully specified,
standardized, and widely deployed. This implies that if we are going
to do something in this area, we should ask how much of the problem is
already solved by Kerberos and how hard it would be to extend it to
address any gaps.

>From my perspective, probably the biggest gap is the multiple KDC key
sharing functionality, and I think it's quite probable one could
extend Kerberos to do that, along the lines that I indicated, and
quite possibly in a way that allowed gradual migration from single-KDC
to multi-KDC operation. You raise a number of other points which
I'm less persuaded by, but obviously a WG would have to look at them
and see how significant they were.

As I said, I'm not necessarily sold that this problem needs to be
addressed, but if we are going to address it, then, yes, I think we
should be looking at Kerberos as one potential starting point.

-Ekr


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