Subject: Last e-mail in this thread -- was -- Re: [Hipsec] Moving the basespec forward

From: [email-masked] (Henderson, Thomas R)
Date: Mon Sep 13 18:45:00 2004

> -----Original Message-----
> From: Yogesh Prem Swami [mailto:[email-masked]]=20
> Sent: Monday, September 13, 2004 12:21 PM
> To: ext Pekka Nikander
> Cc: [email-masked]
> Subject: Last e-mail in this thread -- was -- Re: [Hipsec]=20
> Moving the basespec forward
>=20
>=20
> 4th, and last! I promise.=20
>=20
> ext Pekka Nikander wrote:
>=20
>=20
> >> Specific comments (assuming people want to keep the key=20
> exchange as is.)
> >>
> >> * Page-12: I-1 needs to have a type which says what DH=20
> groups Initiator
> >>            supports. We should not assume that I-1 can/will-want to
> >>            handle all the DH groups. Additionally, if=20
> Responder cannot
> >>            select any of the proposed groups, it should=20
> say something.
> >=20
> >=20
> > Good point.  I think we have discussed this before, but I don't know
> > what were the thoughts about this.  Anyone?
>=20
>=20
> I read Mika's comments and the old discussion, but I still think it's
> useful to put HIP-TRANSFORM in I1. It's possible that the=20
> Initiator and
> Responder both consider a certain group to be safe, but the default
> choice on the two sides could be different. In those cases,=20
> HIP-XFRM in
> I1 will help. Also, just because I1 proposes a HIP transform,=20
> Responder
> doesn't have to accept it (so there is no chance of attacker degrading
> the quality of SA). It might send it's own choice anyways
> (falling back to the present scheme, to some extent.)
>=20

My recollection was that the lack of I1 preferences and nonces was=20
because R1s are precomputed, and it didn't seem to be offering
anything since both sides could still get what they wanted based
on advertisement or choice.=20

>=20
> >=20
> >> * Page-12: I think all messages, including I1 should contain a
> >>            nonce/cookie (similar to R1 counter to match=20
> incoming and
> >>            outgoing requests) in addition to HITs. For example,
> >>            If the local policy requires one SA per USER_ID,
> >>            then the present key exchange will not be  able=20
> to meet these
> >>            requirements.
> >=20
> >=20
> > I don't understand this comment.  Please elaborate.
> >=20
>=20
>=20
> Okay, may be I misunderstood, so let me ask a question. Let's=20
> say I want
> to have 3 different SA between same  hosts at the same time=20
> (because my
> local policy requires on 1 SA per TCP connection and all three TCP
> connections start at once.) How does HIP disambiguate between these
> three parallel ongoing key exchange. Does it mean SA creating=20
> should be
> sequential. I guess this is what you mean by coarse granular key
> exchange for HIP, right? Some text in either of the two drafts
> (base/arch) will help.
>=20
> > (Editorial comments left to Petri, the current editor.)
> >=20
> >>             I would personally prefer the entire signature
> >>             out from R1 (i.e., there is no need for=20
> HIP_SIGNATURE_2).
> >>             Removing SIG_2 in R1 doesn't hurt MITM issues=20
> because R2
> >>             is still signed.
> >=20
> >=20
> > No, it doesn't protect against MitM.  It is there to protect the
> > hosts from certain kinds of replay attacks.  I think the draft
> > says it somewhere, but maybe it doesn't?
> >=20
> >=20
> >>             Additionally, I would modify I2 to
> >>             contain HMAC and signature (similar to R2) than just
> >>             a signature. HMAC on I2 proves a lot more than the
> >>             signature alone.
> >=20
> >=20
> > How come?  I don't understand, but maybe I'm blind.  Supposedly
> > the Responder hasn't got any state when it gets I2.
>=20
>=20
> Wow! back up a little bit. When Initiator receives R1, it can compute
> the session  key. If you want to follow the design choice of=20
> sigma, you
> should  provide a proof of possession of the ephemeral key by=20
> the HMAC,
> not just  the signature as it is in the draft right now.
>=20
> But then, this makes me ask another question. How does the=20
> Responder get
> the public-key of the Initiator. If it's from DNSSec, then it's useful
> to use HMAC. If not, then why bother--you are anyway willing to risk
> identity mis binding.
>=20
> >=20
> >> * Page-15: ""The packets R1, I2, and R2 implement a standard
> >>               authenticated DH..."". Draft needs a=20
> reference here. I
> >>               guess you mean ISO based scheme here, right?
> >=20
> >=20
> > A reference to Hugo's SIGMA paper?
> >=20
> > Hugo Krawczyk: SIGMA: The 'SIGn-and-MAc' Approach to Authenticated
> > Diffie-Hellman and Its Use in the IKE-Protocols. CRYPTO=20
> 2003: 400-425
> >=20
>=20
> I disagree that the present key-exchange is based on SIGMA.=20
> That was the
> whole point of my question for a reference :-)
>=20
>=20
> >> * Page-16: I'm not sure what is the attacker going to gain from
> >>            replaying R1 and I2. The attacker cannot derive the
> >>            DH keys by replaying R1/I2. She might be able=20
> to force the
> >>            Initiator/Responder to solve the puzzle (but=20
> that is a lot
> >>            less computation than the Signature verification).
> >=20
> >=20
> > Not necessarily.  With large K, solving the puzzle takes a=20
> lot of CPU.
>=20
> This is unnecessary protection, IMO. Also, what is the order of
> processing for these messages, i.e., do you fist verify the=20
> signature or
> compute the solution. If you verify the signature first -- as you
> should -- then aren't you opening up to some kind of DoS? Note that a
> counter (R1_COUNTER) doesn't help because a smart blind attacker can
> just send a value in the upper quarter of the number space with high
> probability of success, so the  primitive sequence number check before
> signature verification will not help much.

If the attacker is blind, then it doesn't know when an initiator
has sent the I1, right?  The first check in R1 processing is whether
initiator is in state I1-SENT or I2-SENT with respect to that responder.

If the attacker can snoop the packets, then there is a possibility
to generate bogus R1s with slightly higher R1_COUNTERs and force=20
initiator to validate lots of signatures (after the first presumably=20
good one) but a smart initiator might get wise to the failed signatures
after a while.

>=20
> >=20
> >>            IMO, if more than one R1 or I2, they should all be
> >>            considered valid until a right authentication comes.
> >>            Following IKEv2 design choices...
> >=20
> >=20
> > Good point.  Please elaborate so that we understand better,=20
> I haven't
> > been following IKEv2.
>=20
>=20
> One way to get rid of the signature in R1 is to consider all R1s as a
> valid response. Since only a valid Initiator can provide an=20
> R2 (because
> of HMAC), its safe to delete the other invalid R1s after the key
> exchange is completed. IKEv2 draft does a better job than me in
> explaining these things ... so please see that.

Wouldn't that lead to a way for MitM to get initiator to disclose
encrypted HI?  Plus, this would seem to negate the possibility
to encrypt and piggyback data on the I2.

>=20
> >=20
> >> * Page-16: More text is needed about caching the random=20
> number r of g^r
> >>            in R1. BTW, how does this protocol behave if the random
> >>            number r is deleted and g^r arrives after that.=20
> It should
> >>            send new g^r and the Initiator should be able=20
> to accept it
> >>            (section 8.7 doesn't seem to say anything=20
> either. I might
> >>            have missed it.)
> >=20
> >=20
> > Suggested text to be added?
>=20
>=20
> You might want to check JFK paper (Steve Bellovin, et. al. "Just Fast
> Keying) on r caching.
>=20
> >=20
> >> *  Page-37: HOST_ID should probably be renamed USER_ID.=20
> This field also
> >>             needs a OPAQUE type for unknown HOST_ID types (e.g.,
> >>             cell-phone numbers etc).
> >=20
> >=20
> > Good point, though I'm a little bit reluctant as it slightly adds
> > complexity.  HIP is a _Host_ Identity Protocol, after all,=20
> even though
>=20
> No. That's not what I meant. In the draft you refer to e-mail address,
> FQDN, etc as HOST_ID (you need these for polices, right?). This is
> confusing and it should be renamed USER_ID, IMO. Also adding an OPAQUE
> field there doesn't add complexity--or maybe this time I am=20
> "blind." :-)

Do you mean unknown Domain Identifier types?  Not sure I follow.
Are you saying that HOST_ID might not be a public key?

