Subject: [abfab] GSS-EAP: do we ned an identity request

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 09:56:22 -0400

[EMU copied for EAP input]

Here in ABFAB, we're designing a new EAP lower layer for applications to
use for authentication. We're using the GSS-API (RFC 2743) as our
application integration point.

Currently, our lower layer is kind of chatty. The peer sends a first
message that roughly says "Hi, I'd like to authenticate." Then the
authenticator sends an identity request EAP message. Then the peer sends
an identity response. Then the authenticator (probably after an AAA
interaction) respons with the first EAP method message.

As best we can tell that round trip is unneeded. We could instead
include an unsolicited identity response in our first message from the
peer to authenticator and get a request with an EAP method message from
the first message from the authenticator.

We can't see any down side of this. There seems to be nothing in the
identity request.  We already have another approach for "network
selection." If you want to know who your authenticator is in order to
decide on an identity, we have a lower-layer specific mechanism for
that.

I'd appreciate any comments. From ABFAB participants, do we want to make
this optimization? From EMU participants are we missing anything?

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 18 Oct 2011 16:51:31 +0200

Hi Sam:

> the first message from the authenticator.

According to RFC 3579 (section 2.1) that would be possible in certain cases:

"This is useful in cases where the identity is determined by
   another means (such as Called-Station-Id, Calling-Station-Id and/or
   Originating-Line-Info); where a single authentication method is
   required, which includes its own identity exchange; where identity
   hiding is desired, so that the identity is not requested until after
   a protected channel has been set up."

Alternatively, what I believe you can also do is to allow the peer send information (probably peer's identity) to the authenticator out of EAP (within GSS token). This information allows AAA client to reach the EAP/AAA server that handles the peer's credentials. Then the EAP/AAA server can start directly the preferred EAP method for that peer.

What I am trying to say corresponds with something similar to the first figure of section 2.2 in RFC 4072.

In RFC 3579 you can also find this text:

"Rather than sending an initial EAP-Request packet to the
   authenticating peer, on detecting the presence of the peer, the NAS
   MAY send an Access-Request packet to the RADIUS server containing an
   EAP-Message attribute signifying EAP-Start.  The RADIUS server will
   typically respond with an Access-Challenge containing EAP-Message
   attribute(s) encapsulating an EAP-Request/Identity (Type 1).
   However, an EAP-Request for an authentication method (Type 4 or
   greater) can also be sent by the server."

Between both choices, it seems that second one gives the EAP/AAA server the opportunity to start directly with the selected EAP method from a pool of them. First choice, always starts with a particular EAP method (implemented in the Acceptor) that it may not be supported by the (home) EAP/AAA server or not the preferred one by the server for that peer.

Hope this helps.

> _______________________________________________
> 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, 18 Oct 2011 11:35:41 -0400

I think I may have been unclear in what I was proposing.  I'm proposing
that the peer send its identity in the first message (*) and that the
server gets to respond with type 4 or greater (a specific EAP method).
I'm proposing dropping the identity request, not the identity response.

(*) There's a case where we ask the acceptor what its name is. In that
case I think it is desirable to let the peer wait to receive the
acceptor name before sending an identity.

In all these cases we support identity hiding.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 18 Oct 2011 18:20:16 +0200

Hi Sam:

> server gets to respond with type 4 or greater (a specific EAP method).

Sending its identity does not mean that it must be carried in the EAP response/identity. In fact what I suggested is to carry the identity in the first message but not contained in the EAP response/identity.

> I'm proposing dropping the identity request, not the identity response.

As I said in my previous e-mail, you can do that but it does not necessarily mean to transport the identity in an EAP response/identity.

According to the text I pasted in my previous e-mail (below), the peer can send its identity in the first message (but not contained in any EAP response/identity). Then the NAS sends that identity to the EAP/AAA server with an EAP-Message attribute (without EAP message) signifying EAP-Start. The RADIUS server then sends "an EAP-Request for an authentication method (Type 4 or greater)

This is what I proposed in my previous e-mail. Is it not similar to what you proposed?

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 12:55:23 -0400

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

    Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió:

    >> I think I may have been unclear in what I was proposing.  I'm
    >> proposing that the peer send its identity in the first message
    >> (*) and that the server gets to respond with type 4 or greater (a
    >> specific EAP method).

    Rafa> Sending its identity does not mean that it must be carried in
    Rafa> the EAP response/identity. In fact what I suggested is to
    Rafa> carry the identity in the first message but not contained in
    Rafa> the EAP response/identity.

OK. Why not carry it in the EAP response/identity?
It seems easier than developing new encoding.

However it's certainly easy enough to carry it elsewhere. So, if there
is a reason to do so I'm happy to invent our own subtoken for it.

do you support the general concept of an optimization here?

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 19 Oct 2011 00:06:38 +0200

Hi Sam:

> It seems easier than developing new encoding.

Basically EAP is a lock-step protocol where it is required to get a request to obtain a response (in the peer side)). So the EAP peer state machine implementing the EAP standard protocol will react after receiving an EAP request. So I see two options: either you hack the EAP peer state machine to return an EAP response/identity without receiving any EAP request/identity (this "violates" the standard and so we need to hack the EAP peer state machine) or directly at GSS-API level you create a EAP response/identity and include the identity (which seems weird taking into account that we have an EAP stack in charge of creating EAP messages)

