[kitten] User-to-user Kerberos in GSS-API

Post by Rick van Rein
Hello,
I'm looking into user-to-user encryption with Kerberos, and that can be
done when a user submits a TGT (without the key) to the intended
communication peer, who can then send it to the KDC to obtain a
user-to-user ticket. This is considered difficult and theoretical.
In GSS-API, it should be doable to insert a phase preceding standard
Kerberos5, where a TGT is pushed from the initiator to the acceptor, who
then contacts its KDC, and so on. We've seen a similar thing in SPNEGO.
Has this been considered / and if so, why did it not mature?

I don't know of it having been explicitly considered previously (though I
did not attempt to search the archives and confirm), but mostly assume that
it was seen as uninteresting given the general low usage level of
user-to-user functionality.

-Ben

Nico Williams

2018-10-29 18:31:38 UTC

I have a use for user-to-user, as well as for multi-round-trip
extensions to the existing mechanism.

The use for this has to do with keying clusters atomically, which is
difficult to pull off. If you have user-to-user, you can always just
make sure that each member of a cluster can get a TGT for the service
principal name and not bother making sure they all have the latest keys
for the service principal name. Using PA-TGS for AS exchanges would
even make it possible for a host to get TGTs for containers/guests
without having to ever even have keys for the container services -- this
would be an amazing simplification to key management.

Multi-round-trip extensions can also make cluster key management easier,
naturally.

Of course, since we have these key management issues now, we already
work to solve them in our key management frameworks (e.g., Roland
Dowdeswell's krb5_admin/krb5_keytab stack), and will continue to have
to for a long time. But it would be very nice if we could get started
on making these problems go away, even if it takes a decade to get
universal support.

Nico
--

Rick van Rein

2018-10-30 09:45:32 UTC

Hey Nico,

Post by Nico Williams
The use for this has to do with keying clusters atomically, which is
difficult to pull off. If you have user-to-user, you can always just
make sure that each member of a cluster can get a TGT for the service
principal name and not bother making sure they all have the latest keys
for the service principal name.

I had to read this five times :) but if I understand it, it is a clever use. I was thinking p2p protocols, but you are saying that you don't want to use the long-term service keytab but rather derive a TGT on a daily basis, right? Intereting to use u2u for that indeed! and sound like it'd work.

I've been thinking about such problems too, but resorted to doing the GSS exchange in a protected environment and then handing out the security context to a lesser process that could handle the symmetric stuff. In fact, that's what we're considering doing with TLS also; hand off the long-term credentials-based negotiation to a separate TLS Pool, and get back the symmetric stuff for local, in-line handling. (Whoops, I'm taking off now, sorry.)

It does sound like TLS-KDH can do what you want. Progress on that has been stifling, mostly because 1.3 grabbed the attention of GnuTLS developers, but I'm told that it will soon get in there -- and then we'll move on with that spec too. It has a Kerberos-only mode and is Post Quantum, by the way. In short, the server either sends no key or a TGT, and the client either sends a service ticket or initiates u2u exchanges. I thought it was the first such application.

Post by Nico Williams
Using PA-TGS for AS exchanges would
even make it possible for a host to get TGTs for containers/guests
without having to ever even have keys for the container services -- this
would be an amazing simplification to key management.

Yes, our work with TLS Pool confirms that. It also simplifies code, but then again, TLS is always more dramatic than Kerberos. If you want to read more (all in-progress):

https://tools.ietf.org/html/draft-vanrein-tls-kdh-04
https://github.com/arpa2/tlspool
https://github.com/arpa2/docker-demo/tree/master/build-tlspool
[the latter is not yet built with a TLS-KDH supportive GnuTLS]

Post by Nico Williams
Multi-round-trip extensions can also make cluster key management easier,
naturally.

I have no idea what you mean with this. But I am curious!

-Rick

Nico Williams

2018-10-30 15:02:32 UTC

Correct.

User-to-user was originally meant for X11, both for users to be able to
connect to their own X11 displays, and for display sharing (I imagine
anyways) without having to have long-term service keys, but that just
hasn't worked out. Perhaps new p2p cases can be deployed, but given
that most of the relevant services involve some degree of
centralization (in the enterprise at least), I doubt it.

