[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: