[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: it just occured to me...

Now that I have one of the swIPe disks in hand, I decided to read the
draft (now expired, oh well), and I have a few comments.

You describe the authenticator:

         An authenticator, computed over the entire swIPe packet (minus
         the outer IP header), but before any confidentiality processing
         is performed.  When the authenticator is computed, the
         authentication data field is zeroed.

There's a problem with this.  First, even given a particular policy
identifier, it may not be possible to determine the length of the
authenticator until the authenticator is chosen.  For example, if you
use GSS-API, you don't know what the underlying mechanism or encoding
is, so the length could even change from packet to packet (say, if an
ASN.1 encoded length was a part of the checksum).  This makes it
impossible to put the "correct" number of zeros in place before
computing the authenticator.


   								If
   authentication is to be performed, the authenticator field (of the
   appropriate length) is zeroed, and the authentication algorithm is
   applied to the authentication information part of the header (i.e.,
   the swIPe header minus the first 32 bits) and the original IP
   datagram.  The checksum resulting from the application of the

Why not include the first 32 bits as well?  That seems like useful
information to have signed, and the overhead is small.

As a fix, I would propose changing the authenticator to be defined as
the signature over the (virtualized) buffer resulting from the first 8
octets of the sWIpe header concatenated to the inner packet.  It also
occurs to me that even this might be an overspecification; it doesn't
seem to me that the authenticator needs to be defined this rigidly.
If one particular encryption system wants to stick 16 bytes of zeros
in the middle of the buffer to make way for an MD5 hash, I have no
problem with that.  As long as the mechanism can be determined from
the policy identifer, the exact details of the authenticator
construction should be a mechanism-specific issue.

         Some security algorithms (such as DES) require padding to bring
         the length of the data to an integral multiple of the block
         size.  The padding is added after the authentication data have
         been computed.

Some integrity algorithms (such as DES MAC) also require padding.  In
both cases, does the padding need to be transmitted?  In addition, the
padding could be useful for foiling traffic analysis, etc.  In short,
I think this field is overspecified, too.

		Marc