>=20
> > various people (me included) have pondered issues like supporting
> > multiple Host Identities within a multi-user host etc.
> >=20
> >> *  The SPIs needs to be encrypted. It provides limited user traffic
> >>    confidentiality.
> >=20
> >=20
> > Definitely not.  Here I (and I guess a number of other people)
> > disagree strongly.
>=20
>=20
> I can live with a clear SPIN--although it does make traffic
> confidentiality little worse.
>=20
> >=20
> > HIP has been explicitly designed to be middle box friendly, which
> > IKE (including IKEv2) is not.
> >=20
>=20
> Well IKEv2 does not have any problems (or it's being fixed)=20
> with middle
> boxes to the best of my knowledge.
>=20
> >> To summarize, I would prefer the key exchange to look=20
> something like:
> >>
> >> I->R:   IP( HIP(
> >>         I1-COUNTER    /* just a random number */
> >>         R1-COUNTER    /* =3D 0 */
> >>         HIP-TRANSFORM /* with list of DH groups */
> >>     ))
> >=20
> >=20
> > Responder could select a suitable pre-computed R1 from a pool,
> > using the suggested D-H?  Adding optional HIP-TRANSFORM here
> > might be a good idea.  Or even make it mandatory, for simplicity's
> > sake?
> >=20
> > I don't understand the need for the I1 nonce.  To remove the
> > need for R1 signature?
> >=20
>=20
> But also to allow parallel SA creation. May be you don't want to
> consider in the design choice.
>=20
> > Didn't we discuss that before?  Anyone remembers the conclusions
> > or cares to dig up the archives?
> >=20
> >>                 HOST_ID        /* ? why is this here in clear ? */
> >>                                /* Probably better to move it to R2.
> >>                                ID protection from passive=20
> attacker is
> >>                                still a good idea.
> >>                                 */
> >=20
> >=20
> > Maybe, but IMHO not now.  Something to remember for the=20
> next revision.
> >=20
> > See Jukka Ylitalo and Pekka Nikander,  "BLIND: A Complete Identity
> > Protection Framework for End-points",  to appear in=20
> Security Protocols,
> > Twelfth International Workshop,  Cambridge, 24-28 April, 2004.
> >=20
>=20
> Sure. Thanks.
>=20
> >>         no change, except add a new field HMAC.
> >>                 I am not sure if signing the whole message has
> >>                 any advantage over just encrypting the=20
> HMAC with private
> >>                 key.
> >=20
> >=20
> > You forget middle boxes.  If you have the signature, there is no
> > explicit benefit from the HMAC.  If the responder knows the=20
> initator's
> > identity, it can verify the signature before constructing=20
> the D-H keys.
>=20
>=20
> Agreed, but on the other hand, HMAC is more resistant to=20
> attacks due to
> HASH collision. With SHA0  nearly colliding, and MD5 gone, my
> confidence in SHA1 is very low. But HMAC-SHA (or MD5 for that matter)
> is still relatively secure.
>=20
> So much form me! Hope this is useful discussion.
>=20

yes, very.

Tom

---

From: [email-masked] (Yogesh Prem Swami)
Date: Tue Sep 14 01:18:00 2004

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0F77523C0157D687D301B1A5
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Continuing...

ext Henderson, Thomas R wrote:

<text removed>

> My recollection was that the lack of I1 preferences and nonces was 
> on advertisement or choice. 
> 

In some cases it's possible that the responder will have a cache of 
multiple g^r corresponding to different group and one preferred group 
out of those. In the present scheme, the responder will choose the 
preferred group, and send it in R1. But if the Initiator does not 
support this group, then the connection will fail, right? (I might have 
missed something.) It's still however possible that Initiator and 
responder do have a common group. By putting HIP-XFRM in I1, it will 
help in these cases.

<text removed>

>>processing for these messages, i.e., do you fist verify the 
>>signature or
> to generate bogus R1s with slightly higher R1_COUNTERs and force 
> initiator to validate lots of signatures (after the first presumably 

I don't have very strong opinion about removing SIGNATURE_2. To me SIG_2 
doesn't seem to provide much gain compared to computation involved.

Consider how much computation is needed before the Initiator sends I2: 
it needs to calculate a) the signature-verification of SIG_2 ( = 1 MAC, 
one public-key encryption), b) the  puzzle solution, c)  g^y generation, 
d) (g^x)^y  (to get the key, if we want to follow SIGMA), e) and one 
more SIGNATURE (for I2).

That's 4 exponent computation (and a lot of HASH computation if the 
puzzle is tough) before sending I2. Removing SIG_2 will reduce it to 3 
exponent calculation (not a bit feat, but useful on some low computation 
power environments, nonetheless.)

<text removed>

>>field there doesn't add complexity--or maybe this time I am 
>>"blind." :-)
> 
> 

