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

["Bernard Aboba" <bernard_aboba at hotmail.com>]

> 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?

The problem is that the RFC 4334 lower layer number space is not 
synchronized with the existing RADIUS NAS-Port-Type space.   On the server 
side, this means that a AAA server could not just compare the NAS-Port-Type 
attribute value with the OIDs in the cert;  it has to have a table mapping 
one to the other.  This would require addition of an OID mapping table to 
the AAA server.  So far, no servers have implemented this, and I suspect 
that they will not do so in the near future.

> 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.

If the approach is not good for the long-term, why should implementers be 
encouraged to embrace it?  This is likely to encourage further requests for 
allocation of RFC 4334 OIDs, creating interoperability problems where none 
existed previously.

> 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.

RFC 4334 doesn't improve authorization of clients.  Today AAA servers can 
check the NAS-Port-Type attribute and send a Reject if the client is not 
authorized for that medium.  Adding lower layer OIDs to the client 
certificate will not provide more authorization functionality than we 
already have, but will add complexity.

In terms of server authorization, the benefit is unclear to me.  Assuming a 
server is authenticated and appears authorized along other dimensions 
(chains to a trust anchor, has an appropriate name), should a client reject 
it because it lacks the OIDs for the particular form of access involved?  
> From an architectural point of view, EAP-TLS implementations typically leave 
certificate selection to the TLS implementation.  RFC 4334 support could 
require changes to the certificate selection code.

Overall, given the lack of RFC 4334 implementation and the cost/benefit 
ratio going forward, it's probably best to let this "sleeping dog" RFC lie.



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