Subject: [Hipsec] HIP parameters critical flag

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Jan 2010 07:58:23 -0800

Tobias and I have been working away on 5201-bis and of course one new 
thing is the HIH parameter that needs a number...

-------- Original Message --------
Subject: 	Fwd: HIP parameters critical flag
Date: 	Tue, 12 Jan 2010 11:49:51 +0100
From: 	Tobias Heer <[email-masked]>
To: 	Robert Moskowitz <[email-masked]>

Hello Bob,

>  Am 11.01.2010 um 21:54 schrieb Robert Moskowitz:
>
>>  So for defining the new HIH parmeter, I am looking at 5.2.1 and it talks about the critical flag.  Oops, of course HIH is critical.  So I search for critical in the other parameters and NONE mention being critical.
>>
>>  What am I missing here???
>>
>
>  the C bit is the lowest order bit of the parameter number. All parameters with odd numbers (e.g. Puzzle, Solution, DH ...) are critical.

We are going to clearify this in 5201-bis and explicitly state what is a critical parameter.

>>  Also what is the type value for HIH to get it in the 'right' place in the parameters?
>>
>  The HIH definitely needs to be in the signed part of the packet. I would consider it a parameter that is related to the BEX. The appropriate parameter range would be 0-1023. We probably need to check the HIP extensions to find a free number in this range. I'll do this tomorrow.
>

I looked at the parameter numbers and I would suggest number 715 because is located behind 705/Host_ID and it is therefore close to it in the actual HIP control packet.

I checked the following things for all active HIP drafts and documents that are accessible from the HIP WG status page:
* There is no mentioning of the parameter number 715
* The next parameter higher than 705/HOST_ID is 768/Cert (RFC5201 and draft-ietf-hip-cert-02.txt)
   - there won't be any parameter between HOST_ID and HIH
   - there is sufficient space between HIH and Cert to introduce new parameters

I checked the following files:

rfc4423.txt
rfc5201.txt
rfc5202.txt
rfc5203.txt
rfc5204.txt
rfc5205.txt
rfc5206.txt
rfc5338.txt
draft-ietf-hip-bone-03.txt
draft-ietf-hip-cert-02.txt
draft-ietf-hip-hiccups-00.txt
draft-ietf-hip-nat-traversal-09.txt
draft-ietf-hip-native-api-11.txt

Any more to check? HIP RG documents?

=================================================================

And Miika proposes:

I would say that it should be before the ESP_INFO parameter. 63?

http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml

====================================================================

So a hum is requested:

715?
63?

Other?

---

From: Tobias Heer <[email-masked]>
Date: Tue, 12 Jan 2010 17:35:46 +0100

Since I suggested it, it makes sense to vote for it:

715

Tobias

Am 12.01.2010 um 16:58 schrieb Robert Moskowitz:

> Tobias and I have been working away on 5201-bis and of course one new thing is the HIH parameter that needs a number...
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: Tobias Heer <[email-masked]>
Date: Tue, 12 Jan 2010 18:17:46 +0100

Hi, 

Just one clarification:
The suggestion that the HIH and the HI should be close in the packet comes from the fact that the HIH only makes sense in packets that contain the HI (e.g., to check the HI-HIT relation). Therefore, they are closely related and it might be useful to keep both together.

Tobias

--

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Tue, 12 Jan 2010 09:24:44 -0800

> Since I suggested it, it makes sense to vote for it:

Are you going to include the HIH parameter inside the ENCRYPTED TLV (in the I2 packet)?
If so, it keeping HIH next to HOST_ID with the value 715 makes sense to me. Otherwise 63 would work. 

Have you considered extending the HOST_ID TLV by one field to include HIH (rather than using a separate parameter)?
(for example the HI hi_hdr already indicates the RSA/DSA key type, the HIP_SIGNATURE contains SIG algorithm, etc.)

-Jeff

> > Tobias and I have been working away on 5201-bis and of 
> course one new thing is the HIH parameter that needs a number...
> > 
> >>> So for defining the new HIH parmeter, I am looking at 
> 5.2.1 and it talks about the critical flag.  Oops, of course 
> HIH is critical.  So I search for critical in the other 
> parameters and NONE mention being critical.
> >>> 
> >> the C bit is the lowest order bit of the parameter number. 
> All parameters with odd numbers (e.g. Puzzle, Solution, DH 
> ...) are critical.
> > 
> >> The HIH definitely needs to be in the signed part of the 
> packet. I would consider it a parameter that is related to 
> the BEX. The appropriate parameter range would be 0-1023. We 
> probably need to check the HIP extensions to find a free 
> number in this range. I'll do this tomorrow.
> >> 
> > 
> > I looked at the parameter numbers and I would suggest 
> number 715 because is located behind 705/Host_ID and it is 
> therefore close to it in the actual HIP control packet.
> > 
> > I checked the following things for all active HIP drafts 
> and documents that are accessible from the HIP WG status page:

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Jan 2010 09:57:27 -0800

> (for example the HI hi_hdr already indicates the RSA/DSA key type, the HIP_SIGNATURE contains SIG algorithm, etc.)

I envision multiple HIH per HI.  With a possible ranking of HIH for the HI.

>>> From: 	Tobias Heer<[email-masked]>
>>> To: 	Robert Moskowitz<[email-masked]>
>>>
>>>
>>>
>>> Hello Bob,
>>>
>>>        
>>> We are going to clearify this in 5201-bis and explicitly
>>>        
>> state what is a critical parameter.
>>      
>>>        
>>>>> Also what is the type value for HIH to get it in the
>>>>>            
>> 'right' place in the parameters?
>>      
>>>>>            
>>> * The next parameter higher than 705/HOST_ID is 768/Cert
>>>        
>> (RFC5201 and draft-ietf-hip-cert-02.txt)
>>      
>>>   - there is sufficient space between HIH and Cert to
>>>        
>> introduce new parameters
>>

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Tue, 12 Jan 2010 10:27:00 -0800

> > Have you considered extending the HOST_ID TLV by one field 
> to include HIH (rather than using a separate parameter)?
> > (for example the HI hi_hdr already indicates the RSA/DSA 
> key type, the HIP_SIGNATURE contains SIG algorithm, etc.)
> >    
> 

It seems hard to rank or negotiate the HIH since the HITs chosen in the HIP header are already derived using a particular HIH. If you chose a different HIH then you would start a new association using different HITs? Maybe I don't fully understand HIH yet...

-Jeff

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Jan 2010 10:45:37 -0800

> It seems hard to rank or negotiate the HIH since the HITs chosen in the HIP header are already derived using a particular HIH. If you chose a different HIH then you would start a new association us…

We are both correct  :)

The way that Tobias  and I are working out the changes to BEX to support 
HIH, I1 will have a HIT based on I's perfered HIH, but listing the HIHs 
I supports.  R1 would either just go with that or respond with R's 
perfered HIH.  In the later case, I would restart BEX with just one HIH, 
either what is in R1 or guessing it is the victim of a downgrade attack 
what I suspects is the right HIH to use.

Tobias, do you think it would be good to share your revised BEX exchange 
here?

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Tue, 12 Jan 2010 11:51:00 -0800

> either what is in R1 or guessing it is the victim of a 
> downgrade attack what I suspects is the right HIH to use.

thanks, that clears it up a bit
 
> Tobias, do you think it would be good to share your revised 
> BEX exchange here?

I overlooked this previous message which Miika pointed out to me:
http://www.ietf.org/mail-archive/web/hipsec/current/msg02770.html

> If so, it keeping HIH next to HOST_ID with the value 715 
> makes sense to me. Otherwise 63 would work. 

Again, I'd say make the value 715 if you plan to include it in ENCRYPTED, otherwise you may want to leave that value open for future parameters to be included in ENCRYPTED.

-Jeff

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Tue, 12 Jan 2010 11:56:35 -0800

> Again, I'd say make the value 715 if you plan to include it 
> in ENCRYPTED, otherwise you may want to leave that value open 
> for future parameters to be included in ENCRYPTED.

looking more carefully at that previous message, I guess there is no ENCRYPTED in the I1 packet that will include this info:

  "I1 packet has to be modified to include the hash, public keys and
  diffie-hellman algorithms supported by the Initiator in a new "algo"
  parameter.  The parameter should indicate which hash and public key
  algorithm the Initiator used to generate its HIT."

-Jeff

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Jan 2010 12:06:34 -0800

oops on that last transmit.  I "blame" it on a new install with a new 
version of Thunderbird....  Right...

>    algorithm the Initiator used to generate its HIT."

And thus a new downgrade attack that we need to mitigate.  And Tobias 
figured it out better than I did, so he gets to present it!

---

From: Tobias Heer <[email-masked]>
Date: Tue, 12 Jan 2010 22:24:47 +0100

Hi Jeff, 

>  algorithm the Initiator used to generate its HIT."

The purpose of the HIH parameter is to convey which hash function was used to generate the HIT used by a host. It is needed to verify the relation between HI and HIT because multiple algorithms. As far as I can see, there are four options to transfer the information:

a) as part of the HIT 
   - this option takes bits from the HIT that could otherwise be used for cryptographic purposes. It raised serious concerns about security and extendability.

b) as part of the HIP header (close to the HIT itself)
   - this would make sense from a conceptual point but the information is only needed when verifying the HI/HIT relationship. Putting it into every packet would be overkill.

c) as part of the HI parameter
   - this would make sense from a usage point of view but conceptually, the HIH is not part of the HI. Mixing these two might confuse people. Depending on the HIT in the HIP header, different HIs would be used.

d) as extra parameter
   - this provides a distinction between HOST_ID and HIH. However, the space requirements for an own TLV are slightly higher than for options a, b, and c.

I agree that c) and d) are valid and (in my opinion) good options.
 
In which packets do we need the HIH parameter? In my opinion, we need the parameter in all packets that may trigger a verification of the HI-HIT relationship. This means R1 and I2 during the BEX. In general every packet that contains a HI should probably have a HIH parameter. However, I am not sure if there are any extension for which this rule of thumb fails.

The list that Bob mentions is not necessarily a collections of HIH parameters. The HIH contains an index to the hash function used, the list contains several indexes. The list could be a separate parameter to avoid confusion and context-sensitive interpretation of the HIH. I will include some thoughts about crypto agility for the HIH below. The following text contains some thoughts for a BEX in which the Initiator does not know the HIHs supported by the Responder before the BEX:

     The Initiator initiates the BEX with an I1 packet. The
     Initiator picks source HIT and HIH based on local policies.

     The Responder responds to the I1 with an ordinary R1 with the
     exception that the R1 contains a list of supported HIH hash
     functions in the signed part of the R1.

     When receiving the R1, the Initiator verifies the signature
     in the R1 packet. If the signature is valid, it looks at the
     list of HIHs. If the previously selected initiator source HIT
     is amongst the supported HIHs, the Initiator continues with
     an I2 packet. If not it may restart the BEX with an I1 and a
     different source HIT.

     An attacker could try to launch a downgrade attack here but
     this will not be successful. I will explain the attack anyway.
     The attacker could store a old R1 message containing a HIH list 
     with weak algorithms and replay it to the initiator even if the
     Responder upgrades its algorithms to stronger ones. The initiator
     would restart its BEX after receiving this replayed R1 - using the
     weaker algorithms. It sends a new I1 with a weaker HIT. So far the 
     attack seems to be working. The next step is where it fails. The
     Responder will send an R1 message as response to the weaker source
     HI in the I1. This fresh R1 contains the HIH list (with the stronger
     algorithms) in the signed part of the packet, thereby revealing
     the attack. Moreover, the R1 counters will not match (huge gaps).
     This can even be noticed by security middleboxes.

     If the Attacker would decide to continue replaying the old R1
     to the new (downgraded I1), the initiator would send a I2 with
     an invalid R1 counter and a wrong HMAC because the DH public
     key in the replayed R1 are not valid any more. -> No successful
     downgrade due to the list in the R1.

I hope this gives enough context to understand my perception of the HIH parameter and the need for the HIH list.

Best regards, 

Tobias

--