>>>>> "Jeffrey" == Jeffrey Hutzelman <[email protected]> writes:
Yes.
>>
Jeffrey> Why define a family of mechanisms parameterized by enctype,
instead of
Jeffrey> defining a single mechanism, specifying a mandatory-to-implement
enctype,
Jeffrey> and negotiating the enctype to be used as part of context
establishment?
Jeffrey> This would also work around a situation with SASL mechanism
naming, which
Jeffrey> is that you are effectively defining an entire family of GSs-API
mechs but
Jeffrey> specifying SASL mechanism names for only one member of that
family. This
Jeffrey> means that either other enctypes cannot be used at all, or else
they must
Jeffrey> forever have non-friendly names encoded as per RFC5801 section 3.1.
>>
Jeffrey> Alternately, you could register a family of SASL mechansim names,
of the
Jeffrey> form EAP-<enc> and EAP-<enc>-PLUS, where <enc> is a numeric
enctype. This
Jeffrey> is a bit uglier than EAP-AES128[-PLUS], but prevents future
Jeffrey> interoperability problems due to SASL mechanism name mismatches
and at
Jeffrey> least is reversible, unlike the RFC5801 section 3.1 encoding.
>>
>> I think this one is informed WG consensus. One reason to do things as we
>> have is that you run into an interop problem if policy or algorithm
>> evolution ever disables a mandatory enctype.
>> I think the implications have been discussed.
Jeffrey> OK, fair enough.
>> Since the SASL registry is FCFS, I don't see a problem with having to
>> register each enctype separately to get a friendly name.
Jeffrey> The only problem is that if someone starts using that enctype with
this
Jeffrey> mechanism before the friendly name is registered, they end up
using the
Jeffrey> unfriendly name, and then you eventually have a false interop
problem,
Jeffrey> where two implementations both support that enctype but don't know
it.
Jeffrey> Avoiding this is why we wanted friendly names registered when the
Jeffrey> mechanism is defined, but RFC5801 doesn't really contemplate
mechanism
Jeffrey> families like this one.
My assumption is that a implementation will only include things for
which it has a friendly name in indicate_mechs output.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
