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

comment on swIPe Draft

I happened to take a look at the swIPe IP Security Protocol Draft
by Ioannidis and Blaze which, just by chance, expires today.
So before the day is over let me provide you with the following comment.

(I guess that at least Matt is busy with other things now, for example,
giving interviews and rejecting jobs...)

My comment regards the specification in the draft of the information
on which the encryption is performed. According to the draft (section 2):

   The swIPe header is prepended to the (inner) IP datagram.  The
   sequence number is copied into the packet and incremented.  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
   authentication algorithm is copied into the authenticator field.  If
   authentication is not performed, then the authenticator field is not
   present.  Next, if encryption is (also) specified, the appropriate
   algorithm and crypto variable are selected and applied to the same
   parts of the datagram as the authentication.  The algorithm may
   require padding, which is appended to the packet after encryption has
   been performed.  The resulting datagram is then transmitted to its
   destination (which may not be the same as that of inner packet).

Some message authentication algorithms (e.g. based on universal hashing)
work by computing a checksum on the authenticated information and then
encrypting this checksum.  In this case one would want to apply encryption
not only to the raw information but also to the authenticator field.
Therefore, the specification that the encryption is "applied to the same
parts of the datagram as the authentication" may be too restrictive for
these cases.  The option to encrypt the authenticator should then be
included.

Hugo Krawczyk

PS: and never use a 16 bit checksum...
Follow-Ups: