MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Ren=E9_Hummen?= <rene.hummen@cs.rwth-aachen.de>
Content-transfer-encoding: quoted-printable
Date: Wed, 26 May 2010 15:47:18 +0200
Message-id: <279FACB2-90A1-465A-951B-7F1FC8214404@cs.rwth-aachen.de>
To: HIP WG <hipsec@ietf.org>
Subject: Re: [Hipsec] Conflicting text in RFC5201 - RFC5201-bis
Precedence: list

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.
>> =09
>> 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?
>=20
> 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=E9



--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://ds.rwth-aachen.de/members/hummen