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

[Richard E. Silverman]

>     tlyu> Richard Silverman <res at qoxp.net> writes:
>     >> 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)?
> 
> A string of zero length is different from an absent string.  Among
> other things, they are encoded differently in the protocol.

In which protocol?  Not Kerberos, since the application data is not a
field in the AP_REQ; it's assumed to be transmitted in some
application-specific way along with the AP_REQ.

> >> 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).
> 
> The checksum field of an authenticator is an optional field.  The
> logical thing to do if there is no application data is to omit the
> checksum field.  If the application data consists of a zero-length
> string, then it makes sense to checksum the zero-length string.

Now that you've pointed out that the cksum is optional, I tend to agree
with you, though the spec is silent on this point.  However, there's
difference of opinion, or at least implementation, on this.  I just
finished reading the Samba code (v3.3.2).  In constructing the SPNEGO
token, which contains an AP_REQ with no application data in sight (not an
empty application data field somewhere), they do indeed pass a zero-length
buffer -- not a null in_data pointer -- to krb5_mk_req_extended().  When
that (logically) results in a checksum over the empty string, my NetApp
filer returns KRB5KRB_AP_ERR_MODIFIED.  With my modification so that this
results in omitting the checksum field, the transaction succeeds.  Now,
since Samba is reverse-engineering a Microsoft protocol, once can argue in
this case that this is a bug: they need to do what Microsoft expects.  But
I have identical behavior in other situations: OpenSSH to Bitvise WinSSHD,
and FreeTDS to MS SQL Server.  I need to review that code and see what's
up.

Of course, it's still a mystery to me why the server should further depend
on the checksum cipher in use... I have more research to do to (hopefully)
fully understand this.  I'm using my patch in the meantime because it
makes everything in my environment work, but it may not be the eventual
right thing to do, certainly.

> -- 
>   Richard Silverman
>   res at qoxp.net
>