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

Re: Thoughts...


Steve Kent says:
> 	The error propogation of CNBC is strictly limited, so using a
> specified pad value at the end and checking it will not detect
> modification that occurred more than one block earlier in the data
> stream.  Given that limitation, it might be better to use a real
> manipulation detection function, or, as you suggested, rely on the
> transport layer error detection functions and view IPSP, in this
> instance, as providing only "support for" integrity at higher layers.

I've got mixed feelings on on this -- on the one hand, I'd like to see
MD5 or SHA based authentication, since TCP checksums aren't
particularly robust. On the other hand, I wouldn't want to see
everyone wrecked to do it. Although multiplying "required" entities is
probably not a good idea, I'd propose (as a strawman) that the
following three things end up in the base standard...

1) MD5 only authentication for use with the Authentication header. (We
   haven't been discussing this yet, but its probably fairly
   non-controversial).
2) DES only for use with the Encryption header, using a session IV,
   relying largely on things like the TCP sequence number to scramble
   blocks of identical data differently, and incorporating no message
   authentication beyond the TCP or similar checksum...
3) a DES+MD5 mode with an explicit authentication block at the end and
   an explicit IV at the beginning that also serves as a sequence
   number against replay, this mode available for paranoids without
   any speed concerns or with heavy hardware.

Phil is a big proponent of the "don't specify too much" school, and
he's one of the people actually implementing, so I will wait for him
to throw bricks at me for suggesting #3 :-)... Myself, I think that
these three are a sufficiently modest base that they aren't sooo bad.
Perhaps #3 should use 3DES instead of DES since its the "paranoid
mode". Perhaps not. Perhaps as I've suggested #3 is a bad idea
altogether because it multiplies requirements too much (but I don't
think its actually so bad.)

Ran mentions that MD5 is somewhat slow even on 64bit RISC processors.
Unfortunately, beyond clever implementations, I'm not sure that we
know of good ways to improve that without hardware, and other than the
(equally slow) SHA, I'm not sure I know of anything else thats really
trustworthy for authentication. Anyone else have ideas?

> 	As for the IV issue, as I noted earlier, a per security
> association IV would be consistent with the guidance of FIPS 81, the
> DES modes standard.  It also might avoid any possible problems with
> hardware that is designed to implemet DES modes according to FIPS 81.
> The incremental performance cost in a software implementation is just
> that of XORing the 64-bit IV for the first block, which seems rather
> minimal.

Of course, a per-association IV doesn't actually buy much in the sense
that identical blocks still look identical -- NFS transfers of large
fields of zeros are likely to be easily spotted, for example. It would
still be reasonable to use a per-association IV over no IV at all
since its fairly cheap.

Perry
References: