[AFS3-std] rxgk key version number of value zero

Wed, 12 Dec 2012 14:07:18 -0600

--0__=09BBF041DFFE7CAA8f9e8a93df938690918c09BBF041DFFE7CAA
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable

afs3-standardization-admin@openafs.org wrote on 12/11/2012 15:41:53:
> On Tue, 2012-12-11 at 20:30 +0000, Simon Wilkinson wrote:
> > On 11 Dec 2012, at 20:05, Michael Meffie wrote:
> >
> > >   The Checksum field allows for an optional packet checksum.  A z=
ero
> > >   checksum field value means that checksums are not being compute=
d.
An
> > >   Rx security protocol (identified by the security field, describ=
ed
> > >   below) may choose to use this field to transport some checksum =
of
the
> > >   packet that is computed and verified by it (for example, rxkad =
uses

> > >   this field for a cryptographic header checksum).  Rx itself mak=
es
no
> > >   use of the checksum field.
> >
> > Technically, this is a "spare" field that rxkad hijacked to use for=

> > checksums. I don't think there's any particular problem with rxgk
> > assigning it a different meaning. One possible consideration is tha=
t
> > the OpenAFS RX stack notes the presence of non-zero values here, an=
d
> > the rx_IsUsingPktCksum() function will return true if it has seen a=
ny
> > in the life of the connection. However, the only caller of this
> > function in the OpenAFS code is rxkad, and I don't think it makes m=
uch
> > sense outside of rxkad itself.
>
> In fact, it makes sense only in versions of rxkad newer than 1989 or =
so.
> Versions of rxkad prior to that didn't use this field, and had no
> equivalent to the checksum that is carried there today.  According to=

> RCS logs, the rx_{Get,Set}PacketCksum interfaces were introduced in 1=
991
> by Ted Anderson; they were present by the time AFS 3.1 was released.

As I recall, the cksum was added to defeat an attack identified by some=
one
in Peter Honeyman's group at UMich.  The 89-91 time frame would be righ=
t
for that.  We didn't have a lot of flexibility in responding, so a fiel=
d
was borrowed from the RX header.  If my recollection is correct, it
confirms that the usage is rxkad-specific, which I gather is the point
here.

Ted

> rxvab never used the spare/cksum; in fact, its CheckPacket always
> succeeds.  R did have a checksum field in its headers, but it was nev=
er
> actually used -- the field was always sent as -1 and discarded as the=

> packet was being decoded (R's headers were XDR'd on the wire).
>
> -- Jeff=

--0__=09BBF041DFFE7CAA8f9e8a93df938690918c09BBF041DFFE7CAA
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

<html><body>
<tt>afs3-standardization-admin@openafs.org wrote on=
 12/11/2012 15:41:53: 
&gt; On Tue, 2012-12-11 at 20:30 +0000, Simon Wilkinson wrote: 
&gt; &gt; On 11 Dec 2012, at 20:05, Michael Meffie wrote: 
&gt; &gt; 
&gt; &gt; &gt; &nbsp; The Checksum field allows for an optional packet =
checksum. &nbsp;A zero 
&gt; &gt; &gt; &nbsp; checksum field value means that checksums are not=
 being computed. &nbsp;An 
&gt; &gt; &gt; &nbsp; Rx security protocol (identified by the security =
field, described 
&gt; &gt; &gt; &nbsp; below) may choose to use this field to transport =
some checksum of the 
&gt; &gt; &gt; &nbsp; packet that is computed and verified by it (for e=
xample, rxkad uses 
&gt; &gt; &gt; &nbsp; this field for a cryptographic header checksum). =
&nbsp;Rx itself makes no 
&gt; &gt; &gt; &nbsp; use of the checksum field. 
&gt; &gt; 
&gt; &gt; Technically, this is a &quot;spare&quot; field that rxkad hij=
acked to use for 
&gt; &gt; checksums. I don't think there's any particular problem with =
rxgk 
&gt; &gt; assigning it a different meaning. One possible consideration =
is that 
&gt; &gt; the OpenAFS RX stack notes the presence of non-zero values he=
re, and 
&gt; &gt; the rx_IsUsingPktCksum() function will return true if it has =
seen any 
&gt; &gt; in the life of the connection. However, the only caller of th=
is 
&gt; &gt; function in the OpenAFS code is rxkad, and I don't think it m=
akes much 
&gt; &gt; sense outside of rxkad itself. 
&gt; 
&gt; In fact, it makes sense only in versions of rxkad newer than 1989 =
or so. 
&gt; Versions of rxkad prior to that didn't use this field, and had no<=
br>
&gt; equivalent to the checksum that is carried there today. &nbsp;Acco=
rding to 
&gt; RCS logs, the rx_{Get,Set}PacketCksum interfaces were introduced i=
n 1991 
&gt; by Ted Anderson; they were present by the time AFS 3.1 was release=
d. 
</tt> 
<tt>As I recall, the cksum was added to defeat an atta=
ck identified by someone in Peter Honeyman's group at UMich. &nbsp;The =
89-91 time frame would be right for that. &nbsp;We didn't have a lot of=
 flexibility in responding, so a field was borrowed from the RX header.=
 &nbsp;If my recollection is correct, it confirms that the usage is rxk=
ad-specific, which I gather is the point here.</tt> 
 
<tt>Ted</tt> 
 
<tt>&gt; rxvab never used the spare/cksum; in fact, it=
s CheckPacket always 
&gt; succeeds. &nbsp;R did have a checksum field in its headers, but it=
 was never 
&gt; actually used -- the field was always sent as -1 and discarded as =
the 
&gt; packet was being decoded (R's headers were XDR'd on the wire). =

&gt; <br>
&gt; -- Jeff<br>
</font></tt></body></html>=

--0__=09BBF041DFFE7CAA8f9e8a93df938690918c09BBF041DFFE7CAA--