20 jul 2012 kl. 16:24 skrev "Sam Hartman" <[email protected]>:
> 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
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
