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

From: Rick van Rein <[email-masked]>
Date: Mon, 29 Oct 2018 08:51:59 +0100

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?

Thanks,
 -Rick

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 29 Oct 2018 12:26:11 -0500

> 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

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Oct 2018 13:31:38 -0500

> user-to-user functionality.

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

---

From: Greg Hudson <[email-masked]>
Date: Mon, 29 Oct 2018 14:38:25 -0400

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Oct 2018 13:52:21 -0500

On Mon, Oct 29, 2018 at 02:38:25PM -0400, Greg Hudson wrote:
> Heimdal.  

We should implement this.

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Oct 2018 16:20:47 -0500

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 29 Oct 2018 17:25:03 -0500

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

>       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

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Oct 2018 18:18:17 -0500

On Mon, Oct 29, 2018 at 05:25:03PM -0500, Benjamin Kaduk wrote:
> >    [...]

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

> >    [...]

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

---

From: Rick van Rein <[email-masked]>
Date: Tue, 30 Oct 2018 10:45:32 +0100

Hey Nico,

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

> Using PA-TGS for AS exchanges would

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]

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

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

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Tue, 30 Oct 2018 11:46:57 +0100

Hey,

> 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

---

From: Nico Williams <[email-masked]>
Date: Tue, 30 Oct 2018 10:02:32 -0500

On Tue, Oct 30, 2018 at 10:45:32AM +0100, Rick van Rein wrote:
> 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.

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.

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

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

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

> [the latter is not yet built with a TLS-KDH supportive GnuTLS]

I'll take a look.

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 30 Oct 2018 10:19:45 -0500

> protocols that is considered to be a no-go area.

I don't follow.

> grounds for acceptance vs. denial decisions.

Yes.

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

Elsewhere in this thread I explained the problem with reversing the
flows: the protocols are insufficiently symmetric as to authorization
data.  And, of course, the fix is to make them more symmetric.

So, yes, this should work:

I->A: TGT
A<->TGS: 2nd ticket request to get a ticket for talking to the initiator
A->I: AP-REQ
I->A: AP-REP

> its logic, and make it a one-hour patch to existing code.

StartTLS is a feature of protocols like SMTP, SUBMIT, IMAP, and so on --
generally SASL apps.  (HTTP has a StartTLS that is not implemented and
nobody uses.)  Where would you use StartGSS?

Anyways, we (SASL WG, now KITTEN WG) long ago decided that the right
approch for SASL apps is to a) use TLS, b) use SASL with channel binding
to TLS, c) do not use GSS for the "SL" part of SASL.  See RFC5801.  SASL
effectively became SA.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Oct 2018 20:13:31 -0500

>     - TLS 1.3 w/ some PAKE -> replaces the new Kerberos PAKE PA

Have you seen draft-barnes-tls-pake?

>    quite renegotiation, mind you), which I'm sure is bound to upset

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

-Ben

---

From: Nico Williams <[email-masked]>
Date: Tue, 30 Oct 2018 23:10:00 -0500

> Have you seen draft-barnes-tls-pake?

Indeed, I have.

> See https://www.ietf.org/mail-archive/web/atlas/current/maillist.html .

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

---

From: Srinivas Cheruku <[email-masked]>
Date: Wed, 31 Oct 2018 04:50:14 +0000

Hello Nico,
    
    > for the service principal name.
    
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

---

From: Nico Williams <[email-masked]>
Date: Tue, 30 Oct 2018 23:58:26 -0500

On Wed, Oct 31, 2018 at 04:50:14AM +0000, Srinivas Cheruku wrote:
> 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
--