Subject: [Mip6] Substitute "high risk" for "mitigated risk" in Security Considerations of draft-ietf-mip6-bootstrapping-split-02.txt

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Apr 2006 20:12:19 +0200

James,

Per your request here are some comments and text suggestions on some 
parts of the Security Considerations section of
draft-ietf-mip6-bootstrapping-split-02.txt.

> The risk in Case 1 is mitigated because the Mobile Node is
                         ^^^^^^^^^
                         Substitute "high" for "mitigated" because it is
very easy to set up an AP running DNS Server, HA and even fake CA, thus
fooling MN to send all its traffic to it.

> Thus, an attacker would have to set up both a bogus DNS server and a 
> bogus Home Agent,

This leaves the reader with the impression that it is difficult to set
up a rogue laptop being AP, DNS, HA and CA.  It's not: hostap, bind9,
mipl and open-ssl.

> and provision the Home Agent with a certificate that a victim Mobile 
> Node could verify.

Once the MN sends all its traffic to the rogue AP being CA, the MN will
query that CA about cert validity and the rogue CA will reply
positively, because it's rogue.

> If the Mobile Node can detect that the certificate is not 
> trustworthy,

That's a big IF.  Do you have in mind a legitimate MN with two 
interfaces, one spoofable and one completely secure?  Because if the MN 
is attached only to the rogue AP leading to a fake Internet, how could 
it securely verify the certificate?

> the attack will be foiled when the Mobile Node attempts to set up the
>  IKE SA.

Yes, provided that big IF materializes into a yes.  But I am pretty sure 
a 802.11 laptop won't do normal traffic on one interface and security
verification traffic on another more secure interface.

So I suggest substituting High for the Mitigated cited previously.

> The risk in Case 2 is limited for a single Mobile Node to Home Agent 
> transaction if the attacker does not possess proper credentials to 
> authenticate with the Home Agent. The IKE SA establishment will fail 
> when the attacking Mobile Node attempts to authenticate itself with 
> the Home Agent. Regardless of whether the Home Agent utilizes EAP or 
> host-side certificates to authenticate the Mobile Node, the 
> authentication will fail unless the Mobile Node has valid 
> credentials.

I agree with this.  However the previous risk is relatively high, not
mitigated.  Would you agree?

> Explicit security measures between the DNS server and host, such 
> DNSSEC [16] or TSIG/TKEY [17] [18] can mitigate the risk of 1) and 
> 2), but these security measures are not widely deployed on end nodes.

Substitute "1) and 2)" with "2) only" because I think it's easy to 
set-up a fake DNS server appearing as DNSSEC to MN, with the laptop 
hostap I described previously.

Or maybe some text is needed in this section that states that the MN to 
the first real IP hop (not virtual) connection is secured?  There is no 
such text currently here.  I mean something about link-layer security?

Alex

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Apr 2006 14:51:11 -0700

> Per your request here are some comments and text suggestions on some parts 
> of the Security Considerations section of

The key point here is that the MN needs to perform IKE with the home agent. 
If the home agent's cert fails to authenticate, the MN will know that there 
is a problem. The text further along in this section says that.

>> and provision the Home Agent with a certificate that a victim Mobile Node 
>> could verify.
>

The MN has got a set of root certs that it will check the rogue CA's 
against. If it doesn't authenticate, then the MN will simply not use the 
bogus HA.

>> If the Mobile Node can detect that the certificate is not trustworthy,
>
> That's a big IF.  Do you have in mind a legitimate MN with two interfaces, 
> one spoofable and one completely secure?  Because if the MN is attached 
> only to the rogue AP leading to a fake Internet, how could it securely 
> verify the certificate?
>

I have in mind a MN with a collection of root certs that it chains back to 
to check the HA's proffered cert. That is how IKE cert-checking works. If 
you think it would be clearer, I can spell this out, but we assumed a 
certain level of understanding about IKE and cert-checking when we wrote 
this, and it seems a bit redundant to have to repeat everything in the IKE 
document.

> Yes, provided that big IF materializes into a yes.  But I am pretty sure a 
> 802.11 laptop won't do normal traffic on one interface and security

I'm not sure I understand what your point is. There is no need for two 
interfaces. All that's needed is IKE and the standard way IKE cert-checking 
is done.

>> authenticate with the Home Agent. The IKE SA establishment will fail when 
>> the attacking Mobile Node attempts to authenticate itself with the Home 
>> Agent. Regardless of whether the Home Agent utilizes EAP or host-side 
>> certificates to authenticate the Mobile Node, the authentication will 
>> fail unless the Mobile Node has valid credentials.
>

See above.

>> Explicit security measures between the DNS server and host, such DNSSEC 
>> [16] or TSIG/TKEY [17] [18] can mitigate the risk of 1) and 2), but these 
>> security measures are not widely deployed on end nodes.
>
> Substitute "1) and 2)" with "2) only" because I think it's easy to set-up 
> a fake DNS server appearing as DNSSEC to MN, with the laptop hostap I 
> described previously.
>

Link layer security is won't help much.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 00:22:28 +0200

James Kempf wrote:
>> Per your request here are some comments and text suggestions on 
>> some parts of the Security Considerations section of 
>> ^^^^^^^^^ Substitute "high" for "mitigated" because it is very easy
>>  to set up an AP running DNS Server, HA and even fake CA, thus 
>>> Thus, an attacker would have to set up both a bogus DNS server 
>>> and a bogus Home Agent,
>> 
>> This leaves the reader with the impression that it is difficult to 
>> set up a rogue laptop being AP, DNS, HA and CA.  It's not: hostap, 
>> bind9, mipl and open-ssl.
>> 
> 
> The key point here is that the MN needs to perform IKE with the home 
> agent. If the home agent's cert fails to authenticate, the MN will 
> know that there is a problem. The text further along in this section 
> says that.

I've read that text, and still have doubts.

>>> and provision the Home Agent with a certificate that a victim 
>>> Mobile Node could verify.
>> 
>> Once the MN sends all its traffic to the rogue AP being CA, the MN 
>> will query that CA about cert validity and the rogue CA will reply

All the root certs will point to the rogue AP.  The HA will not 
understand messages coming from the MN (because encrypted with 
legitimate HA's or CA's public keys), but the MN will understand all 
messages coming from the rogue AP/HA/CA.  The HA will tell MN "Binding 
Refresh Request", or "RA you're at home" or any other messages initiated 
by HA for which MN takes risky action like not using IKE.

Do you think these attacks are feasible?  I think so, and I think it's 
more than just DoS on MN.  Because when MN believes it's at home it 
won't IKE with HA, won't encapsulate ESP, nothing.

>> interfaces, one spoofable and one completely secure?  Because if 
>> the MN is attached only to the rogue AP leading to a fake Internet,
>>  how could it securely verify the certificate?
>> 
> 
> I have in mind a MN with a collection of root certs that it chains 
> back to to check the HA's proffered cert. That is how IKE 
> cert-checking works.

Yes, I guess so, but still much hurt can be provoked by HA sending 
packets to MN (even replaying responses maybe) without HA being able to 
understand whatever MN sends encrypted.

> If you think it would be clearer, I can spell this out, but we 
> assumed a certain level of understanding about IKE and cert-checking 
> when we wrote this, and it seems a bit redundant to have to repeat 
> everything in the IKE document.

I'll have to look at it, again.

>>> the attack will be foiled when the Mobile Node attempts to set up
>>>  the IKE SA.
>> 
>> Yes, provided that big IF materializes into a yes.  But I am pretty
>>  sure a 802.11 laptop won't do normal traffic on one interface and 
>> security verification traffic on another more secure interface.
>> 
> I'm not sure I understand what your point is. There is no need for 
> two interfaces. All that's needed is IKE and the standard way IKE 
> cert-checking is done.

OCSP?  Ok.

>> Or maybe some text is needed in this section that states that the 
>> MN to the first real IP hop (not virtual) connection is secured? 
>> There is no such text currently here.  I mean something about 
>> link-layer security?
>> 
> 

I didn't know.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Apr 2006 15:45:27 -0700

> All the root certs will point to the rogue AP.  The HA will not understand 
> messages coming from the MN (because encrypted with legitimate HA's or 
> CA's public keys), but the MN will understand all messages coming from the 
> rogue AP/HA/CA.  The HA will tell MN "Binding Refresh Request", or "RA 
> you're at home" or any other messages initiated by HA for which MN takes 
> risky action like not using IKE.
>

The root certs are preprovisioned on the MN. These are the roots of trust. 
Unless the rogue AP can get a root cert into that set or somehow spoof one 
of the CAs in that set into issuing it a cert, the MN can determine if it is 
being faked.

> more than just DoS on MN.  Because when MN believes it's at home it won't 
> IKE with HA, won't encapsulate ESP, nothing.
>

You are talking specifically about when the MN is at home?

Then I'd say that the RA from the HA needs to have a SEND signature on it, 
and the MN needs to ask the HA for a cert chain using SEND CPS. It won't 
know from the cert that the router is an HA but having the 'H' bit on and 
the signature will provide assurance that the RA hasn't been modified in 
transit and that the orignator is a certified router.

Maybe something should be said along these lines in Section 9?

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 00:58:32 +0200

James Kempf wrote:
>> Refresh Request", or "RA you're at home" or any other messages 
>> initiated by HA for which MN takes risky action like not using IKE.
>>
> 
> The root certs are preprovisioned on the MN. These are the roots of 
> trust. Unless the rogue AP can get a root cert into that set or somehow 
> spoof one of the CAs in that set into issuing it a cert, the MN can 
> determine if it is being faked.
> 
> 

Yes, mainly.  Rogue HA forcing legitimate MN at home means no IKE, no 
root certs verification, no ESP.

Additionally, the rogue HA could gather two legitimate MNs under it, 
make them both believe they're under same subnet and at their respective 
homes (advertise two different prefixes), so communicate with their 
CoAs, so no IKE involved, no RR tests.  While this communication, the 
rogue HA can listen all traffic between them.  If both MNs bootstrapped 
via DNS, and DNS is rogue, this risk is related to this draft.

> Then I'd say that the RA from the HA needs to have a SEND signature on 
> it, and the MN needs to ask the HA for a cert chain using SEND CPS. It 
> won't know from the cert that the router is an HA but having the 'H' bit 
> on and the signature will provide assurance that the RA hasn't been 
> modified in transit and that the orignator is a certified router.
> 

Yes.  I hope it's realized that this brings SeND in the picture of 
secure bootstrapping, along with DNSSEC and IKE?  I mean MN should run 
all that.

And maybe something about the Binding Refresh Request too?

There's no security check in 3775 about what does MN do when it receives 
a BRR.  All it says is it should send a BU to its HA with its current 
location.  I'm not sure though how to exploit this attack but there 
should be something about it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 01:57:00 +0200

James Kempf wrote:
>> legitimate HA's or CA's public keys), but the MN will understand
>> all messages coming from the rogue AP/HA/CA.  The HA will tell MN
>> "Binding Refresh Request", or "RA you're at home" or any other
>> messages initiated by HA for which MN takes risky action like not
>> using IKE.
>> 
> 
> trust. Unless the rogue AP can get a root cert into that set or
> somehow spoof one of the CAs in that set into issuing it a cert, the
> MN can determine if it is being faked.
> 
> 
>> Do you think these attacks are feasible?  I think so, and I think
>> it's more than just DoS on MN.  Because when MN believes it's at
>> home it won't IKE with HA, won't encapsulate ESP, nothing.
>> 
> 
> Then I'd say that the RA from the HA needs to have a SEND signature
> on it, and the MN needs to ask the HA for a cert chain using SEND
> CPS.

James, I think I didn't make myself clear (if you got my message please
skip this).  It's the DNS bootstrapping method that tells MN whether
it's at home or not.  Clearly, a rogue AP/AR/DNS server can instruct a
MN as apparently being at home.  This indication doesn't involve cert
verification, because comes from RA and DNS.

You're proposing this attack be foiled by running SeND on the home
network.  But it should actually run on all foreign networks where MN
attaches.  To foil the attack, the MN shouldn't talk to any network that
is not able to send SeND signatures on RAs.

So, do you propose to assume SeND is deployed on many access networks?

If not, I think the risk you and I described above should be evaluated
as "high" and not "mitigated" in the section Security Considerations of
the draft.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Apr 2006 08:36:32 -0700

> Yes, mainly.  Rogue HA forcing legitimate MN at home means no IKE, no root 
> certs verification, no ESP.
>
> Additionally, the rogue HA could gather two legitimate MNs under it, make 
> them both believe they're under same subnet and at their respective homes 
> (advertise two different prefixes), so communicate with their CoAs, so no 
> IKE involved, no RR tests.  While this communication, the rogue HA can 
> listen all traffic between them.  If both MNs bootstrapped via DNS, and 
> DNS is rogue, this risk is related to this draft.
>
> Yes.  I hope it's realized that this brings SeND in the picture of secure 
> bootstrapping, along with DNSSEC and IKE?  I mean MN should run all that.
>

Well, one possibiity is for the MN to run IKE on the home link too. And 
there is nothing in RFC 3775 to prevent it. Also, as mentioned, SEND can be 
used on the RA.

I'll see if I can come up with some text for Section 9.

> There's no security check in 3775 about what does MN do when it receives a 
> BRR.  All it says is it should send a BU to its HA with its current 
> location.  I'm not sure though how to exploit this attack but there should 
> be something about it.
>

I'll deal with this in a separate thread.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Apr 2006 08:37:50 -0700

> location.  I'm not sure though how to exploit this attack but there should 

I don't see the threat here as necessarily part of bootstrapping, but I'd 
like to hear a little more first. What exactly is the attack you had in 
mind?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Apr 2006 08:58:27 -0700

> is not able to send SeND signatures on RAs.

Right, if the 'H' bit is set on an RA in a foreign network, how can the MN 
trust it?

This is something for the updated version of RFC 3775, I think. Beyond the 
scope of the bootstrapping draft.

> So, do you propose to assume SeND is deployed on many access networks?

Well, I think SEND should be deployed on all last hop IPv6 networks. Having 
been the victim of an ARP spoofing attack (on IPv4) myself , I can 
categorically state that the threat is real, but most people don't seem to 
take it seriously. In fact, I just got email the other day from a former 
IETF SEC AD that he had suffered some kind of attack due to an unsecured RA 
in IPv6. I don't know what the implementation status of SEND is, but some 
people seem to be unhappy about the fact that it contains IPR, even if the 
IPR is royalty-free, which might be holding it up.

> as "high" and not "mitigated" in the section Security Considerations of

Like I said, this is really beyond the bootstrapping draft. RFC 3775 should 
recommend SEND to mitigate the risk of bogus HA advertisement. But since RFC 
3775 was written before SEND was completed, there is nothing in it. 
Something for RFC 3775bis.

            jak

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 19:04:52 +0200

James Kempf wrote:
>> James, I think I didn't make myself clear (if you got my message
>> please skip this).  It's the DNS bootstrapping method that tells MN
>> whether it's at home or not.  Clearly, a rogue AP/AR/DNS server can
>> instruct a MN as apparently being at home.  This indication doesn't
>> involve cert verification, because comes from RA and DNS.
>> 
>> network.  But it should actually run on all foreign networks where
>> MN attaches.  To foil the attack, the MN shouldn't talk to any
>> network that is not able to send SeND signatures on RAs.
>> 
> 
> Right, if the 'H' bit is set on an RA in a foreign network, how can
> the MN trust it?
> 
> This is something for the updated version of RFC 3775, I think.
> Beyond the scope of the bootstrapping draft.

The DNS-based bootstrapping draft could still acknowledge some security
risks induced by this method and by not using SeND.

> Well, I think SEND should be deployed on all last hop IPv6 networks.
>  Having been the victim of an ARP spoofing attack (on IPv4) myself ,
> I can categorically state that the threat is real, but most people
> don't seem to take it seriously. In fact, I just got email the other
> day from a former IETF SEC AD that he had suffered some kind of
> attack due to an unsecured RA in IPv6.

> I don't know what the implementation status of SEND is, but some
> people seem to be unhappy about the fact that it contains IPR, even
> if the IPR is royalty-free, which might be holding it up.
> 
>> If not, I think the risk you and I described above should be
>> evaluated as "high" and not "mitigated" in the section Security
>> Considerations of the draft.
> 
> Like I said, this is really beyond the bootstrapping draft. RFC 3775
>  should recommend SEND to mitigate the risk of bogus HA
> advertisement. But since RFC 3775 was written before SEND was
> completed, there is nothing in it. Something for RFC 3775bis.

Remark that if DHAAD is used, and the home link prefix pre-configured on 
the MN, the MN is not subject to a security risk where the rogue AP 
sends it a fake RA to fool it believing it is at home; simply because 
rogue AP doesn't know the real MN's home prefix.

With the currently described DNS-based bootstrapping method, rogue AP 
can easily fool MN believing it is at home: DNS response and RA contains 
same data.

And this distinction happens regardless of SeND being or not being used.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 19:15:35 +0200

James Kempf wrote:
>> There's no security check in 3775 about what does MN do when it 
>> receives a BRR.  All it says is it should send a BU to its HA with its 
>> current location.  I'm not sure though how to exploit this attack but 
>> there should be something about it.
>>
> 
> I don't see the threat here as necessarily part of bootstrapping, but 
> I'd like to hear a little more first. What exactly is the attack you had 
> in mind?

I'm not sure about the following attack.  However, I do sense a risk in 
rogue AP making MN think it's at home and being able to send it a BRR.

Legitimate MN is connected to legitimate AP and sends legitimate BUs to 
legitimate HA.  Rogue AP shows up, MN attaches to it, rogue AP makes it 
think it is at home, rogue AP instructs MN to send BU (with BRR), at 
which point rogue AP turns off.  MN will probably send BU to legitimate 
HA, telling it it is at home, which is not.

It's probably a minor risk though, just inducing delays, with 
re-establishing proper connection with IKE soon after rogue AP turned off.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Apr 2006 10:21:31 -0700

Alex,

We don't seem to be making much progress here. Clearly, you have a 
preference for DHAAD. Nobody is saying that it should be deprecated, just 
that it does not provide enough support. I don't agree that DNS 
bootstrapping is insecure, the need for the IKE is sufficient  on the 
foreign link. You've brought up an issue about the home link, and I'm going 
to work up some text on the topic for Section 9, but that is basically all I 
have to say on this. We'll just have to agree to disagree on the rest.

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 25, 2006 10:04 AM
Subject: Re: Not using SeND is insecure for DNS-based bootstrapping, but 
irrelevant if DHAAD-based (was: Should we assume SeND in foreign/visited 
networks?)

> the MN, the MN is not subject to a security risk where the rogue AP sends 
> it a fake RA to fool it believing it is at home; simply because rogue AP 
> doesn't know the real MN's home prefix.
>
> With the currently described DNS-based bootstrapping method, rogue AP can 
> easily fool MN believing it is at home: DNS response and RA contains same 
> data.
>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Apr 2006 10:33:34 -0700

> think it is at home, rogue AP instructs MN to send BU (with BRR), at which 
> point rogue AP turns off.  MN will probably send BU to legitimate HA, 
> telling it it is at home, which is not.
>

Even if the rouge AP is able to get packets out with the MN's home address 
on them as the source address (because the access network doesn't implement 
ingress filtering), the return packets won't arrive. So just having the 
rouge AP convince the MN it is at home essentially constitutes a DoS attack 
on the MN. I don't see what additional risk is added for BRR.

> re-establishing proper connection with IKE soon after rogue AP turned off.

I think a rouge AP that could spoof an HA would certainly be able to do much 
more serious damage than send a bogus BRR.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 19:53:56 +0200

James Kempf wrote:
>> I'm not sure about the following attack.  However, I do sense a risk 
>> in rogue AP making MN think it's at home and being able to send it a BRR.
>>
>> Legitimate MN is connected to legitimate AP and sends legitimate BUs 
>> to legitimate HA.  Rogue AP shows up, MN attaches to it, rogue AP 
>> makes it think it is at home, rogue AP instructs MN to send BU (with 
>> BRR), at which point rogue AP turns off.  MN will probably send BU to 
>> legitimate HA, telling it it is at home, which is not.
>>
> 
> Even if the rouge AP is able to get packets out with the MN's home 
> address on them as the source address (because the access network 
> doesn't implement ingress filtering), the return packets won't arrive. 
> So just having the rouge AP convince the MN it is at home essentially 
> constitutes a DoS attack on the MN. I don't see what additional risk is 
> added for BRR.

Probably right... rogue AP could turn off right after the RA/DNS 
Response too, not necessarily after BRR.

> I think a rouge AP that could spoof an HA would certainly be able to do 
> much more serious damage than send a bogus BRR.

Right, I was not thinking about real address spoofing, but about simple 
attacks with rogue AP running AR and DNS server.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 21:14:39 +0200

James Kempf wrote:
> preference for DHAAD.

I do, just like many people are biased.  It's normal to have preferences 
from some protocols when implementing them, no?

About making progress: I'm trying to, don't get me wrong.

> foreign link. You've brought up an issue about the home link, and I'm 
> going to work up some text on the topic for Section 9,

Thanks!

Alex