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. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
