KRB5KRB_AP_ERR_MODIFIED: MIT Kerberos 1.8.1 & arcfour-hmac-md5 session key

[Richard Silverman]

On Fri, 4 Jun 2010, Greg Hudson wrote:

> On Fri, 2010-06-04 at 12:24 -0400, Richard E. Silverman wrote:
>> I tracked down the bug.
>
> With apologies for being a pain in the butt, I'm not sure we understand
> the situation well enough to safely make a change.

Not at all; it has to be done right.

> Providing zero-length input data is not the same as not providing any
> input data.

I don't understand your point here -- from a calling perspective of course
they are distinguishable, but they *mean* the same thing, do they not?  I
mean, the AP_REQ either has application data accompanying it, or it
doesn't.  What does a null in_data pointer indicate in that regard that a
pointer to an empty buffer doesn't (or vice versa)?

> The change you suggested could have interoperability or security
> ramifications if an application genuinely wants to checksum the empty
> string in an authenticator.

This is a matter of the spec, isn't it?  It's not a question of what an
application *wants* to do; it's a question of what is *supposed* to be
done when there is no application data.  The RFC says of the checksum:

5.3.2. Authenticators
...
    cksum     This field contains a checksum of the the application data
              that accompanies the KRB_AP_REQ.

... and says nothing further about how to treat the situation of no
application data.  In particular, it does not specify some special action
to be taken in that case (e.g. a zero checksum).  In the absence of that,
I interpret it to mean that the checksum should be computed over the empty
string in that case.  And my patch assures that if krb5_mk_req_extended()
is passed an empty buffer, it will checksum the empty string (it didn't
before).

> Moreover, the mk_req_ext behavior you're proposing to change did not
> change between 1.6 and current.  The behavior of callers may have
> changed, of course.

Good point.  Something surrounding or underneath it changed though, since
this does fix the problem.  That doesn't mean it's necessarily the right
fix or that it doesn't have some other undesirable consequence, but it
seems right to me.  I think that once I have a chance to track down
exactly what it behaves differently depending on which cipher is used,
that might help clarify this.

- Richard