Subject: [Hipsec] [CORRECTED] "Minor" correction to hip-rvs

From: Julien Laganier <[email-masked]>
Date: Mon, 10 Dec 2007 17:05:55 +0100

[ Resent since I managed to mess up my copy/paste :( Sorry! ]

Folks,

While being polled for IANA action I noticed that the hip-rvs draft 
still defines a RVS_HMAC parameter of fixed length, while the hip-base 
draft does not:

Value        Parameter Type            Length      Data                        
             Reference
--------     ----------------------    ---------- 
----------------------------------------  ---------
65500        RVS_HMAC                  20                                      
             [RFC-ietf-hip-rvs-05.txt]

Historically the RVS_HMAC related text from hip-rvs has been a near 
copy/paste of the HMAC text from hip-base, only the parameter type (and 
hence the location, after signature) would differ. 

The coupling between the two has been lost due to negligence on my part. 
I lost track of the changes of HMAC in hip-base, i.e. addition of 
pseudo hash agility. Therefore I think the RVS_MAC text in hip-rvs 
shall be aligned with that of the HMAC in hip-base.

That would require the change below to be carried on. I do not know 
however how now that hip-rvs is in RFC Editor queue. ADs, can that be 
done as part of AUTH-48?

--julien

----------------------------------------------------------------------

OLD:

4.2.1.  RVS_HMAC Parameter

   The RVS_HMAC is a non-critical parameter whose only difference with
   the HMAC parameter defined in [I-D.ietf-hip-base] is its "type" code.
   This change causes it to be located after the FROM parameter (as
   opposed to the HMAC):

   Type        [ TBD by IANA (65500 = 2^16 - 2^5 - 2^2) ]
   Length      20
   HMAC        160 low order bits of a HMAC keyed with the
               appropriate HIP integrity key (HIP_lg or HIP_gl),
               established when rendezvous registration happened.
               This HMAC is computed over the HIP packet, excluding
               RVS_HMAC and any following parameters.  The
               "checksum" field MUST be set to zero and the HIP header
               length in the HIP common header MUST be calculated
               not to cover any excluded parameter when the
               "authenticator" field is calculated.

   To allow a rendezvous client and its RVS to verify the integrity of
   packets flowing between them, both SHOULD protect packets with an
   added RVS_HMAC parameter keyed with the HIP_lg or HIP_gl integrity
   key established while registration occurred.  A valid RVS_HMAC SHOULD
   be present on every packets flowing between a client and a server and
   MUST be present when a FROM parameters is processed.

NEW:

4.2.1.  RVS_HMAC Parameter

   The RVS_HMAC is a non-critical parameter whose only difference with
   the HMAC parameter defined in [I-D.ietf-hip-base] is its "type" code.
   This change causes it to be located after the FROM parameter (as
   opposed to the HMAC):

   Type        [ TBD by IANA (65500 = 2^16 - 2^5 - 2^2) ]
   Length      length in octets, excluding Type, Length, and
               Padding
   HMAC        HMAC computed over the HIP packet, excluding the
               RVS_HMAC parameter and any following parameters. The
               HMAC is keyed with the appropriate HIP integrity key
               (HIP-lg or HIP-gl) established when rendezvous
               registration happened. The checksum field MUST be set to
               zero and the HIP header length in the HIP common header
               MUST be calculated not to cover any excluded parameters
               when the HMAC is calculated.  The size of the
               HMAC is the natural size of the hash computation
               output depending on the used hash function.

   To allow a rendezvous client and its RVS to verify the integrity of
   packets flowing between them, both SHOULD protect packets with an
   added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity
   key established while registration occurred.  A valid RVS_HMAC SHOULD
   be present on every packets flowing between a client and a server and
   MUST be present when a FROM parameters is processed.

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec