Subject: [Ietf-krb-wg] Summary: GSS Preauthentication

From: Sam Hartman <[email-masked]>
Date: Fri, 13 May 2011 13:20:21 -0400

People may have noticed a few messages surrounding a new GSS
preauthentication draft from Alejandro Perez-Mendez and Rafa
Marin-Lopez.  I think the discussion was spirited enough that it would
be useful to the WG to prepare a summary.  I've done so and would
appreciate comments from those more involved on whether I got the major
points.

The current status of the draft is that the authors are seeking
comments.  They seem to have been successful in that desire. This is
something we could adopt under the new or existing charter, but we have
not received a request to do so. The authors would be interested in
pursuing the draft if we did choose to adopt.

The basic idea of the mechanism is to provide GSS preauthentication to
use some other mechanism to authenticate a user. One mechanism that this
has been used with is the GSS EAP mechanism being standardized in ABFAB.

One issue surrounds the state requirements. Currently, GSS contexts need
to be initiated and accepted with a single process on the other
side. However, Kerberos KDCs are stateless. We have evaluated this
multiple times both in the context of RFC 6113 and in the OTP
draft. Larry expressed a strong desire for KDC implementations not to
maintain state. I don't know his exact reasoning, but I suspect it
involved the KDC being critical to an organization's authentication and
wanting to avoid a need to build up state. You can avoid significant
classes of attack if state is not required. We could revisit that
decision, but it seems like it would be a fairly high bar to do so.

Nico claimed that we could export the state and move it between KDCs.  I
think it was Greg who pointed out some general flaws in this approach
surrounding replays. Nico, myself and several others started thinking
about the question of state export. The conclusion seems to be that Nico
argues that if you limit the validity of a context, replays are not a
significant issue for Kerberos under reasonable assumptions. However
this seems like an area that would require more thought if we were able
to standardize.

State export may not be the only option. It is also possible to treat a
realm as a cluster and to have some backend communication channel to get
the GSS token to the right place.

Martin pointed out that GSS-API does not currently support export of
partial contexts. He pointed out that would require changes to the
semantics of a number of APIs. Also it might not be possible for all
mechanisms or all mechanism implementations to support state export. One
class of implementations that might have problems involve hardware
security modules. Nico pointed out that there are a number of
deployments involving hardware modules where this is not an issue.  Any
standardization of partial context export would presumably happen in
kitten.

There was discussion of whether this needed to be a FAST factor and how
it interacted with the preauthentication framework. I did not follow
that closely enough to summarize.

I don't know if this was pointed out on-list, but it came up in a number
of side discussions.  Many of the mechanisms like EAP, OTP, etc that
would be most concerning from a state management issue already have
solutions. EAP is funneled back to an AAA server. OTP solutions
typically have a central server (possibly distributed) that manages the
state. For these mechanisms export of the state might be fairly easy.

I'd appreciate any major points that I missed. There were a number of
messages and there was a lot flying back and forth.

Sam Hartman
Kerberos co-chair
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 17 May 2011 13:01:51 +0200

Dear Sam, all

thanks for this summary. I really believe you got the major points. But we would like to point out a few aspects below.

> appreciate comments from those more involved on whether I got the major

We would also like to acknowledge the other co-authors (Gabriel López Millán and Fernando Pereñiguez).

> pursuing the draft if we did choose to adopt.

We really appreciate the comments and interest received by the participants of Kerberos WG. Thank you very much.

> decision, but it seems like it would be a fairly high bar to do so.

While we completely understand that maybe we have arrived late to the reasons behind making the Kerberos pre-authentication
stateless at KDC side, we would really appreciate if Larry (or any other) could summary the reason/s about it. It would really fruitful for us (maybe a link to the e-mails where it was discussed would be more than enough)

In any case, it is worth noting that the state that KDC has to keep is very limited in time. The reason is that once the KDC ends the pre-authentication and delivers the TGT that state may be removed right away. In fact, as far as we know, Kerberos is considered stateless because between the exchanges KRB_AS_REQ/KRB_AS_REP; KRB_TGS_REQ/KRB_TGS_REP and KRB_AP_REQ/KRB_AP_REP there is no state kept by the KDC. That would happen somehow here.

> the GSS token to the right place.

Regarding this option, we also thought about the possibility that the GSS mechanism could store the state in a distributed database shared by all KDCs in a realm (after all, those KDCs share the same information like TGS key), which seems something similar to your comment here. That would make also sense.

> state. For these mechanisms export of the state might be fairly easy.

Regarding EAP state, Alex and I sent a couple e-mails that apparently did not reach the mailing list. But basically what we said is that the acceptor must perform the EAP Full Authenticator State Machine  (see fig. 6-7 page 30-31 in RFC 4137). So that, we should also export it. But not only that, also the state of the radius client (or Diameter client). All that state should be handled to the client and reconstructed in the new KDC. We are not completely sure how it would work and how difficult the implementation would be, but it does not sound very straight at first sight. In fact, we really wondered about whether, under implementation point of view, it would be easier or not than keeping a state only during the authentication KRB_AS_REQ...KRB_AS_REP and removing right away (and keeping the client contacting the same KDC). This implementation aspect was also commented.

Best regards.

> messages and there was a lot flying back and forth.

-------------------------------------------------------
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: Nico Williams <[email-masked]>
Date: Tue, 17 May 2011 10:57:39 -0500

> stateless at KDC side, we would really appreciate if Larry (or any other) could summary the reason/s about it. It would really fruitful for us (maybe a link to the e-mails where it was discussed wo…

I can't speak for Larry, but I believe there's a number of reasons to
want the KDC to be stateless:

 - client implementations that are deployed may well already assume
statelessness, and making them assume otherwise might be a fairly
intrusive change
 - managing state on the KDC is annoying for the implementor (e.g.,
the KDC would have to implement expiration of old, abandoned state)

Unfortunately I didn't take notes the last time that the full
motivation for KDC statelessness was explained to me.

> In any case, it is worth noting that the state that KDC has to keep is very limited in time. The reason is that once the KDC ends the pre-authentication and delivers the TGT that state may be remov…

Only the KDC exchanges require server-side statelessness.  The AP
exchange, unlike the KDC exchanges, is always one round-trip, so
there's no question of server-side state, except that typical
applications that use AP exchanges also want to use KRB-SAFE/KRB-PRIV
messages afterwards, which requires server-side state (this could be
made stateless in the same way that we've been discussing, but you'd
lose replay protection, and most applications do require replay
protection -- the KDC is special in that regard).

BTW, the TLS extension clearly requires KDC-side state.  I don't know
whether Microsoft is interested in implementing the TLS extension, but
certainly nothing is blocking the TLS extension.  You could use the
TLS extension as a design pattern:

 - begin with a TCP connection, do a GSS-API context token exchange,
 - _then_ do an AS exchange with a PA type that says "use the GSS
"tunnel"'s authentication to authenticate the cname/crealm and use a
key derived from GSS_Pseudo_random() as the reply key".

This approach would work, it wouldn't require statelessness, and it'd
require a single AS round-trip.  You'd lose the ability to optimize
away a round-trip, but you'd gain privacy protection for the AS-REQ
body -- a fair trade-off, IMO.  And on the KDC side, the state keeping
and cleanup can be common to both, this and the TLS extension (because
in both cases the state would be tied to TCP connections, which could
be closed based on idle time).

> Regarding this option, we also thought about the possibility that the GSS mechanism could store the state in a distributed database shared by all KDCs in a realm (after all, those KDCs share the sa…

That's much harder to implement though, particularly in a way that is
robust in the face of KDC failures.  (Well, maybe you could use
memcache as a way to tie things together robustly and easily.)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 17 May 2011 12:29:36 -0500

> want the KDC to be stateless:

Another reason for wanting statelessness is that statefulness might be
particularly bothersome for KDC implementors in the case of UDP.

With a stateless KDC it'd be possible to start the KDC processes on
demand via inetd, but then there'd be no way to guarantee that one KDC
process will handle all UDP messages from some client for a given
multiple round-trip AS exchange.  The same applies to a multi-process
implementation of the KDC.  This one would be my preferred reason to
be against KDC-side state.

Now, if the pre-auth method is implemented in such a manner that the
KDC process can come and go but the method preserves state, well,
that's a little better.  The method could use IPC to a service to do
the GSS work.  This approach only has the problem that the client
library has to know to come back to the same KDC -- this might be
tolerable.

Note that Simon's extension for using TLS in KDC exchanges is
stateful, but the state is a) in a separate layer, b) tied to TCP.
This approach to state keeping is OK with me.

Also, I like the idea of using the GSS-API in as traditional a way as
possible (and here I trust Martin will completely agree with me,
because, really, I'm agreeing with him).

So that's my proposal for GSS pre-auth: make it be like Simon's TLS
KDC extension, use it over TCP, and have a one round-trip AS exchange
using a trivial pre-auth method to indicate that the GSS initiator
principal authentication authenticates the Kerberos client principal
and that the reply key should be either constant (NULL enctype)

Nico

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 18 May 2011 13:35:09 +0200

Hi Nico, 

> library has to know to come back to the same KDC -- this might be

Somehow this is the idea we have in mind. Basically, the KDC calls the GSS-API. For us, GSS-API is an API :),  which can handle its internal state as it wants. That state may be potentially externalized (we know that is not implemented like that though). Thus, the KDC implementation does not handle any state but the GSS-API does. And that is why we used the PA_FX_COOKIE.

That is why for us, in the end, the KDC is stateless in the sense that the state is handled by the GSS-API. How the GSS-API handles the internal state should be irrelevant for the KDC. That is the concept of an API after all :).

In other words, under a design point of view (not implementation point of view), that is feasible for us.   

> because, really, I'm agreeing with him).

For us, using GSS-API as already defined sounds more than reasonable.

> and that the reply key should be either constant (NULL enctype)

Could you elaborate a little bit more here?

In any case, if I understand correctly, with this solution we are not talking about GSS pre-authentication for Kerberos in this case. The reason is that there is a pre-authentication framework based on PA-DATAS and we would like to use that framework. GSS-API provides tokens for authentication information that should be able to be transported as part of those PA-DATAS.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 18 May 2011 18:12:09 +0200

Hi Nico,

> statelessness, and making them assume otherwise might be a fairly

Yes, however no client implementation has GSS pre-authentication yet, which should be implemented and supported by the clients after all

> the KDC would have to implement expiration of old, abandoned state)

That happens under the assumption that the GSS-API will not do that. But under a design point of view, KDC should not keep or be aware of that state.

> motivation for KDC statelessness was explained to me.

Certainly, that discussion could be really useful here.

> protection -- the KDC is special in that regard).

I was not referring to this. What I am saying is that originally (AFAIK) Kerberos is considered stateless because when the KDC sends a KRB_AS_REP with the TGT, it does not have to store any state until it receives a KRB_TGS_REQ. Moreover, the explanation given in RFC 6113 about the need of KDC stateless is next:

"Kerberos KDCs are stateless in that there is no requirement that clients will choose the same KDC for the second request in a conversation. Proxies or other intermediate nodes may also influence KDC selection."

If my interpretation of this particular sentence is correct (please let me know if I am wrong) is that the KDCs are stateless as a consequence that clients may choose a different KDC in the next request. And it seems no other reason is provided. In other words, if the clients had a way to contact the same KDC, there would not be a need to make the KDC stateless (according to the paragraph in RFC 6113.)

> be closed based on idle time).

Please see my answer in the other e-mail I sent.

> memcache as a way to tie things together robustly and easily.)

Exactly, memcache-alike solution is what I think Sam referred here.

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 May 2011 11:13:09 -0500

> In other words, under a design point of view (not implementation point of view), that is feasible for us.

I agree it's feasible.

Existing GSS-API implementations don't have the semantics you need,
but you could easily build a user-land version of the kernel-land
GSS-API library (on Solaris, Linux) that uses IPC to talk to a "gssd"
daemon that actually holds the GSS-API credentials and security
context handles.

The only question is: are client implementors OK with pre-auth methods
that require all round-trips be done against the same KDC?

> For us, using GSS-API as already defined sounds more than reasonable.

It's close, as defined.  As implemented, not so much (but this is easy
to address as described above).

> In any case, if I understand correctly, with this solution we are not talking about GSS pre-authentication for Kerberos in this case. The reason is that there is a pre-authentication framework base…

There would still be a "GSS PA-DATA", but it'd be like "SASL
EXTERNAL": it would say to take authentication from the "external"
channel, namely, the GSS security context protecting this connection.

Nico

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 May 2011 11:31:31 -0500

Incidentally, the best reason for wanting to do KDC-over-GSS-over-TCP
is this: you get to automatically protect all traditionally
unauthenticated plaintext in KDC messages, including KRB-ERROR, plus
you also get to provide confidentiality protection for them.

The fact that KDC-over-GSS-over-TCP would be no more controversial
than Simon's StartTLS is a big bonus.

Nico

---

From: Luke Howard <[email-masked]>
Date: Thu, 19 May 2011 11:57:55 +0200

