Subject: [abfab] GSS-Preauth and decoupling for GSS-EAP

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Sep 2011 09:52:41 -0400

Hi.
At the mic in Quebec I raised the following issue about GSS preauth and
ABFAB.

I want to be able to use GSS preauth between the RP and the KDC even if
the initiator knows nothing about it.

That is: gss-eap initiator <-> RP FAST(rp armor key,
gss-preauth(gss-eap)) RP <->KDC When that happens:

* The initiator should obtain a TGT which it probably can't use because
  well it doesn't know about gss preauth

* The RP should obtain a service ticket. This is critical and is the
  motivation for allowing gss preauth even when the initiator dosen't
  know about it. This allows the KDC to be a central policy point all
  the time gss-eap is used.

* The initiator and KDC know the TGT key

* The initiator, RP and KDC know the context key for the gss-eap context
  between the initiator and RP. It's not critical the KDC knows this
  key, but it will

is there any interest in figuring out how to do this. If we cannot then
Moonshot may end up introducing a separate eap-preauth proposal to meet
this use case. It would be highly desirable to avoid both eap-preauth
and gss-preauth. I think everyone agrees that gss-preauth is cleaner if
we can make it work.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 6 Sep 2011 17:28:24 +0200

Hi Sam:

Please see my comments/questions inline.

> the initiator knows nothing about it.

Could you elaborate a little bit about the motivation related to this and what is the associated issue?

> gss-preauth(gss-eap)) RP <->KDC When that happens:

Before going into detail I would like to understand this flow (at first sight, it vaguely reminded me the use of IAKERB where the RP is IAKERB proxy. But it seems you are pursuing a different thing). It seems that the RP is acting as Kerberos client that uses a GSS-API based pre-authentication mechanism and the content of the gss-api token contains the gss-eap token provided by the user. Is that right? 

Best regards and thanks in advance.

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

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Sep 2011 11:38:57 -0400

>>>>> "Rafa" == Rafa Marin Lopez <[email-masked]> writes:

    Rafa> Hi Sam: Please see my comments/questions inline.

    Rafa> El 06/09/2011, a las 15:52, Sam Hartman escribió:

    >> 
    >> Hi.  At the mic in Quebec I raised the following issue about GSS
    >> preauth and ABFAB.
    >> 
    >> I want to be able to use GSS preauth between the RP and the KDC
    >> even if the initiator knows nothing about it.

    Rafa> Could you elaborate a little bit about the motivation related
    Rafa> to this and what is the associated issue?

Sure.
The idea is that you have some resource domain of servers.
You'd like to use GSS-EAP (ABFAB) to access them.
However  you want a central place to define policy, perform
authorizations, etc.
You've decided that Kerberos works well for that.
All authentications into the domain must go through the KDC. Only the
KDC can create authorizations.

You want the initiator to be able to take advantage of a TGT for fast
reauthentication within a domain if the initiator understands how.
However, you want to work with any initiator. So, depending on
gss-preauth-specific changes to the ininitiator isn't acceptable. In
particular you don't want to have to bypass the KDC for old initiators.
Services are not trusted to make authorization decisions.

    >> gss-preauth(gss-eap)) RP <->KDC When that happens:

    Rafa> Before going into detail I would like to understand this flow
    Rafa> (at first sight, it vaguely reminded me the use of IAKERB
    Rafa> where the RP is IAKERB proxy. But it seems you are pursuing a
    Rafa> different thing). It seems that the RP is acting as Kerberos
    Rafa> client that uses a GSS-API based pre-authentication mechanism
    Rafa> and the content of the gss-api token contains the gss-eap
    Rafa> token provided by the user. Is that right?

Your understanding is correct.

--Sam

---

From: Nico Williams <[email-masked]>
Date: Tue, 6 Sep 2011 17:36:41 -0500

Options to make this happen:

a) Make the GSS-EAP client aware of the AS exchange and give it the
bits it needs to recover the reply key and extract the credentials.
Now how to get a service ticket for the RP in a round-trip efficient
way?  Well, have the RP mint one and be done, say.  Or define a new
way to use a TGT as an additional ticket with which to get the desired
service ticket (sortof like reverse user-to-user).

b) Define a new AS-like exchange where the final reply in a successful
case contains a KRB-CRED, so that multiple tickets may be issued at
once, then apply the solution above this one.