I misunderstood this part (eh! the PKI tunnel vision. :-)). I was 
thinking that in addition to HIs, there might be a need for another 
field such as e-mail address or FQDN for policy purposes. For example, 
even though every host inside a corporation might be able able to have a 
security association with any other host, not every user will get the 
same level of access to resources. In those cases, these USER IDs might 
be useful.

I guess HIP doesn't support this yet, right? (or, perhaps requires every 
user to have their own HIs, which could be hard operationally).

Thanks
Yogesh

--------------enig0F77523C0157D687D301B1A5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig0F77523C0157D687D301B1A5--

---

From: [email-masked] (Miika Komu)
Date: Tue Sep 14 03:29:00 2004

On Mon, 13 Sep 2004, Henderson, Thomas R wrote:

> > Agreed, but on the other hand, HMAC is more resistant to
> > attacks due to

Just to separate rumours from facts, see:

http://www.sandelman.ottawa.on.ca/ipsec/1996/05/msg00021.html

Q: Is SHA-1 broken?
A: No. Eli Biham described attacks that work against simplified versions
of SHA-1, but there is no suggestion that any known attack technique can
be extended to break the full SHA-1. (The attacks presented against SHA-0
are also effective against a 36-round reduced variant of SHA-1, but the
standard version of SHA-1 uses a full 80 rounds and has not been
compromised.) Although there has been speculation that SHA-1 will fall
soon, extending the current results to the full SHA-1 appears to be an
extremely difficult problem and we do not anticipate such an attack in the
immediate future. Nevertheless, the new results certainly do merit a full
re-evaluation of all hash functions.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: [email-masked] (Pekka Nikander)
Date: Tue Sep 14 06:38:01 2004

> support this group, then the connection will fail, right? (I might 
> have missed something.) It's still however possible that Initiator and 

I think this is a valid comment, and that we should either

   a) add HIP transforms as a mandatory parameter to I1, or

   b) write a separate extension draft that defines an optional
      HIP transforms parameter that MAY be included to I1

I am in favour of b), but can live with a).  Others?

--Pekka

---

From: [email-masked] (Pekka Nikander)
Date: Tue Sep 14 06:40:00 2004

> I don't have very strong opinion about removing SIGNATURE_2. To me 
> SIG_2 doesn't seem to provide much gain compared to computation 
> involved.

The Initiator does not need to verify SIG_2 unless is suspects
that it may be false.

It looks like we can close this piece of this discussion.

> ... I was thinking that in addition to HIs, there might be a need for 
> another field such as e-mail address or FQDN for policy purposes. For 
> example, even though every host inside a corporation might be able 
> able to have a security association with any other host, not every 
> user will get the same level of access to resources. In those cases, 
> these USER IDs might be useful.
>
> I guess HIP doesn't support this yet, right?

Right.  The idea is that to support multiple users with different
security levels, you need to represent each user with a different HIT.
Architecturally that is easy, but not easy to implement.

--Pekka

---

From: [email-masked] (Yogesh Prem Swami)
Date: Tue Sep 14 11:50:00 2004

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCF5BD28DAA567CF86A5212DA
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Miika,

Thanks for pointing this out. I realized I was not careful in my 
wording, and didn't mean to give the impression that SHA1 is any less 
secure than what it was before crypto '04.

I will respond to other mails from Pekka somewhat later on.

Thanks
Yogesh

> re-evaluation of all hash functions.

--------------enigCF5BD28DAA567CF86A5212DA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigCF5BD28DAA567CF86A5212DA--

---

From: [email-masked] (Miika Komu)
Date: Tue Sep 14 15:32:00 2004

> I am in favour of b), but can live with a).  Others?

I have another alternative in my mind that tries to avoid the introduction
of new parameters in I1. It offers only a partial solution to the problem
as it mostly concerns devices with limited CPU resources. The idea is that
we could have a new "G" flag which the initiator sets if it requests the
lowest possible DH group.

I had a small off-line conversation with Jeff on a fourth alternative that
does not work, but perhaps is worth mentioning. The idea is to move the DH
parameter from R1 to R2, and to put a DH_GROUP_TRANSFORM parameter into
R1. This does not work for two reasons. First, the initiator needs to have
the responder's DH in R1 to be able to encrypt it's HI in I2. Second, the
initiator needs to validate the HMAC in R2, but it is not possible
because the DH is inside the invalidated R2.