Subject: [Hipsec] IMPLEMENTORS: New -08-pre and interoperability in Minneapolis

From: [email-masked] (Pekka Nikander)
Date: Wed Oct 1 06:22:01 2003

I have placed now a new set of -08-pre versions on my
web site:

http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01.xml
http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01.txt
http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01.html
http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01-diff.html
http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01-chbar.txt

Unless there are new issues, I expect to get -08 out before
the deadline, once I've got feedback on issues #3, #4/12, #14,
#16 and #17.  I am planning to leave #18 open.

The question is now:  Shall we try base our interop tests
(and possible BOF demos) in Minneapolis on -07 or -08?

Personally I would prefer -08, even if it would require some
more work from us.  However, if nobody else has time to update
their implementation to -08, we would be happy with -07, too.
Our current code is (mostly) based on -07.

--Pekka Nikander

---

From: [email-masked] (Julien Laganier)
Date: Fri Oct 3 03:50:02 2003

> http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01-chbar.txt

Hi Folks,

I am a bit confused by the parameter encryption process.

While having to encrypt a parameter in TLV format, this parameter is aligned 
on a 64 bits boundary. But while using a block cipher whose block size is 
greater than 64 bits (e.g., 128 bits for AES), additional padding might be 
needed while encrypting. So are we supposed to:

(i) let the encryption routines (like openssl's ones) add padding to the 
parameter?

OR

(ii) pad ourself the parameter TLV up to the nearest block size boundary, so 
that no additional padding is needed?

I am guessing that the two above are functionnaly equivalent, but I'm not 
sure. 

Perhaps we can further clarify section 6.2.15 ENCRYPTED with something like:

   If necessary, an implementation MUST append any TLV parameter that is to be    
   encrypted with an additional padding, so that the length of the resulting 
   cleartext is a multiple of the cipher block size length.

Or is this clear for everybody except me ? ;-)

Thanks,

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 6 01:57:02 2003

> Or is this clear for everybody except me ? ;-)

This goes beyond my expertese.  Hence, I am willing to put into the
draft whatever you folks think is good.  The text proposed by Julien
sounds good to me.

Do we accept it?  Any opinions or alternatives?

--Pekka Nikander

---

From: [email-masked] (Andrew McGregor)
Date: Mon Oct 6 05:46:01 2003

-----BEGIN PGP SIGNED MESSAGE-----

- --On Monday, October 06, 2003 09:25:05 AM +0300 Pekka Nikander 
<[email-masked]> wrote:

>> While having to encrypt a parameter in TLV format, this parameter is
>> aligned  on a 64 bits boundary. But while using a block cipher whose
>> block size is  greater than 64 bits (e.g., 128 bits for AES), additional
>> padding might be  needed while encrypting. So are we supposed to:
>>
>> (ii) pad ourself the parameter TLV up to the nearest block size
>> boundary, so  that no additional padding is needed?
>>
>> I am guessing that the two above are functionnaly equivalent, but I'm
>> not  sure.

They are indeed functionally equivalent from an implementation point of 
view, but HIP should specify that padding must exist (and it's cleaner to 
supply the encryption routines with known correct padding).

>>    If necessary, an implementation MUST append any TLV parameter that is
>>    to be     encrypted with an additional padding, so that the length of
>>    the resulting  cleartext is a multiple of the cipher block size
>>    length.
>>

I suspect we should adopt the same sort of wording as RFC2406 section 2.4, 
which specifies this for ESP (as a matter of interest, my code does exactly 
this).  Yes, it's quite wordy, but as you will see, it covers all the bases.

Andrew

- --------
Andrew McGregor
Director, Scientific Advisor
IndraNet Technologies Ltd
http://www.indranet.co.nz/
Office: +64 3 3656485
Mobile: +64 21 898856

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 6 06:18:00 2003

Andrew McGregor wrote:
> I suspect we should adopt the same sort of wording as RFC2406 section
> 2.4, which specifies this for ESP (as a matter of interest, my code
> does exactly this).  Yes, it's quite wordy, but as you will see, it
> covers all the bases.
> 

How about the following text, based on Julien's suggestion:

    If the data to be encrypted is not a multiple of the encryption
    algorithm block size, thereby necessitating padding, and if the
    encryption algorithm does not specify the padding contents, then
    an implementation MUST append the TLV parameter that is to be
    encrypted with an additional padding, so that the length of the
    resulting cleartext is a multiple of the cipher block size
    length.  Such a padding MUST be constructed as specified in
    [RFC2406] Section 2.4.  On the other hand, if the data to be
    encrypted is already a multiple of the block size, or if the
    encryption algorithm does specify padding as per [RFC2406]
    Section 2.4, then additional padding SHOULD NOT be added.

    The Length field in the inside, to be encrypted TLV does not
    include the padding.  The Length field in the outside, ENCRYPTED
    TLV includes all encrypted bytes, and thereby it conceptually
    covers also the padding.

    The ENCRYPTED payload may contain additional padding, if the
    result of encryption, the TLV header and the IV is not a multiple
    of 8 bytes.  The contents of this padding MUST follow the rules
    given in Section "TLV format".

Ok?

--Pekka Nikander

---

From: [email-masked] (Julien Laganier)
Date: Mon Oct 6 06:48:01 2003

>     given in Section "TLV format".

Pekka,

The new text seems fine to me; Perhaps only rewording the first sentence in:

>     If the encryption algorithm requires the length of the data to be
>     encrypted to be multiple of the encryption algorithm block size ...

