Subject: [Hipsec] RE: packet processing text

From: [email-masked] (Henderson, Thomas R)
Date: Fri Sep 5 19:02:01 2003

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]
> Sent: Friday, September 05, 2003 6:11 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: packet processing text
>=20
>=20
> Henderson, Thomas R wrote:
> > Here is some draft text that is a start to section 8 material.
> > Embedded in the text are some notes and questions that may
> > generate some more discussion.  Feel free to further edit.
> > I did not touch the BOS and CER packet processing.
>=20
> Thanks a lot!
>=20
> I am right now editing the text to XML format.
>=20
> Two questions so far:
>=20
> >    The R1 packet may have the A bit set-- in this case, the system
> >    MAY choose to refuse it by dropping the R1 and returning=20
> to state E0.
> >    [Q.  DoS attack by early spoofed anonymous R1, similar to early=20
> >    false DNS replies?].  If the A bit is set, the=20
> Responder's HIT is=20
> >    anonymous and should not be stored or validated against a Host=20
> >    Identity. =20
>=20
> I don't understand why the HIT should not be validated. =20
> Please explain.
>=20

I didn't see the utility of validating it, since it is anonymous. =20
On the other hand, I don't see any harm in validating it, for
consistency sake.  I'm fine with deleting "or validated".=20

---

From: [email-masked] (Pekka Nikander)
Date: Mon Sep 8 03:04:00 2003

Henderson, Thomas R wrote:

>>>  If the A bit is set, the Responder's HIT is 
>>>  anonymous and should not be stored or validated against a Host 
>>>  Identity.  
>>
>> I don't understand why the HIT should not be validated.  
>> Please explain.
> 
> I didn't see the utility of validating it, since it is anonymous.  

I see.  We would have a problem with the later HIP messages,
though.

I think that there are two separate issues here:
- validating that a HIT and an HI correspond to each other
- validate the signatures, using a HI, in the messages

If we do not check that the HITs and HIs correspond to
each other, that would allow an attacker to select a HIT
that matches with the HIT of some other host.  However, since
there is the possiblity of genuine collisions, we have to be
able to handle that situation anyway.  On the other hand,
such a situation may trigger slow or less tested code on
some implementations, and thereby add the possibility of
various nasty implementation dependent attacks.

Two more things are that the HITs are used in constructing
the puzzle and KEYMAT construction.  I don't know if either
of them matter, though.

What comes to the signature checks, we could run the base
exchange and _not_ validate (or even use) the signatures at
all.  In that case we would just have a purely anonymous
D-H secret.  However, we do not currently really use the
D-H secret in protecting the mobility management or even
the NES message.  Maybe we should; I've been thinking
about adding an HMAC to them.  The HMAC would use the
HIP SA, and therefore the D-H secret.
Opinions on this?

Another issue is if we use anonymous HI in one end and an
non-anonymous in the other one.  In that case only the
anonymous host is able to detect possible MitM attackers,
which MAY open up some nasty DoS triangle based DoS scenarios.
(I am not sure though.  I haven't had a suitable amount of
coffee yet to be really able to think clearly.)

Yet another problem might come with session continuity.  That
is, if one of the end-points crashes but if they still continue
to use the same HIs, the hosts might not be able to securely
re-establish the session.

> consistency sake.  I'm fine with deleting "or validated". 

Given all the reasons above, I would like to fall to the
safe side and remove the provision of not validating the HITs.

--Pekka Nikander

---

From: [email-masked] (Andrew McGregor)
Date: Mon Sep 8 06:52:00 2003

-----BEGIN PGP SIGNED MESSAGE-----

> HIP SA, and therefore the D-H secret.

I think it's a good idea; for the peer, what is the point in running a 
signature check in the presence of an HMAC?  If we have the case where 
there is no forwarding agent, just two peers one of whom happens to have 
changed address, why not just check the HMAC and be done?  We still must 
generate signatures, as we don't necessarily know if there is a forwarding 
agent (one may appear on a new path during mobility, after all), but we 
don't need to check them in all cases.

We have to assume that the DH secret is unknown to attackers; but then, if 
they know that, we're pretty much done for.

Andrew

- --------
Andrew McGregor
Director, Scientific Advisor
IndraNet Technologies Ltd
http://www.indranet.co.nz/
Office: +64 3 3656485
Mobile: +64 21 898856

---

From: [email-masked] (Pekka Nikander)
Date: Mon Sep 8 07:00:01 2003

Andrew McGregor wrote:
>> ... However, we do not currently really use the
> changed address, why not just check the HMAC and be done? 

That is the intention.

> We still must generate signatures, as we don't necessarily know if
> there is a forwarding agent (one may appear on a new path during
> mobility, after all), but we don't need to check them in all cases.

Exactly.

I'll add an HMAC to REA and NES in the next versions, unless
someone objects.

--Pekka Nikander