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

Re: ESP_NULL internet draft submitted



In message <A1B6CB375930D11188D100A0C95A36BD011477F9@FMSMSX31>, "Patel, Baiju V" writes:
> 
> 1. Should the pad length field be present and set to 0 or omitted?
> 2. This will mean that the authentication data will not be at 
>    4 or 8 byte boundary 

The ESP master document (draft-ietf-ipsec-esp-v2-03.txt) covers both of these
cases. Specifically, padding is always required when authentication is in use:

(From 2.4 Padding (for Encryption):

           o Padding also may be required, irrespective of encryption
             algorithm requirements, to ensure that the resulting
             ciphertext terminates on a 4-byte boundary. Specifically, the
             Pad Length and Next Header fields must be right aligned within
             a 4-byte word, as illustrated in the ESP packet format figure
             above, to ensure that the Authentication Data field (if
             present) is aligned on a 4-byte boundary.
 

and the pad length field is *always* required:

	2.5  Pad Length
	 
	   The Pad Length field indicates the number of pad bytes immediately
	   preceding it.  The range of valid values is 0-255, where a value of
	   zero indicates that no Padding bytes are present.  The Pad Length
	   field is mandatory.
 


> Section 2.1 suggests that we can use keys of non-zero length.
> 
> [ snip ]
>
> Section 3 requires that key length is 0. One of the two should be
> changed to avoid confusion.
>
> 3. ESP_NULL Operational Requirements
> 
>       For purposes of IKE [IKE] key extraction, the key size for this
>    algorithm MUST be zero (0) bits, to facilitate interoperability and
>    to avoid any potential export control problems.

No. This is fine.

Section 3 requires a key length of 0 *when ESP-NULL is negotiated under IKE*.
Under section 2.1, *manually* keyed ESP-NULL can use any key length.

--
Harald <chk@utcc.utoronto.ca>


References: