Subject: [abfab] gss-eap preauth as a protocol transition mechanism

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Nov 2011 15:53:42 -0500

[I think this is a Kerberos discussion mostly, but consider keeping
abfab in your reply if your discussion fits the abfab list.]

A month or so ago, I promised to write up a use case in response to an
abfab discussion having to do with obtaining a Kerberos ticket as a side
effect of a gss-eap preauthentication.

As background, Microsoft has a Kerberos mechanism called protocol
transition.  The idea is that a service authenticates someone using a
non-Kerberos means.  However, that service still wants to know what the
authorization characteristics of that user are.
In the Microsoft model, the KDC/directory are always responsible for
domain level authorization.
In order to obtain authorization information you need a security token;
to get one of those in a domain you generally need a Kerberos PAC.

There's a lot going for this model. It centralizes policy for the RP
organization in one place: the domain controller for the resource
domain.

We had several discussions at the MIT Kerberos Consortium's conference
last year about how valuable this is, and about how if we can maintain
this in the federated context, Kerberos could be an important policy
mechanism for the cloud.

I'd like Moonshot (the GSS-EAP implementation I'm working on) to be able
to support this model.

One thing we can do is just use protocol transition as it's specified in
Microsoft's extensions today.
You do a GSS-EAP authentication to the RP, the RP asks the KDC for a
ticket, life goes on.

The problem with this is that protocol transition is relatively weak
from a security standpoint. The service makes an assertion to the KDC
that authentication happened.
This can be a privacy exposure to a certain extent: the service needs to
be trusted to obtain authorization information for any user who might
authenticate to it regardless of whether they have. Microsoft has
accepted this; some environments may not.

Another problem is that the resource domain controller may not have the
information needed to construct authorization information in a GSS-EAP
federation. SAML or RADIUS or Diameter information may be
necessary. Now, the KDC could trust the service to disclose the
information, or could possibly rely on SAML signatures.

Trusting the service that much seems a big stretch.

Relying on SAMl signatures viloates the one-trust-infrastructure design
principle. In particular, it's generally a bad idea for a security
system to force deployers to set up more than one trust infrastructure
because those are very expensive. If we're using GSS-EAP we already have
AAA trust. We should use that.

so, somehow, we need to get the KDC as a trusted intermediary in the
GSS-EAP authentication.

Note that we don't want to depend on any particular initiator
functionality.  the RP needs to interact with the KDC for its own
purposes regardless of whether the initiator has ever heard of Kerberos.

I had originally thought about an EAP pre-authentication mechanism to
accomplish this goal.  The idea is that gss-eap would take EAP packets
out of its incoming tokens and send them to the KDC as part of a
fast-armored AS-request.  The client would be ambiguous--somehow
determined by preauth and the service would be the RP.  The service
would not learn the MSK, but could be told the GMSK (GSS-EAP key).

If I could figure out a way to do this with gss-preauth and gss-eap then
I'd support gss-preauth.

Conceptually, I guess what's going on here is that you want to export a
context from the KDC and import it on the RP.  However, we don't want to
expose the MSK to the RP so that if we are doing something that exposes
a TGT to the initiator we have a key to use.

So, this involves probably some changes to GSS-EAP and to the preauth
type.  GSS-EAP probably needs to gain a standardized exported context
and the GSS preauth needs to gain a way to transfer an exported context
token if the mechanism supports the appropriate attribute.
Or something like that.

I'd appreciate comments on this use case and once we understand the use
case I'd like to talk about mechanisms for getting there.

---

From: Nico Williams <[email-masked]>
Date: Wed, 9 Nov 2011 15:46:57 -0600

I agree that this is a desirable use case.

I think this can be generalized though, via an IAKERB-like GSS
mechanism.  Let me sketch it that way and then see if we can make
incremental changes to GSS-EAP instead of pursuing a generic solution.

What I have in mind is a pseudo-mechanism -- think of it as a
stackable pseudo-mechanism.  It needn't actually be that generic if
that's a problem for you.  The pseudo-mechanism would add a bit of
framing to the initiator's initial security context and channel
binding data by which to bear the name of the RP, while the inner
context tokens would be targeted at a different RP: the KDC in this
case.  Ah, but the initiator would have to learn the name of the inner
context's RP (the KDC, or rather, realm name), and this would either
require a host2realm facility like we have in most Kerberos clients,
or an extra round-trip (and trusting the RP); we wouldn't wan the
extra round-trip.  On the acceptor side all context tokens would be
proxied to the KDC over a tunnel authenticating the RP to the KDC, and
then the KDC would give the RP an exported security context token.