Post by Rick van Rein
I've been thinking about such problems too, but resorted to doing the
GSS exchange in a protected environment and then handing out the
security context to a lesser process that could handle the symmetric
stuff. [...]

The problem with that is increased latency on the server side.

Post by Rick van Rein
[...]. In fact, that's what we're considering doing with TLS also;
hand off the long-term credentials-based negotiation to a separate TLS
Pool, and get back the symmetric stuff for local, in-line handling.
(Whoops, I'm taking off now, sorry.)

No, I do think that's interesting from a privilege separation point of
view.

Post by Rick van Rein
It does sound like TLS-KDH can do what you want. Progress on that has
been stifling, mostly because 1.3 grabbed the attention of GnuTLS
developers, but I'm told that it will soon get in there -- and then
we'll move on with that spec too. It has a Kerberos-only mode and is
Post Quantum, by the way. In short, the server either sends no key or
a TGT, and the client either sends a service ticket or initiates u2u
exchanges. I thought it was the first such application.

TLS 1.3 can do what I want, yes.

A few things worth thinking about re: TLS 1.3:

- Kerberos tickets can function as session resumption tickets

It would be good to have a general purpose ticket cache library for
clients and ticket decryptor / authenticator validation library for
services.

- TLS 1.3 could be the foundation of new Kerberos KDC protocols:

- TLS 1.3 w/ PSK -> replaces PA-ENC-TIMESTAMP
- TLS 1.3 w/ client certs -> replaces PKINIT
- TLS 1.3 w/ Kerberos tickets as resumption tickets -> replace PA-TGS
- TLS 1.3 w/ some PAKE -> replaces the new Kerberos PAKE PA
- TLS 1.3 can secure KDC exchanges and completely simplify
everything to do with reply keys and what not
- we'd still have AP exchanges, but we could also have...
- ...a TLS 1.3 based GSS-API mechanism (like the GSI SSL mech)
- ...

On the down side, we'd then lose FAST unless we did TLS-over-TLS (not
quite renegotiation, mind you), which I'm sure is bound to upset
some.

Post by Rick van Rein
https://tools.ietf.org/html/draft-vanrein-tls-kdh-04
https://github.com/arpa2/tlspool
https://github.com/arpa2/docker-demo/tree/master/build-tlspool
[the latter is not yet built with a TLS-KDH supportive GnuTLS]

I'll take a look.

Post by Nico Williams
Multi-round-trip extensions can also make cluster key management easier,
naturally.

I have no idea what you mean with this. But I am curious!

RFCs 1964 and 4121 specify the GSS-API Kerberos mechanism, and that is a
half- or one-round trip mechanism. The initiator sends an AP-REQ plus a
little header, the acceptor responds with an AP-REP plus a little
header. But if anything goes wrong, then the acceptor sends back a
KRB-ERROR and the whole thing fails. We could (should!) extend the
mechanism so that the initiator can indicate that it can do extra round
trips, and then we can have the following scenario:

I->A: AP-REQ
A->I: KRB-ERROR (KRB_AP_ERR_BADKEYVER)
I<->TGS: get new service ticket
I->A: AP-REQ
A->I: AP-REP

(this could happen if you rebuild the service with new keys and lose the
old keys)

or

I->A: AP-REQ
A->I: Ticket
I<->TGS: user-to-user
I->A: AP-REQ
A->I: AP-REP

all while using the same GSS-API mechanism OID.

Nico
--

Benjamin Kaduk

2018-10-31 01:13:31 UTC

Correct.
User-to-user was originally meant for X11, both for users to be able to
connect to their own X11 displays, and for display sharing (I imagine
anyways) without having to have long-term service keys, but that just
hasn't worked out. Perhaps new p2p cases can be deployed, but given
that most of the relevant services involve some degree of
centralization (in the enterprise at least), I doubt it.

The problem with that is increased latency on the server side.

No, I do think that's interesting from a privilege separation point of
view.

