Re: [Hipsec] Conflicting text in RFC5201 - RFC5201-bis

[René Hummen <[e-mail]>]

On May 26, 2010, at 12:59 PM, Samu Varjonen wrote:
> Tobias Heer wrote:
>> Hello, I have a question regarding some text in RFC5201 that conflicts with the crypto agility that we envisioned.
>> 	
>> The new BEX will have to start the negotiations of the DH groups already in I1 to allow the Responder to pick a sensible DH group (there are simple countermeasures against downgrade attacks, too, so don't worry).
>> Therefore, the I1 becomes slightly more important than it was (although it stays unsigned and cheap).
>> In Section 4.1 RFC5201 states:
>> ...
>> 705          The Initiator first sends a trigger packet, I1, to the  706          Responder.  The packet contains the HIT of the Initiator  707          and possibly the HIT of the Responder, if it is known.  708          Moreover, it contains a list of Diffie Hellman Group IDs  709          supported by the Initiator.  Note  710          that in some cases it may be possible to replace this trigger  711          packet by some other form of a trigger, in which case the  712      protocol starts with the Responder sending the R1 packet. ...
>> With the DH group negotiations already starting in I1 it becomes difficult to omit the I1 (you can do it but you lose DH crypto agility).
>> Moreover, I doubt that omitting the I1 works well even without considering the DH group negotiations because some of the measures to keep the Responder stateless until I2 rely on having information from the I1 (IP address or HIT) for the puzzle/ opaque data field.
>> My questions are: Is anyone using or does anyone intent to use this omission of the I1?
> 
> Check out draft-ietf-hip-hiccups-02 Section 5.3
> "
>  A host receiving a HIP DATA packet makes decision whether to process
>  the packet or not.  If the host, following its local policy, suspects
>  that this packet could be part of a DoS attack.  The host MAY respond
>  with an R1 packet to the HIP DATA packet...
> "

You could adapt draft-ietf-hip-hiccups-02 Section 5.3 as follows, in order to support the crypto agility changes introduced in RFC5201-bis:
"
...If the host chooses to
  respond to the HIP DATA with an R1 packet, it creates a new R1 or
  selects a precomputed R1 according to the format described in
  [RFC5201] Section 5.3.2.
"
Add:
"The host should thereby choose its preferred DH group for the DH value."

This way, the BEX can continue as supposed by hiccups, if the two hosts agree on the DH group. Otherwise, the host, that was initially sending the HIP DATA packet, would advertise the supported DH groups by sending a corresponding I1.

>> Is there any specification on how to do it (at least this is the only place in 5201 where it is mentioned).
>> Do we need this feature because there are cases where you cannot send an I1?
>> And finally: can we live without that note?
>> Of course, even if we skip it there is nothing that will keep someone defining it as an extension to the base specs if it is needed in the future.
>> Thanks for any input.
>> Tobias


Ciao,
René



--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.rwth-aachen.de/members/hummen