OK, here's where this stands. We've been discussing on #krbdev, the upstream krb5 IRC channel. We agree that ignoring a MIC token that is an exact copy of the response token is security neutral and it looks like both upstream and I are comfortable making a change to do that even though it seems to go against text in RFC 4178. (I think RFC 4178 is overly conservative here).
My argument for why it is security neutral is that an attacker could modify the token in transit and cause the same effect. So, either the protocol is already broken, or this does no harm. What needs to happen now is someone familiar with the MIT SPNEGO code needs to look at the patch and confirm it actually ignores MIC tokens only when MIC tokens are optional. In particular, we want to confirm that if the mechanism supports integrity and a MIC token would be required either through request-mic state or because the acceptor didn't choose tho optimistic mechanism,that a MIC token is still required. It may be relatively easy to argue that's the case--in particular if this patch affects the logic before the code evaluates whether MIC is required, then it's probably fine. I know I'm relatively busy today and I believe the others involved in the discussion so far have been similarly busy. --Sam -- likewise-open fails to join Windows 2000 SP4 domain https://bugs.launchpad.net/bugs/551901 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to krb5 in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
