Subject: Re: [Hipsec] Fwd: RFC5201 Ticket #33:

From: Miika Komu <[email-masked]>
Date: Mon, 03 Oct 2011 17:21:07 +0300

Hi Tobias,

I support your proposal.

On 09/24/2011 02:05 AM, Tobias Heer wrote:
> Sorry, I just realized that the previous mail was missing an important part: the problem description.
>
> Here is the description from the tracker:
>
> Issue 33: reusing DH public values
> http://trac.tools.ietf.org/wg/hip/trac/ticket/33
> ----------------------------------------------------------------
>
> 5201 states in the R1 processing section, regarding DH reuse:
> " If a future version of this protocol is considered, we strongly
> recommend that these issues be studied again."
> Has this issue been studied again? Should this text be replaced?
>
> ----------------------------------------------------------------
>
>
> Anfang der weitergeleiteten E-Mail:
>
>> Von: Tobias Heer<[email-masked]>
>> Datum: 23. September 2011 17:22:23 MESZ
>> An: HIP<[email-masked]>
>> Betreff: [Hipsec] RFC5201 Ticket #32:
>>
>> Hello,
>>
>> I did a literature search and the only problem I found was the "small subroup"
>> attack.
>>
>> The attack is described in RFC2785 (http://tools.ietf.org/html/rfc2785) and was
>> recently brought up again in [1].
>>
>> The issue is that an attacker (Initiator) can use a DH key with a smaller
>> subgroup. This makes finding the private key easier if this process can be
>> repeated (the Initiator repeats this procedure with different keys for the same
>> Responder key). Therefore, using a static Responder key can create
>> vulnerabilities against this attack.
>>
>> As described in RFC2785 and [1], validating the Initiator key according to
>> RFC2631 (http://tools.ietf.org/html/rfc2631#section-2.1.5) avoids this issue.
>> The validation process is simple: "
>>
>> 1. Verify that y lies within the interval [2,p-1]. If it does not,
>> 	the key is invalid.
>> 2. Compute y^q mod p. If the result == 1, the key is valid.
>> 	Otherwise the key is invalid.
>>
>> "[RFC2785]
>>
>>
>> TLS (RFC5246) addresses the very same issue by stating:
>>    "If the same DH keypair is to be used for multiple handshakes, either because
>>    the client or server has a certificate containing a fixed DH keypair or
>>    because the server is reusing DH keys, care must be taken to prevent small
>>    subgroup attacks. Implementations SHOULD follow the guidelines found in
>>    [SUBGROUP]." [SUBGROUP] = [RFC2785].
>>
>> I propose to add a similar wording to the text passage in RFC5201-bis that
>> discusses repeated use of the Responder's DH key.
>>
>> ############### Text for RFC5201-bis ###############
>> "If the Responder uses the same DH keypair for multiple handshakes. It must
>> take care to avoid small subgroup attacks [RFC2785]. To avoid these attacks,
>> when receiving the I2 message, the Responder SHOULD validate the Initiators DH
>> public key as described in [RFC2785] Section 3.1. In case the validation fails,
>> the Responder MUST NOT generate a DH shared key and MUST silently abort the HIP
>> BEX."
>> ############### /Text for RFC5201-bis ###############
>>
>> Do you have comments or suggestions?
>>
>> Cheers!
>>
>> Tobias
>>
>> References: [1] Alfred Menezes and Berkant Ustaoglu. "On reusing ephemeral keys
>> in Diffie-Hellman key agreement protocols". International Journal of Applied
>> Cryptography (January 2010), pp. 154-158.
>>
>>
>>
>> --
>> Dipl.-Inform. Tobias Heer, Ph.D. Student
>> Chair of Communication and Distributed Systems - comsys
>> RWTH Aachen University, Germany
>> tel: +49 241 80 207 76
>> web: http://www.comsys.rwth-aachen.de/team/tobias-heer/
>> blog: http://dtobi.wordpress.com/
>> card: http://card.ly/dtobi
>> pgp id: AEECA5BF
>>
>> _______________________________________________
>> Hipsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 3 Oct 2011 11:30:14 -0700

> > the Responder MUST NOT generate a DH shared key and MUST silently

I am fine with the above, but what about possibly generating a new NOTIFY in response to this (such as:

     INVALID_PUBLIC_KEY                     13

       The received public key is considered to be invalid.

These notifications can sometimes be more helpful to debugging things than trying to interpret silent discards.

Note that RFC 2631 hints of IPR on the proposed mechanism:
http://tools.ietf.org/html/rfc2631#section-2.1.5

---

From: Tobias Heer <[email-masked]>
Date: Thu, 06 Oct 2011 12:55:49 +0200

> These notifications can sometimes be more helpful to debugging things than trying to interpret silent discards.
Thanks.

Since the verification happens after the puzzle verification and the return routability check, it should be safe to send a response. However, since there is no existing HIP association at that point, an ICMP message would be better (see RFC5201 Section 4.3). Did you have a specific reason to suggest a NOTIFY?

BR,

Tobias

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 6 Oct 2011 10:48:40 -0700

> -----Original Message-----
> From: Tobias Heer [mailto:[email-masked]]
> Sent: Thursday, October 06, 2011 3:56 AM
> To: Henderson, Thomas R
> Cc: HIP
> Subject: Re: [Hipsec] Fwd: RFC5201 Ticket #33:
> 
> 
> > These notifications can sometimes be more helpful to debugging things
> than trying to interpret silent discards.
> >
> Thanks.
> 
> Since the verification happens after the puzzle verification and the
> return routability check, it should be safe to send a response.
> However, since there is no existing HIP association at that point, an
> ICMP message would be better (see RFC5201 Section 4.3). Did you have a
> specific reason to suggest a NOTIFY?
> 

I don't care strongly, but I would note that the current specification seems to limit the generation of ICMP to the case of the host not wanting to enter into HIP association at all due to policy.  The above seemed to me to be a case of signaling a parameter problem with the peer's key, which seemed to be covered under the range of NOTIFICATION values between 11-20.

It seems to me that the last sentence of section 4.1.5 " A HIP NOTIFY message is not used because no HIP session exists between the two hosts at that time." is not consistent with some cases already defined for sending a NOTIFY (some of which are sent despite no HIP session existing).  Perhaps it could be changed to "A HIP NOTIFY message is not used because an ICMP message could be generated without further involvement of the HIP process, particularly if policy filtering is performed separately from HIP processing."  

- Tom