So that's the generic sketch.  A non-generic set of changes for
GSS-EAP would look the same, only without a different mechanism OID
and without the generic pseudo-mechanism in the way.

Note that you'll need the RP to be able to tell the KDC about the CB
data affix -the RP's name as seen by the initiator- or have the KDC
figure it out from the context (the armor key for the FAST tunnel).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Nov 2011 17:07:57 -0500

So, you presented an alternate proposal that violated one of my
constraints without describing what it offers that my proposal did not
offer.

In particular, you propose changing the initiator.  I don't like
changing the initiator to support this use case because it's possible
for an initiator to mis-implement the new functionality or if it is
optional to choose not to implement it at all.  Then you get initiators
that work against some environments but not against high-infrastructure
environments, which tend to be sensitive to working with as many
initiators as possible.

Also, I don't think the set of RP-side intermediates is the initiator's
business at all.  We don't tell the initiator what AAA proxies we use,
so why should the initiator be involved in this?

Finally, host-to-realm in clients has generally been regarded as a bad
idea in Kerberos.  If we had it to do over I would not support
host-to-realm functionality in the clients.  I don't support having that
functionality in clients in a new protocol.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 10 Nov 2011 10:49:39 +0100

> I'd like Moonshot (the GSS-EAP implementation I'm working on) to be able

Would be acceptable to support Kerberos on the client side?

If so, then I think this model (or a very similar one) could be 
supported by Moonshot by relying in IAKERB and 
draft-perez-abfab-eap-gss-preauth. The initiator (client) authenticates 
with the KDC by means of GSS-preauth + GSS-EAP. The transport of the 
Kerberos messages is done throught the RP, which at the end will obtain 
the ST with the corresponding authorization information. This way 
GSS-EAP is being used for federated authentication while the KDC is 
being used for local realm authorization.

> would not learn the MSK, but could be told the GMSK (GSS-EAP key).

What will be the RP from the point of view of the home AAA/IdP? It 
should be the original RP (the application), and not the KDC if you want 
to provide a full set of attributes and you want the IdP to be able to 
determine which privacy policies will be applicable to release them.

Best regards,
Alejandro

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Nov 2011 05:09:12 -0500

>>>>> "Alejandro" == Alejandro Perez Mendez <[email-masked]> writes:

    >> [I think this is a Kerberos discussion mostly, but consider
    >> keeping abfab in your reply if your discussion fits the abfab
    >> list.]
    >> 
    >> A month or so ago, I promised to write up a use case in response
    >> to an abfab discussion having to do with obtaining a Kerberos
    >> ticket as a side effect of a gss-eap preauthentication.
    >> 
    >> 
    >> transition.  The idea is that a service authenticates someone
    >> using a non-Kerberos means.  However, that service still wants to
    >> know what the authorization characteristics of that user are.  In
    >> the Microsoft model, the KDC/directory are always responsible for
    >> domain level authorization.  In order to obtain authorization
    >> information you need a security token; to get one of those in a
    >> domain you generally need a Kerberos PAC.
    >> 
    >> There's a lot going for this model. It centralizes policy for the
    >> RP organization in one place: the domain controller for the
    >> resource domain.
    >> 
    >> We had several discussions at the MIT Kerberos Consortium's
    >> conference last year about how valuable this is, and about how if
    >> we can maintain this in the federated context, Kerberos could be
    >> an important policy mechanism for the cloud.
    >> 
    >> I'd like Moonshot (the GSS-EAP implementation I'm working on) to
    >> be able to support this model.

    Alejandro> Would be acceptable to support Kerberos on the client
    Alejandro> side?

    Alejandro> If so, then I think this model (or a very similar one)
    Alejandro> could be supported by Moonshot by relying in IAKERB and
    Alejandro> draft-perez-abfab-eap-gss-preauth. The initiator (client)
    Alejandro> authenticates with the KDC by means of GSS-preauth +
    Alejandro> GSS-EAP. The transport of the Kerberos messages is done
    Alejandro> throught the RP, which at the end will obtain the ST with
    Alejandro> the corresponding authorization information. This way
    Alejandro> GSS-EAP is being used for federated authentication while
    Alejandro> the KDC is being used for local realm authorization.

No, not really.

I see lots of reasons why I don't think this works.
The biggest in my mind is that  the client behavior I'd recommend for
Kerberos is different than what I'd recommend for GSS-EAP.
Kerberos is something that clients tend to try and use whenever it is
available.
They assume it will fast-fail if it is the wrong option for a given
authentication.
That's not really true for something Federated.

Also, this needs to behavior that doesn't require client-side support so
that you can't end up with clients that don't support it.
It would be OK to add mandatory behavior to
draft-ietf-abfab-gss-eap. However  I definitely don't want to end up
with clients that don't support whatever we end up with here.

    Alejandro> What will be the RP from the point of view of the home
    Alejandro> AAA/IdP? It should be the original RP (the application),
    Alejandro> and not the KDC if you want to provide a full set of
    Alejandro> attributes and you want the IdP to be able to determine
    Alejandro> which privacy policies will be applicable to release
    Alejandro> them.

In my model the client thinks it is authenticating to the RP, so the
RP's information is in the acceptor name RADIUS attributes.  The KDC may
include other information, possibly convincing the IDP to release more
attributes to the KDC only some of which will be forwarded to this
RP. (Think constrained Kerberos delegation). Alternatively the IDP may
release only the attributes needed by this RP and the KDC may do
additional attribute queries as in your prototype.  From a deployment
standpoint I don't like that model because it is desirable to minimize
cases where a KDC calls out to another domain, but if you need that
level of privacy it is the right approach.

--Sam

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 10 Nov 2011 11:27:02 +0100

El 10/11/11 11:09, Sam Hartman escribió:
>>>>>> "Alejandro" == Alejandro Perez Mendez<[email-masked]>  writes:

I don't see why a user on possession of a valid ticket for the 
application's realm should not be use it to fast authenticate with it.
I agree a different situation would occur when the user does not have a 
TGT yet, but I don't really see a big difference between starting a 
Kerberos preauthentication (which will use GSS-EAP as mechanism) or a 
direct GSS-EAP authentication. In the usual Kerberos use case, the user 
has to "kinit" to obtain the TGT, and that process may imply several 
round trips as specified in RFC 6113.

> with clients that don't support whatever we end up with here.

I see your point, but anyway it does require the client to support 
GSS-EAP. Why not adding a Kerberos dependency for the support of the 
specific use case?

> level of privacy it is the right approach.

Ok, thanks for the clarification. I understand now. I thought that the 
KDC was including its own name in the Acceptor Name RADIUS attribute.

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Nov 2011 06:32:32 -0500

>> 
    >> No, not really.
    >> 
    >> I see lots of reasons why I don't think this works.  The biggest
    >> in my mind is that the client behavior I'd recommend for Kerberos
    >> is different than what I'd recommend for GSS-EAP.  Kerberos is
    >> something that clients tend to try and use whenever it is
    >> available.  They assume it will fast-fail if it is the wrong
    >> option for a given authentication.  That's not really true for
    >> something Federated.

    Alejandro> I don't see why a user on possession of a valid ticket
    Alejandro> for the application's realm should not be use it to fast
    Alejandro> authenticate with it.  

I want this, yes.  However for the fast reauthentication use case it's
reasonable to assume initiator support.

    Alejandro> I agree a different situation
    Alejandro> would occur when the user does not have a TGT yet, but I
    Alejandro> don't really see a big difference between starting a
    Alejandro> Kerberos preauthentication (which will use GSS-EAP as
    Alejandro> mechanism) or a direct GSS-EAP authentication. In the
    Alejandro> usual Kerberos use case, the user has to "kinit" to
    Alejandro> obtain the TGT, and that process may imply several round
    Alejandro> trips as specified in RFC 6113.

I'm not worried about the round trips when the authentication succeeds.
The issue is what should the client application logic.
There are a lot of applications (and this is encouraged) for Kerberos
where the application tries fairly hard to use Kerberos if Kerberos is
offered by the server.
The assumption is a coupling of realms; the people who you talk to who
offer Kerberos  are people you want to talk Kerberos to.
This affects retry behavior, affects whether you prompt users for
Kerberos passwords, etc.

This is an operational issue not directly a protocol issue.
It's a big deal though.

    >> 
    >> Also, this needs to behavior that doesn't require client-side
    >> support so that you can't end up with clients that don't support
    >> it.  It would be OK to add mandatory behavior to
    >> draft-ietf-abfab-gss-eap. However I definitely don't want to end
    >> up with clients that don't support whatever we end up with here.

    Alejandro> I see your point, but anyway it does require the client
    Alejandro> to support GSS-EAP. Why not adding a Kerberos dependency
    Alejandro> for the support of the specific use case?

The deployment motivations are wrong.
The RP is the one who has the deployment insentive  to share
infrastructure and better handle authorization
within the RP organization.
If making that work depends on something the client does, then it's a
lot harder to deploy because the client is not motivated to make
 internal RP matters easier.