TLS 1.3 can do what I want, yes.
- Kerberos tickets can function as session resumption tickets
It would be good to have a general purpose ticket cache library for
clients and ticket decryptor / authenticator validation library for
services.
- TLS 1.3 w/ PSK -> replaces PA-ENC-TIMESTAMP
- TLS 1.3 w/ client certs -> replaces PKINIT
- TLS 1.3 w/ Kerberos tickets as resumption tickets -> replace PA-TGS
- TLS 1.3 w/ some PAKE -> replaces the new Kerberos PAKE PA

Have you seen draft-barnes-tls-pake?

Post by Nico Williams
- TLS 1.3 can secure KDC exchanges and completely simplify
everything to do with reply keys and what not
- we'd still have AP exchanges, but we could also have...
- ...a TLS 1.3 based GSS-API mechanism (like the GSI SSL mech)
- ...
On the down side, we'd then lose FAST unless we did TLS-over-TLS (not
quite renegotiation, mind you), which I'm sure is bound to upset
some.

See https://www.ietf.org/mail-archive/web/atlas/current/maillist.html .
(Spoiler: yes, it has.)

-Ben

I'll take a look.

Post by Nico Williams
Multi-round-trip extensions can also make cluster key management easier,
naturally.

I have no idea what you mean with this. But I am curious!

RFCs 1964 and 4121 specify the GSS-API Kerberos mechanism, and that is a
half- or one-round trip mechanism. The initiator sends an AP-REQ plus a
little header, the acceptor responds with an AP-REP plus a little
header. But if anything goes wrong, then the acceptor sends back a
KRB-ERROR and the whole thing fails. We could (should!) extend the
mechanism so that the initiator can indicate that it can do extra round
I->A: AP-REQ
A->I: KRB-ERROR (KRB_AP_ERR_BADKEYVER)
I<->TGS: get new service ticket
I->A: AP-REQ
A->I: AP-REP
(this could happen if you rebuild the service with new keys and lose the
old keys)
or
I->A: AP-REQ
A->I: Ticket
I<->TGS: user-to-user
I->A: AP-REQ
A->I: AP-REP
all while using the same GSS-API mechanism OID.
Nico
--

Nico Williams

2018-10-31 04:10:00 UTC

Post by Nico Williams
- TLS 1.3 w/ some PAKE -> replaces the new Kerberos PAKE PA

Have you seen draft-barnes-tls-pake?

Indeed, I have.

Post by Nico Williams
On the down side, we'd then lose FAST unless we did TLS-over-TLS (not
quite renegotiation, mind you), which I'm sure is bound to upset
some.

See https://www.ietf.org/mail-archive/web/atlas/current/maillist.html .
(Spoiler: yes, it has.)

Oh, I bet!

There's at least two other ways to get FAST-like privacy semantics.

One would be to copy ACME, which will be doing HTTP-in-HTTP (sort of,
IIUC), where encrypted requests as POSTed in the outer HTTP. We could
do something similar using a the GSI mechanism, where we'd POST GSS
tokens (context and wrap tokens) on an outer HTTPS and the unwrapped
contents are the inner requests and responses. If it works for ACME, it
would work for this. It's not like we're averse to nesting things,
considering that FAST *is* just that.

Another possibility would be to pursue encrypted cert payload, much like
encrypted SNI. If we can get encrypted SNI, we can encrypt other
privacy-sensitive parts fo the handshake.

My preference would be the latter, mostly because it simplifies the
application. I'm pretty sure we can get it too.

We are going to need a GSS-API mechanism that can use PK credentials for
a variety of reasons, even if we also do an RFC2712 follow-on. Yes,
there's PKU2U, but I'm not too keen on it: for complexity management
reasons I'd rather use the GSI approach than PKU2U. Yes, I know the GSI
approach has some interesting issues, but I think we can iron them all
out (e.g., TLS has no out of order messaging, but that's what DTLS is
for, and neither has anything like MIC tokens, but we can construct them
anyways, and neither has a channel binding input, but we can extend TLS
for that too).

Nico
--

Srinivas Cheruku

2018-10-31 04:50:14 UTC

Hello Nico,

How does the cluster get the TGT for itself if it has no key e.g. no key table file?
Or if the key in the key table file is old, then MS AD would not issue a TGT using that old key.
Or am I missing something here?

