>>>>>> "Alper" == Alper Yegin <alper.ye...@yegin.org> writes: > > Alper> On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: > >>>>>>> "Alper" == Alper Yegin <alper.ye...@yegin.org> 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. > > 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 > rad...@ietf.org > https://www.ietf.org/mailman/listinfo/radext _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