So, the RP would either have to have a fallback for clients that don't
support the option or would end up just not using the option.

    >> 
    >> In my model the client thinks it is authenticating to the RP, so
    >> the RP's information is in the acceptor name RADIUS attributes.
    >> The KDC may include other information, possibly convincing the
    >> IDP to release more attributes to the KDC only some of which will
    >> be forwarded to this RP. (Think constrained Kerberos
    >> delegation). Alternatively the IDP may release only the
    >> attributes needed by this RP and the KDC may do additional
    >> attribute queries as in your prototype.  From a deployment
    >> standpoint I don't like that model because it is desirable to
    >> minimize cases where a KDC calls out to another domain, but if
    >> you need that level of privacy it is the right approach.

    Alejandro> Ok, thanks for the clarification. I understand now. I
    Alejandro> thought that the KDC was including its own name in the
    Alejandro> Acceptor Name RADIUS attribute.

If the KDC puts its own name in the acceptor name attribute, then the
channel binding will fail.

All this is possible for GSS-EAP, but it's starting to look kind of
complex in terms of generic gss-preauth:

1) We need the KDC to impersonate all RPs in its realm in terms of being
an acceptor for the GSS preauth mechanism.
Clearly possible for EAP but not say for a public-key mechanism.

2) We need standardized context tokens

3) We need keying such that there is some key only the KDC and client
know.

---

From: Josh Howlett <[email-masked]>
Date: Thu, 10 Nov 2011 12:19:41 +0000

>complex in terms of generic gss-preauth:

What are the practical benefits of a generic gss pre-auth mechanism when
Kerberos pre-auth itself provides an extensible framework? I can see that
there is value in the re-using deployed gss mechanisms if this avoids
having to create functionally-equivalent but redundant pre-auth mechanisms
in the case where an equivalent gss mechanism already exists, but are
there really so many of these that this is a compelling argument? It
sounds as though there is potentially a trade-off that we could make
between complexity and generality.

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: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 10 Nov 2011 13:34:14 +0100

> between complexity and generality.

Hi Josh,

on the first place, to make the KDC Moonshot-enabled you need it to 
support GSS preauth. You can consider the KDC as another RP withing a 
realm.
On the second place, the use of FAST to protect the transport may result 
redundant for many authentication mechanism (for example, EAP where no 
assumptions are made on the security of the transport layer), 
introducing unnecessary round trips and computational effort (FAST 
requires a DH to be performed).

Note that you can see GSS preauth as an alternative to FAST, not to the 
Kerberos preauth framework. The latter only defines the guidelines to 
define preuth mechanisms (which we have followed to define the GSS preauth).

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Nov 2011 08:18:59 -0500

Alejandro> El 10/11/11 13:19, Josh Howlett escribiÃ³:
    >>> All this is possible for GSS-EAP, but it's starting to look kind
    >>> of complex in terms of generic gss-preauth:
    >> What are the practical benefits of a generic gss pre-auth
    >> mechanism when Kerberos pre-auth itself provides an extensible
    >> framework? I can see that there is value in the re-using deployed
    >> gss mechanisms if this avoids having to create
    >> functionally-equivalent but redundant pre-auth mechanisms in the
    >> case where an equivalent gss mechanism already exists, but are
    >> there really so many of these that this is a compelling argument?
    >> It sounds as though there is potentially a trade-off that we
    >> could make between complexity and generality.

    Alejandro> Hi Josh,

    Alejandro> on the first place, to make the KDC Moonshot-enabled you
    Alejandro> need it to support GSS preauth. 

Or define an EAP preauthentication fast factor.

    Alejandro> You can consider the KDC
    Alejandro> as another RP withing a realm.  On the second place, the
    Alejandro> use of FAST to protect the transport may result redundant
    Alejandro> for many authentication mechanism (for example, EAP where
    Alejandro> no assumptions are made on the security of the transport
    Alejandro> layer), introducing unnecessary round trips and
    Alejandro> computational effort (FAST requires a DH to be
    Alejandro> performed).

FAST does not require a DH, especially if it is being used to secure
only the path between the RP and KDC.
Depending on how a client used it, FAST might require a DH if you run
the FAST tunnel  from the KDC back to the client.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 10 Nov 2011 15:27:53 +0100

> Or define an EAP preauthentication fast factor.

I guess you meant GSS-EAP preauthentication fast factor, right?

> the FAST tunnel  from the KDC back to the client.

But I was talking about using Moonshot as the authentication mechanism 
for the KDC (as we did in draft-perez-abfab-gss-eap-preauth), thus, you 
would need anonymous PKINIT to establish an ad-hoc securized channel 
between the user and the KDC.

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Nov 2011 09:47:13 -0500

>> Or define an EAP preauthentication fast factor.

    Alejandro> I guess you meant GSS-EAP preauthentication fast factor,
    Alejandro> right?

No.
Any preauth mechanism is a FAST factor.
So if there is a GSS preauth there is a GSS and thus GSS-EAP FAST
factor.

I mean go back to a model where it's EAP between the RP and KDC not GSS.

I've been thinking more about this.  It's obvious to me that we don't
want to use the same GSS-EAP context between the client and RP that we
do between the RP and KDC, even if we use the same EAP conversation.  My
rationale is a bit complicated. One of the big reasons is that the
question of which enctype to use, what GSS-EAP features to use etc
should depend on the RP capabilities not on the KDC capabilities.  Also,
(and perhaps this is what Nico's getting at) it simplifies GSS channel
binding between the client and RP.

This doesn't mean we can't use GSS-PREAUTH; it just means using
GSS-PREAUTH is kind of complicated.
So, like Josh, I'm beginning to ask what GSS buys us in
preauthentication?

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 10 Nov 2011 18:14:29 +0100

Hi Sam:

I have some comments below.

> You do a GSS-EAP authentication to the RP, the RP asks the KDC for a

What kind of ticket would the RP request? The ticket is for the RP right?. So some trust between the KDC and the RP is required.

> accepted this; some environments may not.

At first sight, the Microsoft's model sounds reasonable to me. The reason is that the RP belongs to the same domain as the resource controller. Unless you consider them in two different domains or there is an assumption where the RP might be attacked or may be impersonated in some easy way.

On the other hand, I was wondering why the RP is trusted to receive any information about the user even when a different party (home AAA server) tells the KDC that user is authenticated. The only thing I believe you avoid with this alternative way is that a RP out of control requests authorization information for non-present or non-authenticated users. Is that what you want to avoid?

> would not learn the MSK, but could be told the GMSK (GSS-EAP key).

Basically what it is described here is a protocol to transport EAP between the RP and the KDC. am I correct?. Moreover it seems that the KDC is acting as a AAA proxy where the transport between the RP and KDC is based on Kerberos.

Btw, who is the EAP authenticator here? Apparently, it is still the RP however the MSK does not arrive to the authenticator but to another entity different to the authenticator. AFAIK, RFC 5247 assumes that MSK will reach the authenticator.

> a TGT to the initiator we have a key to use.

Another possibility is that the key you do not want to export to RP is based on some key derived from the EMSK and allow the MSK to reach the RP.

> case I'd like to talk about mechanisms for getting there.

Under my point of view (maybe wrong) this imply the definition of a new backend protocol to transport EAP, despite in general we already have RADIUS and Diameter for that purpose.

-------------------------------------------------------
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: Rafa Marin Lopez <[email-masked]>
Date: Thu, 10 Nov 2011 18:15:19 +0100

Hi Sam:

Let me answer this one as well.

> I mean go back to a model where it's EAP between the RP and KDC not GSS.

So indeed we would be defining a new type of backend transport protocol for EAP based on Kerberos

> So, like Josh, I'm beginning to ask what GSS buys us in

Let me clarify one aspect about GSS-PREAUTH in Kerberos (http://tools.ietf.org/html/draft-perez-krb-wg-gss-preauth-00). The idea we had when designing GSS preauth in Kerberos is to provide a flexible pre-authentication mechanism for Kerberos based on the multiple mechanism that GSS-API could offer (in particular, the GSS-EAP mechanism can be used as we described in http://tools.ietf.org/html/draft-perez-abfab-eap-gss-preauth-00). In fact, this flexibility was one the advantages we mentioned with respect to the use of EAP packets directly as pre-authentication data in Kerberos, which, by the way, we also described some time ago (http://www.ietf.org/mail-archive/web/abfab/current/msg00040.html). 

Obviously, the goal of our work is to define a flexible pre-authentication mechanism for Kerberos, but not a transport for EAP in the backend side of the acceptor/authenticator. However, I understand that if the same concept might be used it would really nice but, as I said, goals are completely different under my point of view.

Best regards.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 14 Nov 2011 04:31:18 +0100

Speaking strictly as an individual...

> Relying on SAMl signatures viloates the one-trust-infrastructure
> design principle. In particular, it's generally a bad idea for a
> security system to force deployers to set up more than one trust
> infrastructure because those are very expensive. If we're using
> GSS-EAP we already have AAA trust. We should use that.

Not getting into any of the other points, arguably SAML trust infra-
structure is much more widely deployed than AAA infrastructure in the
environments where KDCs are widely deployed.

Also I've yet to see a practical example of the single trust-infra-
structure principle applied.

	Cheers Leif