Thanks,
Srini

Nico Williams

2018-10-31 04:58:26 UTC

Post by Srinivas Cheruku

How does the cluster get the TGT for itself if it has no key e.g. no
key table file? Or if the key in the key table file is old, then MS
AD would not issue a TGT using that old key. Or am I missing
something here?

It's not necessarily that it has no key, but that it may not have the
latest keys, or enough keys for all outstanding tickets.

Also, suppose you have a host running various guests/containers: the
host could push the TGTs into the guests. How does the host get the
TGTs? Perhaps by using PA-TGS as pre-auth for an AS-REQ, and the KDC
knows that the host is authorized to request TGTs for the given guest
services.

Nico
--

Greg Hudson

2018-10-29 18:38:25 UTC

Post by Rick van Rein
In GSS-API, it should be doable to insert a phase preceding standard
Kerberos5, where a TGT is pushed from the initiator to the acceptor, who
then contacts its KDC, and so on. We've seen a similar thing in SPNEGO.

There is

https://tools.ietf.org/html/draft-swift-win2k-krb-user2user-03

which I believe is implemented in Windows SSPI but not in MIT krb5 or
Heimdal. In this mechanism the TGT goes from the acceptor to the
initiator, which I think helps keep the code paths similar to what they
are for the regular krb5 mech (although the acceptor cred for this mech
would need to be more similar to a krb5 initiator cred than to a krb5
acceptor cred).

Nico Williams

2018-10-29 18:52:21 UTC

Post by Greg Hudson

There is
https://tools.ietf.org/html/draft-swift-win2k-krb-user2user-03
which I believe is implemented in Windows SSPI but not in MIT krb5 or
Heimdal.

We should implement this.

Post by Greg Hudson
In this mechanism the TGT goes from the acceptor to the initiator,
which I think helps keep the code paths similar to what they are for the
regular krb5 mech (although the acceptor cred for this mech would need to be
more similar to a krb5 initiator cred than to a krb5 acceptor cred).

That is the correct way to do it. (An inverted mechanism would also
work, but would require new AP messages so that authorization data can
flow from the initiator to the acceptor.)

We could also do this with the same mechanism OID as in RFC4121 as
follows (this is desirable because it simplifies negotiation):

1. TGS-driven user2user with RFC4121 mech OID:

a) the initiator attempts a TGS exchange and gets
KDC_ERR_MUST_USE_USER2USER,

b) the initiator prepares a 1-octet initial security context token
(plus the OID wrapper) and sends it,

c) (a) implies that the acceptor knows how to handle this 1-octet
token and sends back its TGT,

d) the initiator does a TGS exchange with the acceptor's TGT as the
second ticket and then sends an AP-REQ,

e) the acceptor responds with an AP-REP (if GSS_C_MUTUAL_FLAG is set
anyways).

2. Acceptor-driven user2user with RFC4121 mech OID:

This is a variant of the multi-round-trip extension...

a) the initiator does a TGS exchange, gets a service ticket, sends an
AP-REQ, but with an ap-option indicating it's willing to perform
additional round-trips,

b) the acceptor can't decrypt the service ticket but has a TGT, so it
responds with its TGT as the reply token,

c) the initiator does a TGS exchange with the acceptor's TGT as the
second ticket and then sends an AP-REQ,

d) the acceptor responds with an AP-REP (if GSS_C_MUTUAL_FLAG is set
anyways).

Nico
--

Nico Williams

2018-10-29 21:20:47 UTC

That is the correct way to do it. (An inverted mechanism would also
work, but would require new AP messages so that authorization data can
flow from the initiator to the acceptor.)

Although even such an inverted flow would still have the problem that
the KDC could not communicate KDC-issued ADs to the acceptor without
extending the TGS-REP as well.

But on the other hand, anything we do to increase symmetry in the
protocol would be good.

Nico
--

Benjamin Kaduk

2018-10-29 22:25:03 UTC

Post by Greg Hudson

There is
https://tools.ietf.org/html/draft-swift-win2k-krb-user2user-03
which I believe is implemented in Windows SSPI but not in MIT krb5 or
Heimdal.

We should implement this.

