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

[Richard E. Silverman]

>>>>> "KR" == Ken Raeburn <raeburn at MIT.EDU> writes:

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

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

I agree.  I'm pointing out that there are apparently differences in how
this is intepreted in various implementations of the same protocol, and
further, that something changed between 1.6.3 and 1.8 which has broken
previously working code.

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

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

    KR> Ken

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