On Sun, January 21, 2007 12:30 pm, Bernard Aboba wrote: >>What about RFC 4334? > > The OIDs defined in RFC 4334 do not correspond to values of the > NAS-Port-Type attribute, so the backend authentication server certificate > handling code would need to be updated everytime a new value were to be > assigned; the AAA server can't just check that the NAS-Port-Type attribute > includes a value that matches one of the OIDs in the client certificate. > Similarly, client code would need to be updated every time a new EAP lower > layer was defined, since the client would need to check if the server > certificate contained an OID allowing it to be used to authorize a given > EAP > lower layer.
So your objection is that essentially different lower layers have been hard-coded into 4334 (PPP and EAPoL), and consequently into the cert handling code, such that new RFCs and new code would be required to support EAP over different L2/L3 technologies? I can see that as an objection to the fundamental approach, and a reason to possibly not support future EKUs for other lower layers, but not as a reason to not support the currently-defined EKUs. If implementers are rev-ing their EAP-TLS code for 2716bis compliance, this would be a good time to roll in these changes. I'd think a statement like "When EAP-TLS is used with WLANs, support for WLAN-specific EKUs [RFC 4334] is RECOMMENDED to improve certificiate-based authorization of EAP clients and servers" would be appropriate. -- t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