That is the correct way to do it. (An inverted mechanism would also
work, but would require new AP messages so that authorization data can
flow from the initiator to the acceptor.)
We could also do this with the same mechanism OID as in RFC4121 as
a) the initiator attempts a TGS exchange and gets
KDC_ERR_MUST_USE_USER2USER,
b) the initiator prepares a 1-octet initial security context token
(plus the OID wrapper) and sends it,
c) (a) implies that the acceptor knows how to handle this 1-octet
token and sends back its TGT,

I'm not sure that I see this implication always occurring -- we don't have
a great channel for an acceptor to inform the KDC about its functional
capabilities (as a floor of functionality across all nodes that have a
key for that principal).

Post by Nico Williams
d) the initiator does a TGS exchange with the acceptor's TGT as the
second ticket and then sends an AP-REQ,
e) the acceptor responds with an AP-REP (if GSS_C_MUTUAL_FLAG is set
anyways).
This is a variant of the multi-round-trip extension...
a) the initiator does a TGS exchange, gets a service ticket, sends an
AP-REQ, but with an ap-option indicating it's willing to perform
additional round-trips,
b) the acceptor can't decrypt the service ticket but has a TGT, so it
responds with its TGT as the reply token,
c) the initiator does a TGS exchange with the acceptor's TGT as the
second ticket and then sends an AP-REQ,

To be clear, this is just for the case when the service ticket is encrypted
to a key that is "too new" for this instance to have, but the principal in
the TGT is the same as the principal that the service ticket is for? If it
can change then we have some exciting authorization checks to make...

-Ben

Post by Nico Williams
d) the acceptor responds with an AP-REP (if GSS_C_MUTUAL_FLAG is set
anyways).
Nico
--
_______________________________________________
Kitten mailing list
https://www.ietf.org/mailman/listinfo/kitten

Nico Williams

2018-10-29 23:18:17 UTC

Post by Nico Williams
We could also do this with the same mechanism OID as in RFC4121 as
a) the initiator attempts a TGS exchange and gets
KDC_ERR_MUST_USE_USER2USER,
[...]

Sure we do, and KDC_ERR_MUST_USE_USER2USER exists, and it assumes that
channel. It's the same channel we use to negotiate a shared secret
key(set) between the two, and the service principal's supported enctype
set.

And the existing kadm5/kadmin/kadmind implementations I do believe
support this (it's just an attribute).

Post by Nico Williams
This is a variant of the multi-round-trip extension...
a) the initiator does a TGS exchange, gets a service ticket, sends an
AP-REQ, but with an ap-option indicating it's willing to perform
additional round-trips,
[...]

Yes, the initiator has to make sure that the service principal name does
not change. And it'd better already be the case that the TGS exchange
with the second ticket protects the second ticket from modification in
flight, and that the KDC verifies the ticket's sname. (But that all
better be true now, else u2u is broken.)

Nico
--

Rick van Rein

2018-10-30 10:46:57 UTC

Hey,

Post by Greg Hudson
https://tools.ietf.org/html/draft-swift-win2k-krb-user2user-03

I think this one might raise problems:

1. The service may declare its realm; in other Kerberos
protocols that is considered to be a no-go area.

2. For services it makes sense to prod them for their TGT;
for users this could be a privacy leak, as they are given no
grounds for acceptance vs. denial decisions.

I was thinking about a symmetric approach, where peers start as
acceptors, but switch to initiator when they need to send, and ship
their TGT for it. In case of cross-fire, the TGT with the highest bytes
(MSB at the entropic end) wins and the other cuts heel, becomes an
acceptor and deferring sending until connected. When a context expires,
it switches to a new initiator on sending, or a new acceptor on
receiving. This wraps around (or prefixes) the usual Kerberos flow.

Perhaps it's worth speccing this one out as an alternative?

I am thinking primarily of users. I would like to experiment with a
STARTGSS operation that behaves somewhat like STARTTLS, but could also
connect users directly (finally a good mechanism to exchange passwords,
yay!) It could be added to my TLS Pool, invalidating its name but not
its logic, and make it a one-hour patch to existing code.

-Rick

Nico Williams

2018-10-30 15:19:45 UTC