> 8. In section 3.1 An example of a GSS_C_NT_HOSTBASED_SERVICE name would be > useful for people w/o sufficient background. I would need to look farther > on this, but based on this text I would end up with something like > "smtp.example.com@SMTP" as a host name. However this looks very strange to > me.
[email protected] would be correct, I agree this notation is confusing, given that most administrators are more familiar with the SPN notation used by Kerberos (smtp/smtp.example.com). > 13. In Section 5.6.1 - is the flag bit of 0x1 reserved for some purpose? > If so this needs to be documented. If not then why not start with mutual > auth at 0x1 rather than 0x2. The flags are from RFC 2744 (e.g. GSS_C_MUTUAL_FLAG is 2). Whilst the initiator should only disclose flags that are relevant to completing the authentication, this allows for future expansion (for example, an initiator that supports DCE-style authentication might use this to select GSS_C_DCE_STYLE). > 14. In section 5.6.3 - Do I assume that it is so obvious that it does not > need to be stated that the EAP negotiated key is used for the MIC w/o any > further key derivation work? I'm wondering actually whether should derive a new key and use RFC 3961 directly rather than GSS_GetMIC(). This might avoid some sequencing issues; the MIT Unwrap/VerifyMIC code checks sequence numbers within a window, and I'm wondering if there might be some attacks because of this. (Of course, this may just be an implementation bug, I need to do more research.) -- Luke _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
