Subject: [Emu] Tweaking EAP (RFC 3748)

From: Alper Yegin <[email-masked]>
Date: Mon, 22 Oct 2012 13:06:40 +0300

On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote:

>>>>>> "Alper" == Alper Yegin <[email-masked]> writes:
> 
>    Alper> Hi Sam, Please also share this discussion with EAP WG and EMU
>    Alper> WG mailing lists. That's where the EAP expertise is and they
>    Alper> should chime in, given that you are proposing to modify EAP
>    Alper> applicability statement.
> 
> The eap applicability statement  update is a charter item of
> ABFAB. We've agreed it will be last called in EMU.
> Since it's a work item of abfab, it should be discussed on that list.
> You're certainly free to let people know that the discussion if taking
> place, although we've done that several times before.

Sam,

The type of changes you are talking about are well beyond the "applicability statement changes" that ABFAB is chartered to make.
Now you are discussing how EAP can be executed in a client-driven style (as opposed to network driven), how server-initiated EAP re-authentication may not be supported, how authorization parameters (especially the session lifetime) is not set by the AAA server. 

We need EAP and AAA expertise to get involved in the discussion. Not only when ABFAB WG thinks it is done, but especially from the get go.
This, IMHO, is re-engineering EAP and associated AAA procedures.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 23 Oct 2012 11:08:09 +0300

>    Alper> On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote:
> 
>>> ABFAB. We've agreed it will be last called in EMU.  Since it's a
>>> work item of abfab, it should be discussed on that list.  You're
>>> certainly free to let people know that the discussion if taking
>    Alper> Sam,
>    Alper> The type of changes you are talking about are well beyond the
>    Alper> "applicability statement changes" that ABFAB is chartered to
>    Alper> make.  
> 
> First,  I definitely encourage you to involve anyone in any IETF WG
> discussion you believe will help form a better consensus.
> So, absolutely, encourage people who you believe should join the
> discussion to do so.
> 

Good. Please remember to keep these groups updated as you progress the discussion.

> I am a bit confused by your message, because I'm not discussing changing
> EAP, only discussing how some issues that seem relatively likely to come
> up will influence applying EAP authentication to application
> authentication.

I captured the issues you are raising as below:

>  how EAP can be executed in a client-driven style (as opposed to network driven), how server-initiated EAP re-authentication may not be supported, how authorization parameters (especially the session lifetime) is not set by the AAA server. 

These have potential impact on the EAP layer, and EAP lower-layer (both the EAP peer to EAP Authenticator leg, and the EAP Authenticator to EAP Authentication Server leg [a.k.a, the AAA protocol]). We need to fully understand the implications. These are not mere "applicability" issues. 

The ABFAB applicability update in my understanding is nothing more than removing the somewhat artificial constraints in RFC 3748 that was blocking the use of EAP for anything other than network access authentication. The types of issues you are discussing now are well beyond that.

> My intent is to document existing, potentially hard to understand
> aspects of EAP so that  people can better apply EAP to their
> applications.
> 

Alper

> Thanks,
> 
> --Sam
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Oct 2012 08:50:56 -0400

Alper> Sam,

Thanks,

--Sam