So, I'm really hoping that from a process standpoint we can not look to hard at this. I absolutely agree with Bernard that we need to implement things that meet the 4962 requirements.
The implementation I have the most experience with (Moonshot) does implement RFC 4962. We use radsec as the key confidentiality method between AAA server and client. We basically require EAP-TTLS because that's all we're currently implementing channel binding for. The problem is that if we get too picky about IETF process, none of this works. In terms of standardized EAP methods with security, we have EAP-GPSK and EAP-TLS. EAP-TLS doesn't support channel binding and adding it would be difficult. EAP-GPSK probably is something we could use. However, it's the wrong fit for a lot of deployments. RADSEC is a good fit for what we want. Except it's not standards track. Long term, TEAP will be a standards-track method we can move to. Long term, either diameter will catch on, or we'll decide that RADSEC or some other form of security is appropriate for a normative reference from a standards-track spec. I don't think publishing ABFAB is experimental is the right approach. I don't think blocking ABFAB until EAP and RADEXT get done coming up with standards-track mechanisms is the right fix. So, I'm left concluding that being a bit liberal in our process and doing something reasonable with the implementations is the right approach here. So, I think that the right fix for the applicability statement is simply to refer to section 1.2 of RFC 4962 and note that is mandatory-to-implement. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