Personally, I do not like either (considering the standard RFC 3748). So, I would prefer to define a subtoken for this.

> is a reason to do so I'm happy to invent our own subtoken for it.

Good.
> do you support the general concept of an optimization here?

Yes, I do. Certainly, we save two messages between initiator and acceptor. Nevertheless, I am not sure how it is the real reduction in time of this optimization in contrast with the fact that an EAP authentication may need to reach a home EAP/AAA server and may be involve several roundtrips to complete.

Best regards.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 18:23:48 -0400

Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió:
    >>>> (*) and that the server gets to respond with type 4 or greater
    >>>> (a specific EAP method).
    >> 
    >> 
    >> OK. Why not carry it in the EAP response/identity?  It seems
    >> easier than developing new encoding.

    Rafa> Basically EAP is a lock-step protocol where it is required to
    Rafa> get a request to obtain a response (in the peer side)). So the
    Rafa> EAP peer state machine implementing the EAP standard protocol
    Rafa> will react after receiving an EAP request. So I see two
    Rafa> options: either you hack the EAP peer state machine to return
    Rafa> an EAP response/identity without receiving any EAP
    Rafa> request/identity (this "violates" the standard and so we need
    Rafa> to hack the EAP peer state machine) 

Or the initiator synthesizes a request and feeds it to the peer's state
machine.

IN our implementation, even if the IETF decides on an an alternate
encoding for the identity, we'll end up synthesizing an identity request
and doing something with the identity response.

With a standard EAP library that is lock-step in the manner you
describe, it's far easier to produce a synthetic identity request in the
initiator than to hack the state machine or do anything else.  Think of
it this way. In GSS-EAP, the identity request is generated by a party
very close to the initiator.  EAP already supports the identity request
being generated by a different party than the actual EAP messages. Why
does it matter whether the request comes from inside the peer or from a
NAS?

    Rafa> or directly at GSS-API
    Rafa> level you create a EAP response/identity and include the
    Rafa> identity (which seems weird taking into account that we have
    Rafa> an EAP stack in charge of creating EAP messages)

But if you don't create an EAP response/identity on the initiator you
probably do have to do it on the acceptor to trigger AAA to use EAP.

    Rafa> Personally, I do not like either (considering the standard RFC
    Rafa> 3748). So, I would prefer to define a subtoken for this.

We can do that. It means faking up an identity response on the
acceptor. But that is certainly not a big deal.

--Sam

---

From: Luke Howard <[email-masked]>
Date: Wed, 19 Oct 2011 10:15:13 +1100

> initiator than to hack the state machine or do anything else.  Think of

Right, I actually tried to hack the state machine as described in a very early iteration and, with the library we used, it just didn't work.

-- Luke

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 19 Oct 2011 11:28:00 +0200

Hi Sam:

> Or the initiator synthesizes a request and feeds it to the peer's state

Yes, this is another option, though I don't like either. The reason is simple. AFAIK, the standard EAP does not say anything about a EAP lower-layer synthesizing a request (which sounds like another type of hack). EAP requests are sent by the authenticator. This is what the standard says.

> initiator than to hack the state machine or do anything else.  