instead of

>     algorithm block size ...

Thanks,

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 6 07:28:00 2003

>>    If the data to be encrypted is not a multiple of the encryption

Ok, I placed the text to the draft.

I think this issue is now closed.

--Pekka Nikander

---

From: [email-masked] (Andrew McGregor)
Date: Mon Oct 6 15:36:01 2003

-----BEGIN PGP SIGNED MESSAGE-----

>     TLV includes all encrypted bytes, and thereby it conceptually

'The Length field in the outside ENCRYPTED TLV is the length of the data 
after encryption (including padding and any other output from the 
encryption process specified for that suite).'

It needs to say this since there are algorithms which change the length, 
independant of padding, and we may have a compressed suite one day.

- --------
Andrew McGregor

---

From: [email-masked] (Pekka Nikander)
Date: Tue Oct 7 02:36:00 2003

> independant of padding, and we may have a compressed suite one day.

Thanks, Andrew!

I changed the text so that it now reads as follows.

    <t>The Length field in the inside, to be encrypted TLV does
    not include the padding.  The Length field in the outside
    ENCRYPTED TLV is the length of the data after encryption
    (including the Reserved field, the IV field, and the output
    from the encryption process specified for that suite, but
    not any external padding).  Note that the length of the
    cipher suite output may be smaller or larger than the length
    of the data to be encrypted, since the encryption process
    may compress the data or add additional padding to the
    data.</t>

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Tue Oct 7 05:00:01 2003

Hi Folks,

While reading the draft, it appears to me that the header length calculation 
of HMAC differs from the SIGNATURE's one: The HMAC is computed over the 
header including the HMAC TLV (with HMAC field zeroed) parameter, while the 
SIGNATURE is computed over the header excluding the SIGNATURE TLV parameter. 
It's OK because the HMAC TLV has a fixed length.

Perhaps it might be good to have similar rules for the two, i.e. computing a 
given authenticator (being either HMAC or SIGNATURE) over the packet without 
actually appending it to the packet.

This would requires to rewrite sender/receiver HMAC processing using the 
SIGNATURE text:

Packet sender:

   1. Create the HIP packet without the HMAC and possibly following
       HIP_SIGNATURE or HIP_SIGNATURE2 TLVs.

   2.  Calculate the length field in the HIP header.

   3.  Compute the HMAC.

   4.  Add the HMAC TLV to the packet.

   5.  Recalculate the length field in the HIP header.

Packet receiver:

   1.  Verify the HIP header length field.

   2.  Save the contents of the HIP_HMAC TLV and remove it from the packet.
       If the packet contains any HIP_SIGNATURE or HIP_SIGNATURE2
       fields, remove them as well, saving the contents if they will be needed
       later.  Recalculate the HIP packet length in the HIP header.

   3.  Extract the HMAC value from its field.

   4.  Clear the checksum field (set it to all zeros) in the HIP header.

   5.  Compute the HMAC and verify it against the received HMAC.

What do you folks think?

Thanks,

--julien

---

From: [email-masked] (Andrew McGregor)
Date: Tue Oct 7 05:57:01 2003

-----BEGIN PGP SIGNED MESSAGE-----

- --On Tuesday, October 07, 2003 11:27:16 AM +0200 Julien Laganier 
<[email-masked]> wrote:

> Hi Folks,
>
> While reading the draft, it appears to me that the header length
> calculation  of HMAC differs from the SIGNATURE's one: The HMAC is
> computed over the  header including the HMAC TLV (with HMAC field zeroed)
> parameter, while the  SIGNATURE is computed over the header excluding the
> SIGNATURE TLV parameter.  It's OK because the HMAC TLV has a fixed length.
>
> Perhaps it might be good to have similar rules for the two, i.e.
> computing a  given authenticator (being either HMAC or SIGNATURE) over
> the packet without  actually appending it to the packet.

<snip sensible proposed text>

> What do you folks think?

I think it's an excellent idea.  I had not noticed the difference last time 
I read the draft, but I would have suggested this if I had :-)

- --------
Andrew McGregor

---

From: [email-masked] (Pekka Nikander)
Date: Wed Oct 8 10:50:01 2003

> I read the draft, but I would have suggested this if I had :-)

I'm giving this Issue number 24.  I will close this in a couple
of days, as per your suggestion, unless there is more discussion
that warrants otherwise.

--Pekka Nikander

---

From: [email-masked] (Mika Kousa)
Date: Tue Oct 21 12:30:01 2003

Section 3.3 Security Parameter Index (SPI) of draft-08 says that "The SPI
selection SHOULD be random." While I was fixing our implementation, I
found out that RFC2406 (IP Encapsulating Security Payload (ESP)) section
2.1 defines some restrictions for SPI assignment: "The set of SPI values
in the range 1 through 255 are reserved by the Internet Assigned Numbers
Authority (IANA) for future use" and "The SPI value of zero (0) is
reserved for local, implementation- specific use and MUST NOT be sent on
the wire". Should the draft-08 also note that these values defined in
RFC2406 must not be used ?

---

From: [email-masked] (Pekka Nikander)
Date: Thu Oct 23 06:21:00 2003

> RFC2406 must not be used ?

Good catch.  I replaced RFC2406 with draft-ietf-ipsec-esp-v3,
and added a reference to Section 2.1 of that draft to the
SPI section of our draft.

I think the issue is fixed now, and can be closed.

--Pekka