Subject: [HOKEY] question about erx-08

From: Stefan Winter <[email-masked]>
Date: Mon, 14 Jan 2008 16:06:46 +0100

Hello,

I'm new to this list, apologies if my question has already been answered.

Draft erx-08 states that

It is plausible that the authenticator does not know
   whether the peer supports ERP and whether it has performed a full EAP
   authentication through another authenticator and hence the
   authenticator initiation of the ERP exchange may require the
   authenticator to send both the EAP-Request/Identity and EAP-Initiate/
   Re-auth-Start messages.

And the ASCII-art shows

        Peer               Authenticator                   Server
        ====               =============                   ======

    [<-- EAP-Request/ ------
        Identity]
    [<-- EAP Initiate/ ------
        Reauth-Start]

    ---- EAP Initiate/ ----> ----EAP Initiate/ ---------->
          Re-auth/                  Re-auth/
         [Bootstrap]              [Bootstrap]

However, RFC3748 (EAP) states in section 4.1 (Request and Response

"Requests MUST be processed in the order that they are received, and MUST be 
processed to their completion before inspecting the next Request."

It is clear that EAP-Request != EAP-Initiate, so the two can co-exist in 
parallel. But the wording in 3748 seems to imply that the peer is forced to 
process and respond to EAP-Request when it receives one, which essentially 
means it is forced to reply with EAP-Response/Identity and thus trigger a 
full-fledged EAP authentication. This is not what erx-08 envisages, though, I 
guess.
At least a note should be added that the peer is supposed to drop the 
EAP-Request/Identity silently iff 
- it is already authenticated
- gets a an EAP-Initiate "shortly afterwards"

this sounds rather unclean though.

Greetings,

Stefan Winter

-- 
Stefan WINTER

Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [email-masked]     Tel.:     +352 424409-1
http://www.restena.lu                Fax:      +352 422473
_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 16 Jan 2008 11:42:54 -0800

> I'm new to this list, apologies if my question has already been answered.

No worries, thanks for your review.  I appreciate it very much.

>         Peer               Authenticator                   Server

Ok, I will make a note and try to incorporate such a clarification in 
the next revision (waiting for AD review at the moment).

> this sounds rather unclean though.

It was the result of a long debate, involved some compromises related to 
backward compatibility considerations.  If you have ideas on making it 
cleaner, please do share them.  (No, that is not an invite to redesign :) ).

thanks,
Lakshminath

> 
> Greetings,
> 
> Stefan Winter
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: Stefan Winter <[email-masked]>
Date: Wed, 30 Jan 2008 16:00:40 +0100

Hi,

> cleaner, please do share them.  (No, that is not an invite to redesign :)

From a conceptual point of view, it is none of the authenticator's business 
whether the EAP peer is trying for the first time (auth) or the n-th time 
(reauth). It basically just sees a new client coming in and needs an 
assessment about its eligibility for the network.
So, separating two messages for auth and reauth respectively appears wrong to 
me. Backwards compatibility doesn't really count, because in the draft's 
model, NASes need to be upgraded to do ERX. Clients will either do auth (if 
not upgraded to understand EAP-Initiate) or need to be upgraded to do reauth.

Another recent proposal suggested to simply use an identity suffix like 
@reauth for the same job and put it into EAP-Response/Identity. From a 
superficial glance, that wouldn't hurt in backwards compatibility: NASes need 
to be upgraded to understand the suffix and do ERX (i.e. send it to a 
separate ERX server) *but* even if not upgraded, they will in any case send 
the request to their default AAA server, so no hurt. Clients will just get a 
Request/Identity and can choose to either do a full auth (non-upgraded 
clients) or use the special syntax for reauth (upgraded clients). This 
approach would have the big plus that EAP wouldn't need to be modified and 
would save us from that unlucky formulation I was talking about in my intial 
mail.

I wonder if this qualifies as re-design :-/ If this was already discussed 
earlier and dismissed, just say so, I'll happily shut up :-)

Greetings,

Stefan

-- 
Stefan WINTER

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 30 Jan 2008 11:35:41 -0800

Hi Stefan,

Thanks for your notes.  I am not sure if you had a chance to read the 
archives, but we had these debates before and what we have is a 
compromise proposal.  Without going into details, the current consensus 
(documented in the ERX I-D) was arrived at after considering the things 
you want to preserve and other things too.  For instance, one of the 
issues that came up was about how the client would know that the NAS 
supports ERX or not.  My original answer was that it can be done at the 
lower layer, but that was not the consensus opinion and so we have a 
mechanism now in the draft.

Finally, I am not saying anything was dismissed; all considerations were 
taken into account and we came up with the compromise design.  It was 
very much a WG effort as one would expect.  Please see the 
acknowledgments section for attributions to specific ideas.  We need to 
add some more there (some additional ideas have come up recently).

regards,
Lakshminath