> On Feb 9, 2019, at 1:17 AM, Alan DeKok <al...@deployingradius.com> wrote:
>
> On Feb 8, 2019, at 7:21 AM, John Mattsson <john.matts...@ericsson.com> wrote:
>> (Everything below is from a pure EAP-TLS (0x0d) perspective without
>> considering any cross-method things)
>>
>> - From an EAP-TLS perspective, I think these two cases ("not authenticated"
>> and "authenticate via some other means") are the same, the peer is not
>> authenticated as far as EAP-TLS is concerned. I read the sentence "other
>> means" as outside of TLS.
>>
>> - RFC 5216 allows deployments with only server authentication:
>>
>> RFC 5216: "While the EAP server SHOULD require peer authentication, this is
>> not mandatory, since there are circumstances in which peer authentication
>> will not be needed (e.g., emergency services, as described in [UNAUTH]), or
>> where the peer will authenticate via some other means."
>>
>> I don't know if there exists EAP-TLS (0x0d) deployments where the "peer
>> authentication will not be needed" or "peer will authenticate via some other
>> means", but if they do exist, we should probably not forbid them to do
>> resumption unless we have good reasons.
>
> I agree.
>
> I can't think of any deployment which allows unauthenticated EAP-TLS. Or
> authenticated only via the NAI.HS 2.0 Release 2 section 7.7 (Anonymous EAP-TLS) This specification defines a WFA Vendor specific EAP method, WFA Anonymous EAP-TLS, which can be used for OSU access. WFA Anonymous EAP-TLS is a profile of EAP-TLS (specified in [25]), in which the supplicant authenticates the AS, but the AS does not authenticate the client. WFA Anonymous EAP-TLS shall only be used for the OSU ESS; it shall not be used for the production ESS (see section 5.4.2) It's used to allow access to the OSU (Online Sign Up) network to allow initial provisioning. Yes, if the same AS server were used for both OSU ESS and production ESS a user could theoretically leverage cross-method resumption to gain access to the production ESS. Arguably, the same issue could occur with any two SSIDs using the same AS irrespective of whether the EAP method was the same or not. This isn't a fundamental issue with cross-method resumption or session resumption in general, but a lack of appropriate binding between session tickets and the context in which they're being used. Regarding anonymous outer identities and re-authorization, the real-world solution I've seen and implemented, is to associate the session ticket ID with the user's NAI using a datastore when using stateful tickets, or to include the user's NAI in the opaque data portion of sateless tickets. Similar methods could be used to prevent cross-method resumption if local policies require it. -Arran
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