c) Add some AS-REQ flags so that the AS-REP will contain an pre-auth
element that contains a KRB-CRED in it with the desired tickets.  In
this case the enc-part of the AS-REP will be useless and will be
thrown out.

d) Add some AS-REQ flags so that the AS-REP's pre-auth method data
will contain an embedded KRB-CRED (in the case of GSS pre-auth
probably using the Null enctype and embedded in a wrap token).

It all sounds rather messy to me.  Desirable, yes, but also messy.

(d) implies that the pre-auth plugin on the KDC must have access to
all details of the AS-REQ.  Probably not a big deal.  It also implies
that the pre-auth plugiin must have some way to get the desired
tickets minted, which sounds like a fairly major abstraction
violation, but one I could make peace with.

(a), (b), and (c) would make GSS-EAP as a protocol have too much
Kerberos knowledge for my comfort.

I think (d) is the best option, then.

The best part of this though is that it gives you a reason to want GSS
pre-auth ;)

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Sep 2011 19:19:17 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> Options to make this happen: a) Make the GSS-EAP client aware
    Nico> of the AS exchange and give it the bits it needs to recover
    Nico> the reply key and extract the credentials.  Now how to get a
    Nico> service ticket for the RP in a round-trip efficient way?
    Nico> Well, have the RP mint one and be done, say.  Or define a new
    Nico> way to use a TGT as an additional ticket with which to get the
    Nico> desired service ticket (sortof like reverse user-to-user).
I would prefer any Kerberos knowledge  to be optional in gss-eap so I
    Nico> don't like this.

    Nico> b) Define a new AS-like exchange where the final reply in a
    Nico> successful case contains a KRB-CRED, so that multiple tickets
    Nico> may be issued at once, then apply the solution above this one.
dito

    Nico> c) Add some AS-REQ flags so that the AS-REP will contain an
    Nico> pre-auth element that contains a KRB-CRED in it with the
    Nico> desired tickets.  In this case the enc-part of the AS-REP will
    Nico> be useless and will be thrown out.

    Nico> d) Add some AS-REQ flags so that the AS-REP's pre-auth method
    Nico> data will contain an embedded KRB-CRED (in the case of GSS
    Nico> pre-auth probably using the Null enctype and embedded in a
    Nico> wrap token).

I don't see the difference between C and D.

Also, this all seems like it focuses on the part of the problem where I
see lots of options rather than the part of the problem I don't know how
to deal with.
Namely, I don't understand how to make the key hierarchy work out right
across the gss-preauth boundary without either

1) building Kerberos knowledge into the initiator

2) having the acceptor gain the TGT key.

Obviously, since I'm willing to go to EAP preauth instead of gss
preauth, I'm OK building what amounts to EAP knowledge into the acceptor
and preauth method and playing with the reply key.
I'd like to find something cleaner.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 7 Sep 2011 17:30:45 +0200

Hi Sam:

Thanks for these clarifications. My comments inline again.

> reauthentication within a domain if the initiator understands how.

May we assume that TGT will be involved in a Kerberos exchange later on?. I mean I think that TGT will have to be provided to the initiator somehow ( within GSS-EAP exchange? )

I assume that initiator will have some Kerberos source code implemented to handle the TGT and to request service tickets. Otherwise, having a TGT is useless as you mention.

Thus I would assume that initiator has Kerberos source code implemented. is it so unreal that initiator would have a kerberos client?.  

Another question would be how the TGT will be used by the initiator and how everything will operate... where the keys will be distributed and how etc... 

> gss-preauth-specific changes to the ininitiator isn't acceptable.

Mmmmm this seems to contradict your sentence "You'd like to use GSS-EAP (ABFAB) to access them." no?. At least it is assumed that the initiator has to implement GSS-EAP. So "any" initiator would not work. 

Also, it would be interesting to know why it may not be acceptable. After all, we are doing changes to include new technology :).

> In

Well, if they are old initiators most probably they will implement legacy mechanisms for authenticating services (not even GSS-EAP except, perhaps, Kerberos GSS-API mechanism, for example). On the other hand, services will need to be updated to support this (so no support for old services).

Apart from this interesting scenario you mention, I would also like to suggest to analyze another possible case for fast re-authentication, when the initiator has to go through the RP. The idea is simple if we can assume GSS-API pre-authentication mechanism in the initiator and IAKERB. As evident, GSS-EAP would be a potential mechanism to perform the GSS-API pre-authentication as it has been already discussed. Then the initiator will have a TGT and can request service tickets.