As I said synthesizing an EAP request is another type of hack, because the EAP protocol does not work like that. We have a RFC 3748 and RFC 5247 where the EAP protocol is defined. I believe it would be good if we follow the standards.

> Think of

Regarding this, you need to think about the mode independence property of EAP where:

"As far as the EAP peer is concerned, its conversation with the EAP authenticator, and all 
consequences of that conversation, are identical, regardless of the authenticator mode of operation."

In other words, under peer standpoint, all EAP requests are coming from the EAP authenticator (the peer does not know and do not care if there is a backend EAP server or it is integrated with the authenticator). 

> probably do have to do it on the acceptor to trigger AAA to use EAP.

I don't think you need to do that. As I explained in the previous e-mail, in RADIUS EAP (RFC 3579) you can find this text:

   greater) can also be sent by the server.

   EAP-Start is indicated by sending an EAP-Message attribute with a
   length of 2 (no data)."

In other words, once the acceptor knows the peer's identity can send that EAP-start message in a RADIUS Access-Challenge. Moreover it should include the user-name in the request. With that, the RADIUS EAP server should start the EAP method selected for that peer.

> acceptor. But that is certainly not a big deal.

As explained, you do not need to fake up any identity response on the acceptor. Just follow what RFC 3579 says.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 19 Oct 2011 11:45:07 +0200

Please replace RADIUS Access-Challenge by RADIUS Access-Request in the sentence of my previous e-mail

"In other words, once the acceptor knows the peer's identity can send that EAP-start message in a RADIUS Access-Challenge..."

Best regards.

---

From: Luke Howard <[email-masked]>
Date: Wed, 19 Oct 2011 22:45:35 +1100

Also, this is probably neither here nor there, but NegoEx provides for server-initiated context establishment (i.e. the first token is emitted by the acceptor). I seem to have lost the reference to this, although NegoEx is otherwise specified in draft-zhu-negoex-04.

-- Luke

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 19 Oct 2011 14:34:05 +0200

Hi again:

I have been thinking again about the situation created with sending an EAP response/id without the authenticator sending EAP request/id and I realized that it may be even worse in the authenticator side. Basically, the authenticator will see an EAP response message which does not answer to any EAP request sent. 

Best regards.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Oct 2011 11:21:30 -0400

Rafa> Hi again: I have been thinking again about the situation
    Rafa> created with sending an EAP response/id without the
    Rafa> authenticator sending EAP request/id and I realized that it
    Rafa> may be even worse in the authenticator side. Basically, the
    Rafa> authenticator will see an EAP response message which does not
    Rafa> answer to any EAP request sent.

OK. point taken.
I've been steadily leaning towards subtoken, but I think the above
argument is convincing enough to push me firmly into the subtoken camp.

Thanks for walking through this with me!

So, I formally propose that we require initiators to send an identity
subtoken either in their first token or in the response to the acceptor
name.

Can I get comments on this?

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 19 Oct 2011 17:54:08 +0200

Hi Sam:

> argument is convincing enough to push me firmly into the subtoken camp.

Definitely, designing a subtoken seems the most standard way of defining this optimization. Nevertheless, we may need to think about something I just realized. It may happen that when the acceptor sends the EAP-Start in the RADIUS Access-Request that the RADIUS EAP/AAA server decides to start the EAP request/identity instead the first EAP request of the chosen EAP method. The reason is the text about that RFC 3579 I pasted in my previous e-mail where it is said:

"The RADIUS server will

It means that RADIUS EAP/AAA server implementation is not obligated (there is no MUST in the text) to start an EAP method instead of sending an EAP request/identity. This means that RADIUS EAP/AAA should be correctly configured to allow this optimization. Otherwise, the RADIUS EAP/AAA server will send the EAP request/identity that has to travel all the way to the authenticator. 

Although the solution does not violate any standard, in certain cases it may not help to achieve the optimization if the home EAP/AAA is not configured to select directly the EAP method for that peer. Even I would say that it is more problematic than sending the EAP request/identity from the authenticator (The EAP request/identity sent from the home EAP/AAA will add more latency and the same number of messages than the current not optimized case).

So the question would be : can we be sure that all home EAP/AAA servers will act to allow the optimization?

> Thanks for walking through this with me!

Thank you. These conversations are always interesting and I am willing to participate as far as I can.