Subject: [Hipsec] HIP issue #03: Keymat interpretation

From: [email-masked] (Petri Jokela)
Date: Wed Nov 19 08:11:01 2003

I have now changed the section 9 and 11 according to discussions
earlier on this list. Proposed new text follows.

Changes in Section 9:

- Changed two paragraphs according to Tom's comments.
- The key retrieval from the KEYMAT according to discussion earlier

Changes in Section 11:

Two new subsections added as proposed by Pekka. I haven't looked at
other subsections in 11, so they are still in the original shape.
The new ones are attached in this mail.

In 11.2, I wanted to use something else than I and R for the rekey
initiator and responder just to make sure that there is no connection
with the basic 4-way handshake roles. That's why I' and R'.

/petri

9. HIP KEYMAT

    HIP keying material is derived from the Diffie-Hellman Kij produced
    during the base HIP exchange.  The Initiator has Kij during the
    creation of the I2 packet, and the Responder has Kij once it receives
    the I2 packet.  This is why I2 can already contain encrypted
    information.

    The KEYMAT is derived by feeding Kij and the HITs into the following
    operation; the | operation denotes concatenation.

     KEYMAT = K1 | K2 | K3 | ...
           where

     K1   = SHA-1( Kij | sort(HIT-I | HIT-R) | 0x01 )
     K2   = SHA-1( Kij | K1 | 0x02 )
     K3   = SHA-1( Kij | K2 | 0x03 )
     ...
     K255 = SHA-1( Kij | K254 | 0xff )
     K256 = SHA-1( Kij | K255 | 0x00 )
     etc.

    Sort(HIT-I | HIT-R) is defined as the network byte order
    concatenation of the two HITs, with the smaller HIT preceding the
    larger HIT, resulting from the numeric comparison of the two HITs
    interpreted as positive (unsigned) 128-bit integers in network byte
    order.

    The initial keys are drawn sequentially in the following order:

       HIP-IR encryption key for Initiator's outgoing HIP packets

       HIP-IR integrity (HMAC) key for Initiator's outgoing HIP packets

       HIP-RI encryption key (currently unused) for Responder's outgoing
       HIP packets

       HIP-RI integrity (HMAC) key for Responder's outgoing HIP packets

       SA-IR ESP encryption key for Initiator's outgoing traffic

       SA-IR ESP authentication key for Initiator's outgoing traffic

       SA-RI ESP encryption key for Responder's outgoing traffic

       SA-RI ESP authentication key for Reponder's outgoing traffic

    The IR and RI denotes the direction of the traffic where the key is
    applied.  The IR describes "from the Initiator to the Responder"
    -direction and the RI the other direction.

    The number of bits drawn for a given algorithm is the "natural" size
    of the keys.  For the mandatory algorithms, the following sizes
    apply:

    3DES 192 bits

    SHA-1 160 bits

    NULL 0 bits

    The four HIP keys are only drawn from KEYMAT during a HIP I1->R2
    exchange.  Subsequent rekeys using NES will only draw the four ESP
    keys from KEYMAT.  Section 8.9 describes the rules for reusing or
    regenerating KEYMAT based on the NES exchange.

11.1 ESP Security Associations

    Each HIP association is linked with two ESP SAs, one incoming and one
    outgoing.  The Initiator's incoming SA corresponds with the
    Responder's outgoing one.  The initiator defines the SPI for this
    association, as defined in Section 3.3.  This SA is called SA-RI, and
    the corresponding SPI is called SPI-RI. Respectively, the Responder's
    incoming SA corresponds with the Initiator's outgoing SA and is
    called SA-IR, with the SPI-IR.

    The Initiator creates SA-RI as a part of R1 processing, before
    sending out the I2, as explained in Section 8.5. The keys are derived
    from KEYMAT, as defined in Section 9. The Responder creates SA-RI as
    a part of I2 processing, see Section 8.6.

    The Responder creates SA-IR as a part of I2 processing, before
    sending out R2, see Step 17 in Section 8.6. The Initator creates
    SA-IR when processing R2, see Step 7 in Section 8.7.

11.2 Updating ESP SAs during rekeying

    After the initial 4-way handshake and SA establishment, both hosts
    are in state E3.  There are no longer Initiator and Responder roles
    and the association is symmetric.  In this subsection, the initiating
    party of the rekey procedure is denoted with I' and the peer with R'.

    The I' initiates the rekeying process when needed (see Section 8.8).
    It creates a NES packet with required information and sends it to the
    peer node.  The old SAs are still in use.

    The R', after receiving and processing the NES (see Section 8.9),
    generates new SAs: SA-I'R' and SA-R'I'.  It does not take the new
    outgoing SA into use, but uses still the old one, so there exists two
    SA pairs towards the same peer host.  For the new outgoing SA, the
    SPI-R'I' value is picked from the received NES packet.  The R'
    generates the new SPI value for the incoming SA, SPI-I'R', and
    includes it in the response NES packet.

    When the I' receives a response NES from the R', it generates new
    SAs, as described in Section 8.9: SA-I'R' and SA-R'I'. It starts
    using the new outgoing SA immediately.

    The R' starts using the new outgoing SA when it receives traffic from
    the new incoming SA.  After this, the R' can remove old SAs.
    Similarily, when the I' receives traffic from the new incoming SA, it
    can safely remove old SAs.

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]

---

From: [email-masked] (Petri Jokela)
Date: Wed Nov 19 08:15:01 2003

Reminder: the issue number refers to the issue-tracker numbering for 
draft-moskowitz-hip-xxx

http://hip4inter.net/issues
userid: guest
passwd: guest

/petri