[saag] Re: SKEX bof comment

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.

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


>
>> Salz, Rich <[email protected]> wrote:
>>     > Overall, I'd like to see something that could be more naturally fit
>> to
>>     > peer-to-peer, is more efficient, and has improved security
>>     > properties. This is not to mention the separate question of the best
>>     > way to do unmediated key refreshment. None of this is meant to
>> detract
>>     > from Kerberos.
>>
>>     > It would be very helpful if you could explain what is missing from
>>     > Kerberos.  For example, do you want to make sure that you get the
>> same
>>     > key for A/B communication no matter who asks first?
>>
>> I don't know if any present browsers can use GSSAPI/Kerberos to do HTTPS.
>> I know that some libraries can do it.  And for non-browser HTTPAI, it's
>> probably gonna work.
>>
>
> I don't believe they do.
>
>
> Kerberos is not deployed to the home (maybe to some people on this list,
>> yes); but neither do I think SKEX would be deployed to the home.   In a
>> quantum-unsafe future (where lattice methods have fallen to some
>> convential
>> attack),  I imagine residential users being enrolled into their ISPs'
>> Kerberos, and the ISPs using SKEX to establish inter-enterprise Kerberos.
>
>
> It's hard to project ourselves forward into a world where there's no public
> key cryptography for key establishment at all [0]. With that said, this is
> not
> really the topology I envision [1]: we already have a whole policy
> apparatus
> for identifying endpoints, which is to say the WebPKI, so the natural thing
> to do is to have the CAs become KDCs This is of course a logistical
> nightmare,
> but it matches the current trust relationships. I certainly don't want to
> have
> to trust my ISP to authenticate servers to me: one of the reasons to use
> encryption is that you don't trust your network provider!
>
> -Ekr
>
> [0] We'll presumably still have hash signatures.
> [1]
> https://educatedguesswork.org/posts/pq-emergency/#what-if-the-pq-algorithms-aren't-secure%3F
> _______________________________________________
> saag 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]