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

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Rick van Rein (OpenFortress)
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
On Mon, Oct 29, 2018 at 08:51:59AM +0100, Rick van Rein wrote:

> 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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
On Mon, Oct 29, 2018 at 12:26:11PM -0500, Benjamin Kaduk wrote:

> On Mon, Oct 29, 2018 at 08:51:59AM +0100, Rick van Rein wrote:
> > 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.

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
In reply to this post by Rick van Rein (OpenFortress)
On 10/29/2018 03:51 AM, Rick van Rein wrote:
> 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).

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
On Mon, Oct 29, 2018 at 02:38:25PM -0400, Greg Hudson wrote:

> On 10/29/2018 03:51 AM, Rick van Rein wrote:
> >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.  

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
On Mon, Oct 29, 2018 at 01:52:21PM -0500, Nico Williams wrote:
> On Mon, Oct 29, 2018 at 02:38:25PM -0400, Greg Hudson wrote:
> >           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.)

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
In reply to this post by Nico Williams
On Mon, Oct 29, 2018 at 01:52:21PM -0500, Nico Williams wrote:

> On Mon, Oct 29, 2018 at 02:38:25PM -0400, Greg Hudson wrote:
> > On 10/29/2018 03:51 AM, Rick van Rein wrote:
> > >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.  
>
> 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,

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

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

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

>    d) the acceptor responds with an AP-REP (if GSS_C_MUTUAL_FLAG is set
>       anyways).
>
> Nico
> --
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
On Mon, Oct 29, 2018 at 05:25:03PM -0500, Benjamin Kaduk wrote:

> On Mon, Oct 29, 2018 at 01:52:21PM -0500, Nico Williams wrote:
> > 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,
> >
> >    [...]
>
> 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).

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

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Rick van Rein (OpenFortress)
In reply to this post by Nico Williams
Hey Nico,

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

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

> 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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Rick van Rein (OpenFortress)
In reply to this post by Greg Hudson
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
In reply to this post by Rick van Rein (OpenFortress)
On Tue, Oct 30, 2018 at 10:45:32AM +0100, Rick van Rein wrote:

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

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.

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
In reply to this post by Rick van Rein (OpenFortress)
On Tue, Oct 30, 2018 at 11:46:57AM +0100, Rick van Rein wrote:
> 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.

I don't follow.

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

Yes.

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

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

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
In reply to this post by Nico Williams
On Tue, Oct 30, 2018 at 10:02:32AM -0500, Nico Williams wrote:

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

Have you seen draft-barnes-tls-pake?

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
On Tue, Oct 30, 2018 at 08:13:31PM -0500, Benjamin Kaduk wrote:
> On Tue, Oct 30, 2018 at 10:02:32AM -0500, Nico Williams wrote:
> >     - TLS 1.3 w/ some PAKE -> replaces the new Kerberos PAKE PA
>
> Have you seen draft-barnes-tls-pake?

Indeed, I have.

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Srinivas Cheruku-3
In reply to this post by Rick van Rein (OpenFortress)
Hello Nico,
   
    > 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.
   
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
On Wed, Oct 31, 2018 at 04:50:14AM +0000, Srinivas Cheruku wrote:

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Rick van Rein (OpenFortress)
In reply to this post by Nico Williams
Hi,

>> 1. The service may declare its realm; in other Kerberos
>> protocols that is considered to be a no-go area.
>
> I don't follow.

Usually, when a service can declare a realm, it is given an opportunity
to sidetrack credentials to that choice of realm.  Other Kerberos
applications choose to infer the realm on the client or in his KDC,
which can be a nuisance, but a secure nuisance.

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

Not completely sure yet, I want to experiment with it.  Possible places
could be (1) as an alternative to StartTLS and (2) as an end-to-end
facility within a client-server connection.

I like the model of SASL-within-TLS, but only from the perspective of
authentication; it leaves things to be desired concerning end-to-end
encryption, which TLS tries very hard to avoid.

I'm also wondering what Quantum Crypto would change; for instance,
OpenSSH looses its secure status but could benefit from mixing the
Kerberos session key with the (EC)DH shared key.  (That's what we did in
TLS-KDH too.)

-Rick

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