Hi folks.
I noticed that under the current draft a mechanism should use the RFC 3961 GetMIC operation on an empty token buffer if an application passes in NULL channel bindings to gss_init_sec_context. I also noticed that this is not what the Moonshot code does. Instead, the moonshot code skips the channel binding subtoken entirely if the application passes in no channel bindings. RFC 3961 says that you can pass in any length data to that operation, which presumably includes 0. I think our checksums are well-defined for 0-length inputs. It's not a widely tested code path, but it probably works and we can work through any bugs relatively quickly. Greg Hudson at MIT did check the aes128 code path and that seems to work. On the other hand, I think what the Moonshot code does is secure. If an attacker removes a channel bindings subtoken the MIC token should detect this. My assumption is that unless there's a consensus to change the draft should remain as-is and Moonshot should change its code. However I'd like to call out the issue and get opinions on whether we want to: 1) Send a MIC of a empty buffer or 2) Omit the token entirely As far as I can tell 1 exercises a not-often-used code path, but is probably fine and 2 is probably fine. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
