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

[Ken Raeburn]

On Jun 4, 2010, at 14:47, Richard Silverman wrote:
>> 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.

Whether an absent checksum is different from a checksum of an empty message is up to the application protocol.

>  What does a null in_data pointer indicate in that regard that a
> pointer to an empty buffer doesn't (or vice versa)?

> 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).

A few lines further up, it indicates that cksum is an optional field.  It might've been simpler had the spec tied, for example, an omitted checksum to omitted or zero-length application data, but the current spec allows the two cases to be different.  A null pointer to the data descriptor vs a pointer to a data descriptor indicating a length of zero is how we support both.

Ken


-- 
Ken Raeburn / raeburn at mit.edu / just an interested Kerberos geek :)