Re: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt

["Charles Clancy" <clancy at cs.umd.edu>]

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.  <>  tcc at umd.edu  <>  www.cs.umd.edu/~clancy



_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu