Subject: [Hipsec] DH Group selection

From: [email-masked] (Henderson, Thomas R)
Date: Tue Dec 2 23:21:01 2003

> -----Original Message-----
> From: Robert Moskowitz [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2003 10:17 AM
> To: Julien Laganier; Kristian Slavov
> Cc: [email-masked]
> Subject: Re: [Hipsec] DH Group selection
>=20
>=20
> I am getting ready for a meeting, but IIRC, the DH group is=20
> selected in R1=20
> and I2.
>=20
> the Responder supplies what it will play with and the=20
> initiator selects=20
> what it can deal with.
>

The R1 could get large with public values if the responder=20
enumerates many possibilities.

i) unlike other parameters, there is no "MUST" implement
Group ID.  We have been using the 1536-bit MODP group in
interop testing-- perhaps require that one?

Perhaps we could state that the R1 contains at most (two?)
DIFFIE_HELLMAN TLVs, of which one must be the required
group?  If two are included, the non-mandatory Group ID
is understood to be the responder's preferred selection?

An alternative would be to require that initiators support
all Group IDs, and have the R1 just send a single TLV.

Or else Julien's suggestion of signaling in I1 (with the=20
resultant bid-down problem to deal with).

ii) there should be some text describing how the D-H
TLV is inserted and processed.

e.g. according to above: =20
"Responder includes in R1 a DIFFIE_HELLMAN TLV for
at most two Group ID that it can support.  The 1536-bit=20
MODP group MUST be among the one or two TLVs.  If two
TLVs are present, the second TLV corresponds to the=20
responder's preferred Group ID if different from the=20
mandatory Group ID."

"Initiator selects, from among the DIFFIE_HELLMAN TLVs
sent in the R1, a single Group ID and public value, and=20
sends only a single DIFFIE_HELLMAN TLV (corresponding
to the selected Group ID and its own public value) in=20
the I2.  The 1536-bit MODP group MUST be supported.
The initiator SHOULD select the responder's preferred=20
TLV unless it conflicts with local policy rules or=20
is not supported by the implementation."

  =20

---

From: [email-masked] (Petri Jokela)
Date: Wed Dec 3 03:10:01 2003

On Wed, 2003-12-03 at 06:54, Henderson, Thomas R wrote:

> The R1 could get large with public values if the responder 

This could be one possibility. With the currently specified
one D_H TLV there is no idea of putting any of the groups
mandatory. 

> all Group IDs, and have the R1 just send a single TLV.

This would be the best solution (I think). The Responder
is the "king" of the communication, thus it defines the 
group to be used.

> Or else Julien's suggestion of signaling in I1 (with the 

This has some effect on the Responder side. Currently,
the Responder doesn't have to do "anything" when I1 is
received. Just pull one R1 and send it back. If there is
a set of group-ids in the I1, the Responder must do some
processing before it can send the R1. 

/petri

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]

---

From: [email-masked] (Julien Laganier)
Date: Wed Dec 3 04:16:02 2003

> processing before it can send the R1.

If the responder precomputed eight R1 with the eigth differents 
possibles DH TLV's, it doesn't seems to require additionnal processing 
on the receiver side compared to the current behavior.

But AFAICS, the only defense against the bid-down attack of this scheme 
would be to specify a minimum security level that must be supported 
(says 1536). Thus, the security level cannot be bid-down to less than 
1536, while not precluding the responder from choosing a lower security 
level if it wants to (after all he's the king).

--julien

---

From: [email-masked] (Julien Laganier)
Date: Wed Dec 3 04:17:00 2003

--julien

---

From: [email-masked] (Petri Jokela)
Date: Wed Dec 3 06:57:01 2003

> on the receiver side compared to the current behavior.

The "hint" field in the I1 would require one additional TLV
that would be included in the I1 packet. The processing of 
this TLV must be done like the processing of other TLVs. The role
of the I1 packet also changes from a simple wake-up packet to a
negotiation packet. 

> level if it wants to (after all he's the king).

If we set a minimum security value, there is no reason why the
responder would go below that. In fact, the responder should never go
below the security level that is configured on it as the default. Thus, 
the negotiation would make sense only in case when the initiator 
requires higher security than the responder would by default
propose. 

My feeling is that negotiation would make things a bit more 
complicated, when compared to the requirement that everyone
must implement all the groups, responder selects the one that
it want's to use and the initiator either accepts or rejects
the proposal that arrived in the R1 packet. As I wrote earlier,
there is the problem, how to kick the responder to go for better
security than it's default value, if required by the initiator.

/petri

---

From: [email-masked] (Pekka Nikander)
Date: Thu Dec 4 10:42:01 2003

On Dec 3, 2003, at 14:31, Petri Jokela wrote:
> below the security level that is configured on it as the default.

Yes, there is: performance.  Some servers might prefer very
short D-H keys for performance reasons.  That is, some servers
might opt to use HIP mainly for mobility and multi-homing reasons,
or some other reasons but security, and want to use fairly short
D-H keys that just make MitM attacks hard but not impossible

> complicated,

I agree.

How about if Initiators MUST implement two groups, one
that is reasonable strong and another one that is fairly
weak, maybe deliberately "too" weak from a strict
security point of view.  A Responder would then be free
to use either of these?  That would prevent bidding-down
attacks since all Initiators MUST implement also the
stronger one, allowing the Responder to select it if it
wishes to have good security.

This could be combined with a simple (optional) I1 parameter
that would simply list what groups the Initiator support.
However, I don't see much usability for such.  Usually,
using any other than mandatory groups would be based on
mutual agreement, i.e. the Responder recognizing the
Initiator HIT.

--Pekka Nikander

---

From: [email-masked] (Julien Laganier)
Date: Fri Dec 5 03:23:01 2003

I agree.

>> My feeling is that negotiation would make things a bit more

Me too.

> wishes to have good security.

Sounds good to me.

> mutual agreement, i.e. the Responder recognizing the

If there are two mandatory security level (a weak and a strong), I agree 
that an optionnal I1 "DH group hint" would probably not be very useful.

So let's keep I1 simple and make two DH groups mandatory. What are we 
going to require? I guess 1 and 3 (or 4)?

Thanks,

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Fri Dec 5 04:24:00 2003

On Dec 5, 2003, at 10:57, Julien Laganier wrote:
>> security point of view.

I would suggest 1 and 3, with 6 as a strong SHOULD, meaning
that only PDAs and such may consider not to implement it.
Then when we start to consider 4 weak we can fairly easily
upgrade to 6.  All others would be OPTIONAL to implement.

Or should we define yet another group that would be still
weaker than 1?  Has anyone got performance figures for 1,
preferably both on slow (100 Mhz, PDA) and fast (2 GHz+,
server) hardware?

BTW, at least in -08 there seems to be a typo.
Aren't MODP 1536 Oakley group 3, not Oakley group 5?

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Fri Dec 5 09:31:02 2003

> upgrade to 6.  All others would be OPTIONAL to implement.

Fine.

> preferably both on slow (100 Mhz, PDA) and fast (2 GHz+,

I found in google that Id 1, 768-bit takes about 5.75 seconds on an 
Intel StrongARM PDA processor, but the frequency wasn't indicated (I 
guess it's about 100MhZ). It seems acceptable.

Another way of supporting slow devices might be to support Elliptic 
Curve DH exchange (Id 3 and 4 in RFC2409) which seems to be faster and 
smaller...

> Aren't MODP 1536 Oakley group 3, not Oakley group 5?

I don't think so. Quoting RFC3526:

--------------------------------
2.  1536-bit MODP Group

    The 1536 bit MODP group has been used for the implementations for
    quite a long time, but was not defined in RFC 2409 (IKE).
    Implementations have been using group 5 to designate this group, we
    standardize that practice here.
--------------------------------

And then 2048-bit has id 14, 3072 has 15, 4096 has 16, etc.

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Fri Dec 5 10:33:01 2003

> I don't think so. Quoting RFC3526:

You are right.  I got confused since RFC2412 first states...

> APPENDIX E The Well-Known Groups
>
>    The group identifiers:
>
>       0   No group (used as a placeholder and for non-DH exchanges)
>       1   A modular exponentiation group with a 768 bit modulus
>       2   A modular exponentiation group with a 1024 bit modulus
>       3   A modular exponentiation group with a 1536 bit modulus (TBD)
>       4   An elliptic curve group over GF[2^155]
>       5   An elliptic curve group over GF[2^185]

... but then later ...

> E.5. Well-Known Group 5:  A 1536 bit prime

Hence, RFC2412 is internally inconsistent, and apparently
the real definition matters, not the list of groups at
the beginning of Appendix E.

--Pekka

---

From: [email-masked] (Petri Jokela)
Date: Sat Dec 6 06:13:00 2003

> D-H keys that just make MitM attacks hard but not impossible

Yes, but then that lower security is the default for that server. If not,
then the server must do some decision making already when the I1 packet is
received. This must be based on the HIT in the I1 packet. Does this create
problems with large servers with lots of traffic?

> wishes to have good security.

If we decide to select two mandatory groups and one as a SHOULD with
better security (I refer to your other e-mail) what will happen to the
rest of the grouups? I just feel that either they become "de facto"
mandatory if servers start to use them more (otherwise it may be difficult
to contact some servers that use non-mandatory groups as default) or then
these non-mandatory groups will just not be used.

One problem is that the server never learns who actually responds and who
not to some R1 packets as it does not keep any information  about the
I1s and R1s. So, the server should make HIT based decisions and it should
be told which of the HITs should use these non-mandatory groups. I think
that if the two  (+ one) mandatory groups are decent, the operators
(server maintainers) use only the mandatory and nothing else. People are
lazy by their nature :-)

> mutual agreement, i.e. the Responder recognizing the

The GPRS is just too slow for this ssh-connection, so I won't fix any
typos :-)

/petri