Initiator (GSS-API pre-authentication mech + IAKERB) --- RP (IAKERB proxy) --- KDC (Acceptor)

Here, KDC is also the central point of authentication and authorization. Certainly the assumptions/requirements differ a little bit in both cases but they seem interesting.

In any case, I believe it would be good to have a clearer picture of the general goal (e.g. to achieve fast re-authentication in GSS-EAP or so...). Then define requirements for a potential solution and needs.

Best regards.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 7 Sep 2011 17:32:54 +0200

Hi Nico:

Are you suggesting the initiator sends the TGT and obtains several STs in return from the KDC in a single exchange?

Best regards.

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 Sep 2011 10:45:11 -0500

> I don't see the difference between C and D.

I do.

In (c) the RP has to collect the additional PA and bundle it in.  In
(d) the PA method at the KDC end-point takes care of that.  Less
abstraction violation in the RP -> better.

> 2) having the acceptor gain the TGT key.

The initiator MUST have a Kerberos client, else it MUST use a trusted
proxy wherever Kerberos is required.  I've no interest in building a
trusted proxy here.

So the question really is: what kind of violence to the initiator
might we accept?

Now, imagine for a second a variation on GSS_Init_sec_context()
specifically for IAKERB-like mechanisms that outputs...  a credential
handle, just like GSS_Accept_sec_context does...  The KRB-CRED
included in a wrap token embedded a GSS-EAP token from the acceptor
(really, the KDC), would be suitable for constructing such an output
credential handle.

The initator app would then GSS_Store_cred(), if it cares to.  Or,
when the app uses the original GSS_Init_sec_context(), the mechanism
or the mechglue could just do it for the app according to local
policy.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 Sep 2011 10:48:55 -0500

> Are you suggesting the initiator sends the TGT and obtains several STs in return from the KDC in a single exchange?

Yes.  It'd be a nice round-trip optimization, no?  A combination of AS
and TGS exchange.

Note that this does not prevent the AS and TGS from being logically
separated since the AS could act as a proxy for the client in talking
to the TGS.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Sep 2011 09:10:27 -0400

Rafa> Hi Sam: Thanks for these clarifications. My comments inline
    Rafa> again.

I don't think these are reasonable assumptions.  I think we can assume
that if a TGT is used, it is provided to the initiator. I'm fine if a
TGT is only provided when it is going to be used.  However, I want a
service ticket provided (with authorization data) to the RP even if the
initiator has never heard of Kerberos and has no Kerberos code at all
other than the RFC 3961 implementation inherent in gss-eap.

In response to Nico's question about trusted proxies. I don't think
there is much trust involved in allowing the RP to interact with a
service ticket.  In effect what I think we're building is a form of
protocol transition where rather than trusting the RP to assert that the
client is authenticating, we're providing a GSS-EAP exchange targeted at
the RP to a KDC.
To me, that level of trust (much less than protocol transition) is
highly desirable.

--Sam

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Sep 2011 10:45:58 -0500

