Hi Martin, Thanks for the quick response.
On 1/8/21 10:25 AM, Martin Thomson wrote: > On Fri, Jan 8, 2021, at 18:54, Mohit Sethi M wrote: >> Thanks for pointing this out. I think Ben also mentioned this in his >> review. I am not sure if it is necessary to add the type-code to the >> label when it is already part of the label string as 'EAP_TLS'. Other >> TLS based EAP methods should ideally register labels of the form >> EXPORTER_EAP_TTLS_MSK or EXPORTER_EAP_FAST_MSK (instead of reusing the >> EAP-TLS label) as is currently done in >> https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01. > Sounds good to me. > >> I do agree with your point about the incorrect usage of the context. >> Perhaps the ideal choice here would be Server-Id and Peer-Id (if client >> certificate is used): https://tools.ietf.org/html/rfc5216#section-5.2. > Maybe, as I said, it depends. > >> However, I checked the wpa_supplicant implementation and currently these >> values are not available. As far as I can tell, the Server-Id and >> Peer-Id are not exported for any EAP method. So we'll need to think >> what's the right thing to do: update implementation/use some other >> sensible value/or leave the context empty (which is allowed in RFC 5705). > This suggests that the values aren't critical to any decision making process > made by either peer and maybe you don't need to include them. I would check > a little more thoroughly though. One implementation not using them isn't > strong enough evidence that they aren't used at all. If those identifiers > determine what certificate is selected, or anything like that, then it would > be good to ensure that peers agree on what they were. That might mean making > them available in implementations that did not previously use them. On the > other hand, if they are always going to be anonymous identifiers that have no > bearing on the TLS operation, don't worry about it and use the empty string. These values are critical for making authorization decisions about network access. It is more a question of where these values are available, exported, and used for decision making in implementations. Thank you for nudging us in the right direction. :) --Mohit _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