> Regarding EAP state, Alex and I sent a couple e-mails that apparently did not reach the mailing list. But basically what we said is that the acceptor must perform the EAP Full Authenticator State Machine  (see fig. 6-7 page 30-31 in RFC 4137). So that, we should also export it. But not only that, also the state of the radius client (or Diameter client). All that state should be handled to the client and reconstructed in the new KDC. We are not 

First, were you actually considering implementing the GSS EAP mechanism with the EAP Full Authenticator State Machine? I was presuming (at least we did in the Moonshot implementation) that pass-through mode would be sufficient.

In any case, at the GSS layer this is opaque.

-- Luke

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 19 May 2011 12:37:19 +0200

Hi Luke,

the EAP full authenticator state machine includes the pass-through part (please see figures 6-7 in page 30-31 in RFC 4137). There is not just only EAP pass-through authenticator state machine in RFC 4137. In RFC 4137 you can find EAP standalone authenticator state machine (Fig. 4) that does not support pass-through,  and the EAP full authenticator machine (Fig.6-7) that supports the pass-through mode.

Regarding implementation, generally speaking it is possible a GSS-EAP where there is no need to contact a AAA infrastructure (standalone EAP authenticator). I know that is not the general assumption but it is technically possible.

Btw, what do you mean with it is opaque at GSS layer? I guess you are referring to the EAP mode independence feature no?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 May 2011 07:52:21 -0400

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

    Rafa> Hi Luke, the EAP full authenticator state machine includes the
    Rafa> pass-through part (please see figures 6-7 in page 30-31 in RFC
    Rafa> 4137). There is not just only EAP pass-through authenticator
    Rafa> state machine in RFC 4137. In RFC 4137 you can find EAP
    Rafa> standalone authenticator state machine (Fig. 4) that does not
    Rafa> support pass-through, and the EAP full authenticator machine
    Rafa> (Fig.6-7) that supports the pass-through mode.

Right.  But why do you have to implement that?  First, RFC 4137 seems to
be informational. So, I don't think it is normative.  Secondly, it
doesn't seem to apply at all to an implementation that is only a
pass-through.  So, I'm not sure I understand why an implementation would
be forced to implement all of figure 6-7.

I agree you could implement all of figure 6-7 if you want to.  I agree
if you do that, you'll have more state.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Luke Howard <[email-masked]>
Date: Thu, 19 May 2011 14:01:50 +0200

> Btw, what do you mean with it is opaque at GSS layer? I guess you are referring to the EAP mode independence feature no?

If the state on an partially established context is exposed by gss_export_sec_context(), it's opaque to the caller which EAP state model is being used. Am I getting off-track here...

-- Luke

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 19 May 2011 18:25:31 +0200

Hi Sam,

El 19/05/2011, a las 13:52, Sam Hartman escribió:

> be informational. So, I don't think it is normative.

Basically I was just referring to RFC 4137 in order to show what I had in mind. In other words, I am not saying that it must be implemented as RFC 4137 says :),  but the EAP authenticator state machine implementations I know are implemented following as reference RFC 4137.

>  Secondly, it

Some states of figure 6 of the EAP full authenticator state machine ("part 1") handles the case where the EAP authenticator sends the EAP request identity even when the EAP authenticator is in pass-through mode. If the implementation does not consider that case where the EAP authenticator sends the EAP request Id, then you may skip the whole figure 6. But it implies a model where the AAA client must notify first at AAA level to the AAA/EAP server, which will send the first EAP request. An example of this model is in section 2.2 (first figure) of RFC 4072.   

> if you do that, you'll have more state.

Not only that, I think the AAA (radius or diameter) client state may require some consideration in the pass-through mode as well. 

Btw, maybe this could be also an interesting discussion in ABFAB.

Best regards.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 19 May 2011 18:36:02 +0200

Hi Luke,

> If the state on an partially established context is exposed by gss_export_sec_context(), it's opaque to the caller which EAP state model is being used. Am I getting off-track here...

Ah. That's for sure, the caller must be agnostic of that state model. But I believe the discussion was if this state will be simple, short and easily reconstructed/handled in another point... (apart from the fact that current GSS-API does not support that partial security context exportation, as far as I have learned during these discussions).

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 19 May 2011 19:16:42 +0200

Hi Nico,

>> In other words, under a design point of view (not implementation point of view), that is feasible for us.

Good.

> that require all round-trips be done against the same KDC?

Following this idea, we believe it is technically possible to allow the client to contact a different KDC, so that it would be possible to avoid any change in the current clients' behavior.   

> channel, namely, the GSS security context protecting this connection.

I understand now. I believe that is also possible.