Oh, your main concern is not protocol transition for the initiator
(though that'd be nice, no?) but protocol transition for the acceptor.
 But the acceptor doesn't need a TGT for this.  Just an INITIAL
service ticket will do (initial because, without a TGT for the user,
what else can the service do but use a pre-auth that somehow produces
an AP-REP with a reply key it can handle, with the KDC disallowing
access to anything other than a service ticket with the acceptor as
the target?).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Sep 2011 14:09:09 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> Oh, your main concern is not protocol transition for the
    Nico> initiator (though that'd be nice, no?) but protocol transition
    Nico> for the acceptor.  But the acceptor doesn't need a TGT for
    Nico> this.  Just an INITIAL service ticket will do (initial
    Nico> because, without a TGT for the user, what else can the service
    Nico> do but use a pre-auth that somehow produces an AP-REP with a
    Nico> reply key it can handle, with the KDC disallowing access to
    Nico> anything other than a service ticket with the acceptor as the
    Nico> target?).

Right.
The service doesn't need a TGT.

I was hoping for a mechanism such that

* a TGT is generated if the initiator can take it

* A service ticket is generated all the time

* The service never knows the TGT key

* The service always knows the context key

* The initiator need not know about the service ticket side of the
  business.

--Sam

---

From: Josh Howlett <[email-masked]>
Date: Fri, 9 Sep 2011 08:36:57 +0000

>* The initiator need not know about the service ticket side of the

Sam,

For the general case, what if:

1. The KDC supplies the context key to the RP within the protected
pre-auth exchange.

2. GSS mechanism specific methods are defined for returning a TGT from the
KDC to the initiator.

3. GSS mechanism specific methods are defined for deriving the TGT session
key.

In the particular case of GSS EAP:

  1: the context key is derived from the EAP MSK per the spec today. The
RP doesn't get to see the MSK.

  2: the GSS EAP mechanism already provides for subtokens; and we have
already implemented the case where a subtoken is a service ticket. Perhaps
the same model could be extended to other mechanisms?

  3: the KDC and initiator independently derive the TGT session key from
the EAP MSK. The RP doesn't get to see the MSK.

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 9 Sep 2011 12:54:40 +0200

Hi Sam: 
> I don't think these are reasonable assumptions.

Well, if we send a TGT or ST to the initiator, it would seem reasonable to me that initiator knows how to handle it. But maybe it is not reasonable. 

In any case, it seems you consider that TGT or ST are provided to the initiator as a opaque blob so that initiator will have to send later on (as an opaque blob) to the RP. is that right?.

>  I think we can assume
> that if a TGT is used, it is provided to the initiator.

I was wondering how is that TGT provided to the initiator (within a GSS-API token after a successful authentication?) and how the initiator sends it to the RP. 

> I'm fine if a

Yes, I understand that it is what you want. What I am trying to see how it could operate and the motivation.

Best regards.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 9 Sep 2011 13:25:41 +0200

Hi Nico:

> Yes.  It'd be a nice round-trip optimization, no?  A combination of AS

This is interesting since we already finished a work done by a student here that pursued a similar goal: obtain several service tickets in one round trip ;).

Best regards.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Sep 2011 08:58:34 -0400

Rafa> Hi Sam:
    >> 
    >> May we assume that TGT will be involved in a Kerberos exchange
    >> later on?. I mean I think that TGT will have to be provided to
    >> the initiator somehow ( within GSS-EAP exchange? )
    >> 
    >> I assume that initiator will have some Kerberos source code
    >> implemented to handle the TGT and to request service
    >> tickets. Otherwise, having a TGT is useless as you mention.
    >> 

    Rafa> Well, if we send a TGT or ST to the initiator, it would seem
    Rafa> reasonable to me that initiator knows how to handle it. But
    Rafa> maybe it is not reasonable.

I agree that if the initiator is going to use a TGT or ST then it's fine
to assume it has code to deal with one.  I think we may send a TGT or ST
to the initiator without being aware it can handle them; we could also
perform capability negotiation and confirm that the initiator can deal
with a TGT or ST before sending it. The capability option is desirable
if we want a different protocol.

In the case of the TGT there is no particular reason to generate a TGT
unless the initiator has Kerberos and can consume it.

In the case of the ST, it is often very useful to generate the ST and
hand the ST to the RP even if the initiator will never see the ST and
wouldn't know what to do with an ST if it had one.

Talking through this with Josh ye.yesterday I've realized I am making
lots of assumptions about model and use that I have documented no-where.
If you can wait a couple of days I'll write up my model and what I've
learned of the constraint space.

--Sam

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 12 Sep 2011 10:06:47 +0200

Hi Sam:

> if we want a different protocol.

That makes sense to me.

Right. 

> learned of the constraint space.

Yes, that would be really appreciated. Thanks.

Best regards.

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Sep 2011 09:50:19 -0500

> if we want a different protocol.

You could just send it, in a wrap token embedded in a GSS-EAP context
token.  If the client can't use it, it won't, and that's that.  Of
course, this is wasteful of resources, particularly if the client does
lots of GSS-EAP exchanges and doesn't grok Kerberos.  So, yeah, this
should be negotiated.

(Awful, ugly thought: one might also allow for credential delegation
whereby the acceptor gets a TGT and session key from the KDC through
which to impersonate the initiator.  How would the KDC learn that the
initiator is willing to delegate credentials thus?)

> wouldn't know what to do with an ST if it had one.

Why is this useful?  A service ticket delivers a few features: a) the
initiator principal's Kerberos principal name, b) any authz-data the
KDC might want to put in the ST (though presumably GSS-EAP could
deliver the same data as SAML, no?), c) the KDC signature on the ST,
which enables S4U*.  I think this is useful enough, but we should be
careful to not make a KDC infrastructure a requirement for using
GSS-EAP.

Nico
--