|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Mime-Version: 1.0 (Apple Message framework v1078) From: Ken Raeburn <raeburn@mit.edu> In-Reply-To: <Pine.LNX.4.64.1006041421430.24992@seraph.oankali.net> Date: Fri, 4 Jun 2010 15:10:02 -0400 Message-Id: <080ADFDC-B69B-4F12-B9DE-D9F7F32A22D7@mit.edu> To: Richard Silverman <res@qoxp.net> Cc: "kerberos@mit.edu" <kerberos@mit.edu> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kerberos-bounces@mit.edu 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@mit.edu / just an interested Kerberos geek :) ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |