Subject: SEND-based protection and related confusions (was RE: AR compromise (Re: [Mipshop] Review ofdraft-haddad-mipship-hmipv6-security-04))

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 1 Aug 2006 14:47:06 -0700

I want to get a clear understanding myself on what SEND provides and
what it doesn't. I seem to have an understanding that is different from
some views here. For instance, the following email seems to allude that
SEND protects against AR compromise. In some previous discussions, I
heard the views that once an MN and AR use SEND, that link is now
secure. Either I am terribly mistaken in my reading of RFCs 3756, 3971
and 3972 or these misconceptions really need to cleared up, before we
build more protocols based on SEND. 

I want to state upfront that I have nothing against enhancing SEND to
protect other protocols or providing other functionality. I am only
questioning some of the fundamental assumptions being made about the
protection provided by SEND itself. Here are some points that I think
are worth getting clarity on. 

1. SEND protects ND messages only - this does not extend any protection
whatsoever to any future messages exchanged between the MN and any
entity in the network, including the AR. 

2. SEND itself DOES NOT protect against AR compromises. In fact, RFC3756
seems to explicitly bring this to attention in section 4.2.3 - "There
are currently no known solutions for any of the presented three trust
models." 

2a. In the case of SEND itself, the AR is one of the signaling endpoints
and nothing can be done about compromise of that. 

2b. In the case of protocols such as HMIP, the AR has no need to be
involved in the protocol. Hence, a compromise of the AR must not result
in issues with respect to the protocol operation (note: this is only
referring to the operation of the particular protocol in question, not a
general routing problem or DoS attack issue per say). 

3. SEND DOES NOT protect against MiTM attacks on other messaging
exchanged on the link (even if it is between the same two nodes that
executed SEND). 

A reasonable extension to SEND for other purposes would be when a key is
exchanged to be shared between the same two entities that executed SEND.
Brokering trust relationships between other entities based on SEND,
given that ARs are edge entities and given that SEND only protects ND
messages, does not seem quite right to me. 

Thoughts, anyone? 

Vidya 

> -----Original Message-----
> From: Wassim Haddad [mailto:[email-masked]] 
> Sent: Sunday, July 30, 2006 7:57 AM
> To: Dondeti, Lakshminath
> Cc: [email-masked]; Suresh Krishnan
> Subject: Re: AR compromise (Re: [Mipshop] Review 
> ofdraft-haddad-mipship-hmipv6-security-04)
> 
> On Fri, 28 Jul 2006, Lakshminath Dondeti wrote:
> 
> > Continuing the discussion on the topic of using the AR as 
> the key distributor.
> 
> => You have mentioned in your first comment that you're not 
> familiar with HMIPv6. Add to this that am well aware that 
> you're opposed to any solution which is based on SEND 
> protocol... All this pushes me to remind you that this draft 
> is based solely on SEND to address a specific issue in HMIPv6.
> 
> > Generally speaking, edge entities are easy to physically 
> get access to 
> > and therefore easy to compromise.
> 
> => FYI, there is a much more interesting and objective 
> analyze of all these threats in RFC 3756 without mentioning a 
> very interesting *philosophy* which is worthy to become 
> familiar with to understand the importance of implementing 
> SEND protocol. Maybe you should take a look.
> 
> > The idea of AR as the key distributor to a network entity 
> and the MN 
> > seems to ignore that vulnerability.
> 
> => Your comment does not make sense because the proposal is 
> based on SEND protocol which aims to counter threats 
> mentioned in RFC3756, which include to some extent the threat 
> you're mentioning above.
> 
> > Note that in your protocol, a compromised AR can continue to send 
> > bogus BUs even after the MN has moved away from that AR.
> 
> => note also that a compromised AR can do *much* more damage 
> than sending bogus BUs messages.
> 
> > Suppose the credential verification is reliant on AAA servers, then 
> > the key management protocol would work even if the AR is 
> compromised.
> 
> => this solution does not aim to rely on AAA. It relies on 
> building a form of trust between the MN and the AR, which 
> starts by implementing the SEND protocol and on exploiting 
> the trust between the MN and the AR to establish a 
> bidirectional security association between the MAP and the MN.
> 
> If you have any comment against the SEND protocol then please 
> post them to the corresponding ML instead of trying to 
> mislead people on this ML by raising *any* kind of possible 
> issue including those already addressed in other 
> specification just because you don't like SEND based solution.
> 
> Concerning your previous comments, version 00 will be 
> submitted tomorrow so please wait for it before pursuing your 
> campaign!
> 
> 
> Wassim H.
> 
> 
> 
> > At 03:01 PM 7/28/2006, Suresh Krishnan wrote:
> >
> > >>Moving beyond that, having an AR distribute a key to the 
> MAP and MN 
> > >>seems to take the opposite view to the philosophy that the edge 
> > >>entities in a network are not as trustworthy as entities 
> deeper in 
> > >>the network.
> > >
> > >I am not sure I see why? Is this philosophy documented somewhere?
> > >
> >
> >
> > _______________________________________________
> > Mipshop mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mipshop
> >
> >
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 1 Aug 2006 16:30:07 -0700

Agree with all these points. RFC 3756 and the SecCon section of 3971 
describe what protection SEND does and doesn't provide.

Also, it is important to distinguish between SEND and CGAs. RFC 3792 
describes how CGAs work, and the protection described there can be applied 
to other protocols that use CGAs, but care is needed to ensure that the 
protection properly to the appropriate threats.

                jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 01, 2006 2:47 PM
Subject: SEND-based protection and related confusions (was RE: AR 
compromise(Re: [Mipshop] Review ofdraft-haddad-mipship-hmipv6-security-04))

Thoughts, anyone?

Vidya

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 2 Aug 2006 12:59:02 +0300 (EEST)

On Tue, 1 Aug 2006, Narayanan, Vidya wrote:

> what it doesn't.

=> I don't think this is the right ML for that. There are two RFCs about
SEND that you should first start to read then there is another proposal on
securing FMIPv6 which is based on the same approach and third there is
ongoing proposal on optimizing SEND which you should also consider reading.
Finally, there is also a draft called OMIPv6_CGA_CBA that you should start
reading because it is based on the same approach (i.e., CGA) that you may
consider also.

Now if you don't like (as I told your colleague) any solution based on SEND
because you don't like SEND itself then this is really unfortunate!

> I seem to have an understanding that is different from
> SEND protects against AR compromise.

=> Again this is not the ML to discuss what SEND does and does not.

> In some previous discussions, I heard the views that once an MN and AR
> use SEND, that link is now secure. Either I am terribly mistaken in my
> reading of RFCs 3756, 3971 and 3972 or these misconceptions really need
> to cleared up, before we build more protocols based on SEND.

=> There is a difference between the "link is secure" and building trust
between two entities which enables you to know if a message has been sent
by the same entity or not. This is exactly what enables you to build on top
of such feature. The problem is that when you feel obliged to accept this
one you bring back immediately the "AR compromise" and we start again!

> protect other protocols or providing other functionality.

=> I have a strange feeling that it is actually exactly the opposite and
you know very well why.

> I am only questioning some of the fundamental assumptions being made
> about the protection provided by SEND itself. Here are some points that
> I think are worth getting clarity on.

=> and this is NOT the ML to do that. All what you're trying to do is
misleading the others.

> are currently no known solutions for any of the presented three trust

=> Add to this that when you compromise an AR there is a list of attacks
that you can do which are much more interesting than what you are trying
to bring to attention in HMIPsec which can lead to simply denying the MAP
service.

> involved in the protocol.

=> This is a clear proof that you don't want SEND involved!

Regards,

Wassim H.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 02 Aug 2006 12:46:25 +0200

Hi Wassim.

> Finally, there is also a draft called OMIPv6_CGA_CBA that you should
> start reading because it is based on the same approach (i.e., CGA)
> that you may consider also.

Although I'm sure you mean this, it's worth emphasizing that
draft-arkko-mipshop-cga-cba uses only CGA for IP address ownership
verification.  It does not use SEND.

Just for clarification.

Take care,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

Wassim Haddad wrote:
>> I want to get a clear understanding myself on what SEND provides
>> and what it doesn't.
> 
> => I don't think this is the right ML for that. There are two RFCs
> about SEND that you should first start to read then there is another
> proposal on securing FMIPv6 which is based on the same approach and
> third there is ongoing proposal on optimizing SEND which you should
> also consider reading. Finally, there is also a draft called
> OMIPv6_CGA_CBA that you should start reading because it is based on
> the same approach (i.e., CGA) that you may consider also.
> 
> Now if you don't like (as I told your colleague) any solution based
> on SEND because you don't like SEND itself then this is really
> unfortunate!
> 
>> I seem to have an understanding that is different from some views
>> here. For instance, the following email seems to allude that SEND
>> protects against AR compromise.
> 
>> In some previous discussions, I heard the views that once an MN and
>> AR use SEND, that link is now secure. Either I am terribly mistaken
>> in my reading of RFCs 3756, 3971 and 3972 or these misconceptions
>> really need to cleared up, before we build more protocols based on
>> SEND.
> 
> => There is a difference between the "link is secure" and building
> trust between two entities which enables you to know if a message has
> been sent by the same entity or not. This is exactly what enables you
> to build on top of such feature. The problem is that when you feel
> obliged to accept this one you bring back immediately the "AR
> compromise" and we start again!
> 
>> I want to state upfront that I have nothing against enhancing SEND
>> to protect other protocols or providing other functionality.
> 
> => I have a strange feeling that it is actually exactly the opposite
> and you know very well why.
> 
>> I am only questioning some of the fundamental assumptions being
>> made about the protection provided by SEND itself. Here are some
>> points that I think are worth getting clarity on.
> 
>> 1. SEND protects ND messages only - this does not extend any
>> protection whatsoever to any future messages exchanged between the
>> MN and any entity in the network, including the AR.
> 
>> 2. SEND itself DOES NOT protect against AR compromises. In fact,
>> RFC3756 seems to explicitly bring this to attention in section
>> 4.2.3 - "There are currently no known solutions for any of the
>> presented three trust models."
> 
> => Add to this that when you compromise an AR there is a list of
> attacks that you can do which are much more interesting than what you
> are trying to bring to attention in HMIPsec which can lead to simply
> denying the MAP service.
> 
>> 2a. In the case of SEND itself, the AR is one of the signaling
>> endpoints and nothing can be done about compromise of that.
>>

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 2 Aug 2006 15:23:27 +0300 (EEST)

Hi Christian,

> verification.  It does not use SEND.

=> yes that's was my intention.

Thanks for the note!

Cheers,

Wassim H.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 2 Aug 2006 12:07:01 -0700

Wassim,
I have made all the technical points I have to make. This discussion, at
this point, is non-productive. 

To conclude, I think the protocol in
draft-haddad-mipship-hmipv6-security-04 is fundamentally broken and from
the discussions, it doesn't seem like the fundamental issues are going
to be fixed in the revision. 

I strongly object to this draft becoming a WG item. 

Vidya 

> Sent: Wednesday, August 02, 2006 2:59 AM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: SEND-based protection and related confusions 
> (was RE: AR compromise (Re: [Mipshop] Review 
> ofdraft-haddad-mipship-hmipv6-security-04))
> 
> => I don't think this is the right ML for that. There are two 
> RFCs about SEND that you should first start to read then 
> there is another proposal on securing FMIPv6 which is based 
> on the same approach and third there is ongoing proposal on 
> optimizing SEND which you should also consider reading.
> Finally, there is also a draft called OMIPv6_CGA_CBA that you 
> should start reading because it is based on the same approach 
> (i.e., CGA) that you may consider also.
> 
> Now if you don't like (as I told your colleague) any solution 
> based on SEND because you don't like SEND itself then this is 
> really unfortunate!
> 
> > reading of RFCs 3756, 3971 and 3972 or these misconceptions really 
> > need to cleared up, before we build more protocols based on SEND.
> 
> => There is a difference between the "link is secure" and 
> building trust between two entities which enables you to know 
> if a message has been sent by the same entity or not. This is 
> exactly what enables you to build on top of such feature. The 
> problem is that when you feel obliged to accept this one you 
> bring back immediately the "AR compromise" and we start again!
> 
> => I have a strange feeling that it is actually exactly the 
> opposite and you know very well why.
> 
> > about the protection provided by SEND itself. Here are some points 
> > that I think are worth getting clarity on.
> 
> => and this is NOT the ML to do that. All what you're trying 
> to do is misleading the others.
> 
> > protection whatsoever to any future messages exchanged 
> between the MN 
> > and any entity in the network, including the AR.
> 
> > RFC3756 seems to explicitly bring this to attention in 
> section 4.2.3 - 
> > "There are currently no known solutions for any of the 
> presented three 
> > trust models."
> 
> => Add to this that when you compromise an AR there is a list 
> of attacks that you can do which are much more interesting 
> than what you are trying to bring to attention in HMIPsec 
> which can lead to simply denying the MAP service.
>

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 3 Aug 2006 12:05:41 +0300 (EEST)

> this point, is non-productive.

=> Thanks for realizing that!

> to be fixed in the revision.

=> this reflects your personal opinion as there is a difference between
willing to understand and not willing.

> I strongly object to this draft becoming a WG item.

=> and from the beginning...!

Wassim H.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Aug 2006 16:47:24 +0300

> describe what protection SEND does and doesn't provide.

Agree about the parts concerning SEND. I still need to read more to
understand the HMIP part of this argument, so I am not commenting on
that.

> describes how CGAs work, and the protection described there can be
> applied to other protocols that use CGAs, but care is needed to ensure
> that the protection properly to the appropriate threats.

Indeed. One bit of history that may be interesting: we considered an earlier
SEND design that would also have provided subsequent payload traffic
protection, and not just ND protection. There are plenty of security
mechanisms, but the interesting part is usually in how they are applied
for a given problem. If a component such as SEND or CGA is used in a
new application, you would expect that the specific needs of the
application are addressed. Either by choosing the right underlying
components or extending them to do the necessary things.

But back to today's problem: do we know what the requirements
for a HMIP security solution are? I'm not sure I want to discuss
what nodes should be involved yet. Rather, what are the resources
and messages that need protection?

--Jari

>                jak
>
> ----- Original Message ----- From: "Narayanan, Vidya"
> <[email-masked]>
> To: <[email-masked]>
> compromise(Re: [Mipshop] Review

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 15 Aug 2006 08:26:48 -0700

>and messages that need protection?

Good question.  I started with 4140's security considerations; that 
seems like a good starting point.

Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 16 Aug 2006 17:20:46 -0700

In the HMIP model (as in any host-based mobility model), I do feel
strongly that the compromise of an AR must not cause spurious binding
cache entries at the MAP on behalf of the MN. As we move towards a model
of distributed systems and IP all the way to the edge, the concern of
domino effects is higher. So, brokering a trust relationship between the
MN and the MAP by the AR providing a key and then doing a DH exchange is
not attractive to me. If we want to leverage the presence of CGAs, we
could perhaps go down the path of IKEv2 using CGAs/self-signed certs,
etc. We have to keep in mind that this is not equivalent to simple IPsec
or IKEv2/EAP, but, in the interest of infrastructureless security, it
can be done. Doing IKEv2 has several advantages, including the fact that
you can then use IPsec as the secure channel. IKEv2 employs a well
designed authenticated DH exchange that provides several useful
properties and if we are going to take on a DH-based approach, it makes
sense to use IKEv2. 

If SEND is used, it will protect the MAP advertisement coming from the
AR - so, that communication can be independently protected. 

Vidya

> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Tuesday, August 15, 2006 8:27 AM
> To: Jari Arkko; James Kempf; Narayanan, Vidya
> Cc: [email-masked]
> (was RE: AR compromise(Re: [Mipshop] Review 
> > > applied to other protocols that use CGAs, but care is needed to 
> > > ensure that the protection properly to the appropriate threats.
> >
> >Indeed. One bit of history that may be interesting: we considered an 
> >earlier SEND design that would also have provided subsequent payload 
> >traffic protection, and not just ND protection. There are plenty of 
> >security mechanisms, but the interesting part is usually in how they 
> >are applied for a given problem. If a component such as SEND 
> or CGA is 
> >used in a new application, you would expect that the 
> specific needs of 
> >the application are addressed. Either by choosing the right 
> underlying 
> >But back to today's problem: do we know what the requirements for a 
> >HMIP security solution are? I'm not sure I want to discuss 
> what nodes 
> >should be involved yet. Rather, what are the resources and messages 
> >that need protection?
> 
> Good question.  I started with 4140's security 
> considerations; that seems like a good starting point.
> 
> Lakshminath
> 
> 
> >--Jari
> >
> > >                jak
> > >
> > > what it doesn't. I seem to have an understanding that is 
> different 
> > > from some views here. For instance, the following email seems to 
> > > allude that SEND protects against AR compromise. In some previous 
> > > discussions, I heard the views that once an MN and AR use 
> SEND, that 
> > > link is now secure. Either I am terribly mistaken in my 
> reading of 
> > > RFCs 3756, 3971 and 3972 or these misconceptions really need to 
> > > cleared up, before we build more protocols based on SEND.
> > >
> > > to protect other protocols or providing other functionality. I am 
> > > only questioning some of the fundamental assumptions being made 
> between the 
> section 4.2.3 
> > > - "There are currently no known solutions for any of the 
> presented 
> > > three trust models."
> > >
> > > involved in the protocol. Hence, a compromise of the AR must not 
> > > result in issues with respect to the protocol operation 
> (note: this 
> > > is only referring to the operation of the particular protocol in 
> > > question, not a general routing problem or DoS attack 
> issue per say).
> > >
> > > A reasonable extension to SEND for other purposes would be when a 
> > > key is exchanged to be shared between the same two 
> entities that executed SEND.
> > > given that ARs are edge entities and given that SEND only 
> protects 
> > > ND messages, does not seem quite right to me.
> >
> >
> >

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 17 Aug 2006 11:06:46 +0300 (EEST)

On Wed, 16 Aug 2006, Narayanan, Vidya wrote:

> cache entries at the MAP on behalf of the MN.

=> A compromise of the AR has a much bigger impact on HMIPv6 protocol than
what you are describing. Thus it does not make sense to ignore the real
impact of an AR compromise (in an HMIPv6 domain) and just highlight the
fact that it can cause "spurious binding cache entries"!

> So, brokering a trust relationship between the MN and the MAP by the AR
> providing a key and then doing a DH exchange is not attractive to me.

=> This is NOT accurate since it is assumed to have a trust relationship
and secure links between nodes inside the MAP domain and the AR is not
outside such domain (note that this assumption is not new!). This is
mentioned in the security considerations section in the latest version.

> If we want to leverage the presence of CGAs, we could perhaps go down
> the path of IKEv2 using CGAs/self-signed certs,
> etc.

=> You don't need to go down to this path with CGA (even when talking
about alternative).

> We have to keep in mind that this is not equivalent to simple IPsec
> can be done.

=> The draft assumes that the infrastructure is secure and the protocol
is built on such assumption.

Regards,
Wassim H.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Aug 2006 09:42:16 -0700

I've not read the protocol design document, so I won't comment on the 
details. However, I'd like to comment on the debate about compromise of an 
AR.

In typical deployment situations, the AR is located in a locked closet that 
only personnel who are authorized can access. This does not, of course, mean 
that an AR can't be compromised over the wire, through some security hole in 
the software or something like that. But that risk exists for any network 
element that has a globally visible IP address. The situation is entirely 
different for APs, which are typically located in public places. In fact, 
this argument - that physical security is stronger for network elements such 
as routers and switches - is one of the major selling points for WLAN 
switching gear, because WLAN switches often handle security instead of APs 
and are considered more secure.

I think it is important to make this distinction when doing a threat 
analysis. It does not meant that an AR can never be physically compromised, 
but it does mean that such a compromise is more likely to be an inside job 
(that is corrupt personnel) than is the case for an AP, where anybody can 
walk up, detach the AP, download the firmware to a laptop, analyze it to 
extract a key, then use the key to compromise the network.

            jak

----- Original Message ----- 
From: "Wassim Haddad" <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>
Cc: "Dondeti, Lakshminath" <[email-masked]>; "Jari Arkko" 
<[email-masked]>; "James Kempf" <[email-masked]>; 
<[email-masked]>
Sent: Thursday, August 17, 2006 1:06 AM
Subject: RE: SEND-based protection and related confusions (was RE: AR 
compromise(Re: [Mipshop] Review ofdraft-haddad-mipship-hmipv6-security-04))

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 17 Aug 2006 10:14:42 -0700

Hi James,

Thanks for starting this discussion.  I thought about this some and 
wondered what might be a good model for us to follow in security analyses.

I agree that in some (I do notice that you've used the word typical) 
deployments, the AR is in a locked closet.  As you note, the APs can 
be in "accessible" locations, and in some architectures it might make 
sense for an AP and AR to be collocated, and thus ARs are also 
vulnerable to physical compromise.  The other aspect to this argument 
is that the number of ARs is large.  It is easier to place 
assumptions of trust or not-easy-to-compromise on how devices that 
might be fewer in numbers, but realistically the IETF cannot ignore 
the generic threat model of ARs being compromised.

In closing, given that you are also saying that AR is only 
inaccessible in "typical" deployments and not all deployments, 
wouldn't we rather not increase the trust on "edge" entities like 
ARs?  It seems counter-intuitive to having them facilitate key 
distribution to entities deeper in the network.

Thoughts?

thanks,
Lakshminath

At 09:42 AM 8/17/2006, James Kempf wrote:
>I've not read the protocol design document, so I won't comment on 
>the details. However, I'd like to comment on the debate about 
>compromise of an AR.
>
>In typical deployment situations, the AR is located in a locked 
>closet that only personnel who are authorized can access. This does 
>not, of course, mean that an AR can't be compromised over the wire, 
>through some security hole in the software or something like that. 
>But that risk exists for any network element that has a globally 
>visible IP address. The situation is entirely different for APs, 
>which are typically located in public places. In fact, this argument 
>- that physical security is stronger for network elements such as 
>routers and switches - is one of the major selling points for WLAN 
>switching gear, because WLAN switches often handle security instead 
>of APs and are considered more secure.
>
>analysis. It does not meant that an AR can never be physically 
>compromised, but it does mean that such a compromise is more likely 
>to be an inside job (that is corrupt personnel) than is the case for 
>an AP, where anybody can walk up, detach the AP, download the 
>firmware to a laptop, analyze it to extract a key, then use the key 
>to compromise the network.
>
>            jak
>
>----- Original Message ----- From: "Wassim Haddad" <[email-masked]>
>Subject: RE: SEND-based protection and related confusions (was RE: 
>AR compromise(Re: [Mipshop] Review ofdraft-haddad-mipship-hmipv6-security-04))
>
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 17 Aug 2006 11:59:54 -0700

Hi James, 
Thanks for this discussion. I agree with Lakshminath's point that we
have to generically look at the threat model and not design for specific
cases, especially when we don't have to. Let's look at the various
impacts of AR compromise generally in the context of HMIPv6: 

1. The AR may advertise an invalid MAP in the RA. 
2. The AR may drop LBUs/LBAs sent from/to the MN. 
3. The AR may in general drop or redirect packets. 

If an MN attaches to such an AR, in the case of 1 above, the MN will
realize that the MAP is invalid when it attempts to create an SA with
the MAP (in the normal case where the AR is not involved with SA
establishment and there is mutual authentication between the MN and
MAP). 2 and 3 above can happen when the AR is compromised, but, the
impact is limited to the MNs attaching to that AR. Also, there is
nothing the MN can do about it. 

By involving the AR in the SA establishment between the MN and MAP, the
following additional vulnerabilities are introduced upon AR compromise: 

A. The AR may advertise an invalid MAP and the MN may not be able to
detect it. The AR is now capable of spoofing the entire SA (the MN will
believe it has an SA with a valid MAP, while it doesn't). 

B. The AR may send a BU, pretending to be the MN, registering a bogus
CoA at the MAP, *even after the MN has moved away from the AR*. 

These are important points in security design of protocols. In general,
the impact of an entity compromise must be limited to things in control
of that entity - in other words, when an AR is compromised, it is vital
to ensure that sessions of MNs that are no longer attached to that AR
are not affected. 

Hope the above helps clarifying what I've been trying to say better. 

Vidya

> Sent: Thursday, August 17, 2006 10:15 AM
> To: James Kempf; Wassim Haddad; Narayanan, Vidya
> Cc: Jari Arkko; [email-masked]
> Subject: Re: How probable is compromise of an AR? (was: Re: 
> SEND-based protection and related confusions )
> 
> Hi James,
> 
> Thanks for starting this discussion.  I thought about this 
> some and wondered what might be a good model for us to follow 
> in security analyses.
> 
> I agree that in some (I do notice that you've used the word 
> typical) deployments, the AR is in a locked closet.  As you 
> note, the APs can be in "accessible" locations, and in some 
> architectures it might make sense for an AP and AR to be 
> collocated, and thus ARs are also vulnerable to physical 
> compromise.  The other aspect to this argument is that the 
> number of ARs is large.  It is easier to place assumptions of 
> trust or not-easy-to-compromise on how devices that might be 
> fewer in numbers, but realistically the IETF cannot ignore 
> inaccessible in "typical" deployments and not all 
> deployments, wouldn't we rather not increase the trust on 
> "edge" entities like ARs?  It seems counter-intuitive to 
> having them facilitate key distribution to entities deeper in 
> the network.
> 
> Thoughts?
> 
> thanks,
> Lakshminath
> 
> >details. However, I'd like to comment on the debate about 
> compromise of 
> >an AR.
> >
> >In typical deployment situations, the AR is located in a 
> locked closet 
> >that only personnel who are authorized can access. This does not, of 
> >course, mean that an AR can't be compromised over the wire, through 
> >some security hole in the software or something like that.
> >visible IP address. The situation is entirely different for 
> APs, which 
> >are typically located in public places. In fact, this argument
> >switching gear, because WLAN switches often handle security 
> instead of 
> >APs and are considered more secure.
> >
> >compromised, but it does mean that such a compromise is more 
> likely to 
> >be an inside job (that is corrupt personnel) than is the case for an 
> >AP, where anybody can walk up, detach the AP, download the 
> firmware to 
> >a laptop, analyze it to extract a key, then use the key to 
> compromise 
> >the network.
> >
> >            jak
> >
> >AR compromise(Re: [Mipshop] Review 
> >>=> A compromise of the AR has a much bigger impact on 
> HMIPv6 protocol 
> >>than what you are describing. Thus it does not make sense to ignore 
> >>the real impact of an AR compromise (in an HMIPv6 domain) and just 
> >>highlight the fact that it can cause "spurious binding 
> cache entries"!
> >>
> >>>So, brokering a trust relationship between the MN and the 
> MAP by the 
> >>>AR providing a key and then doing a DH exchange is not 
> attractive to me.
> >>
> >>=> This is NOT accurate since it is assumed to have a trust 
> >>relationship and secure links between nodes inside the MAP 
> domain and 
> >>the AR is not outside such domain (note that this assumption is not 
> >>new!). This is mentioned in the security considerations 
> section in the latest version.
> >>
> >>>the path of IKEv2 using CGAs/self-signed certs, etc.
> >>
> >>=> The draft assumes that the infrastructure is secure and the 
> >>protocol is built on such assumption.
> >>
> >>
> >>Regards,
> >>Wassim H.
> >
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Aug 2006 12:38:36 -0700

Lakshminath,

> deployments, the AR is in a locked closet.  As you note, the APs can be in 
> "accessible" locations, and in some architectures it might make sense for 
> an AP and AR to be collocated, and thus ARs are also vulnerable to 
> physical compromise.  The other aspect to this argument is that the number 
> of ARs is large.  It is easier to place assumptions of trust or 
> not-easy-to-compromise on how devices that might be fewer in numbers, but 
> realistically the IETF cannot ignore the generic threat model of ARs being 
> compromised.
>

I was being conservative. :-) Actually, I don't know of any real deployments 
where ARs are publically accessable (which of course doesn't mean that there 
aren't any). 802.11 deployments have the APs in accessable places, and the 
AR in the locked wiring closet. The traditional 802.11 architecture is for 
the NAS to be located on the AP, but the trend is toward putting the NAS in 
WLAN switches which can be locked in the wiring closet too. Cellular systems 
are secured even more. The GGSN or PDSN is usually in a building where there 
is no access except for authorized personal, the same as for a Class 5 
switch such as an MSC. Some operators deploy one GGSN for an entire country, 
so they need to make really sure the physical security is rock solid. 802.16 
has yet to be deployed widely for mobility purposes (though there are some 
operators such as Clearwire that are deploying it for point to multipoint). 
So the deployment model up to now for unlicensed spectrum has been to have 
very few, physically secured ARs and lots of less secure APs, with the APs 
as essentially IP bridges, not routers. For licensed spectrum, even the BSs 
are under heavy physical security.

Regarding the threat of ARs being compromised, the issue is not whether or 
not it should be ignored, but rather how much effort should be put into 
defending against it. Threat mitigation is always an issue of tradeoffs. If 
the threat is smaller, then heroic efforts to mitigate it from a protocol 
standpoint, when simple physical security is always in place, are, in a 
sense, overengineering. An example of where such a tradeoff was made is in 
the return routability protocol for MIP6 security in RFC 3775. The protocol 
has a residual vulnerability, but the threat is considered to be relatively 
minor. But the threat was not ignored, it is described clearly in the 
Security Considerations section. Any protocol that has a threat from AR 
compromise would need to indicate that physical security of the AR is 
required for mitigation.

> In closing, given that you are also saying that AR is only inaccessible in 
> "typical" deployments and not all deployments, wouldn't we rather not 
> increase the trust on "edge" entities like ARs?  It seems 
> counter-intuitive to having them facilitate key distribution to entities 
> deeper in the network.
>

I think the issue from an architectural standpoint is where the trust 
relationships are, how they are established, etc. One pattern is to have a 
centralized network entity, such as an AAA server, be the trust anchor. The 
802.1x/802.11e three party trust model never ends up with a trust 
relationship between the AP and the terminal, in the sense that the two 
authenticate to each other. The AP trusts the terminal because the AAA 
server does, and likewise between the terminal and the AP. The other pattern 
is the IKE/IPsec distributed model, where a root of trust between two 
entities is established, and the trust relationship is bootstrapped from 
there. In that case, the two entities do trust each other, because of the 
cert chain back to the root of trust allows them to authenticate each other. 
I think a key distribution and security protocol that fits into one or the 
other of these models is much more likely to be understandable and secure 
than one that attempts to do something different.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Aug 2006 12:49:02 -0700

Vidya,

Like I said in my reply to Lakshminath, I believe the amount of effort to 
put into threat mitigation should be proportional to the liklihood of the 
threat. While the attacks you outline below are possible, I believe they are 
unlikely for a secure router given the way wireless systems are deployed. A 
security recommendation of "use physical security" when physical security is 
always used in practice should be sufficient. Other than that, I think the 
key distribution and security protocol should try to fit into one of the two 
architectural patterns (centralized/AAA or distributed/IKE) that are well 
understood, otherwise, it may be quite a long time before the security is 
well-enough understood that people are willing to agree that it provides 
protection.

I do think that one must draw a distincition between compromise of a secure 
router and an attacker masquerading as a router. Particularly for unlicensed 
systems such as 802.11, masquerading can be an issue if MAC layer security 
is not used (such as for public hotspots). Do you think that any of these 
attacks are possible for a masquerading router?

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "Dondeti, Lakshminath" <[email-masked]>; "James Kempf" 
<[email-masked]>; "Wassim Haddad" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 17, 2006 11:59 AM
Subject: RE: How probable is compromise of an AR? (was: Re: SEND-based 
protection and related confusions )

Hi James,

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 17 Aug 2006 13:22:01 -0700

James,
On the topic of physical security of devices, the trend of the future is
in fact, towards a distributed model with IP to the edge, where the AR
functionality per say is closer to the APs and the BSs than we are used
to now. I can say with some confidence that the myth that the BSs are
physically secure in cellular systems is quickly vanishing and both 3gpp
and 3gpp2 are looking at BSs as being more vulnerable. And, I've seen
deployments of WLAN systems where the AR functionality is wrapped up in
APs - if we let the AR be just an AR (i.e., the first hop IP gateway
that serves as a default gateway and does ND on the link), this is
simple enough functionality that can be collocated with the APs/BSs. 

On the topic of "how much effort should be put into defending against
compromised ARs", I can appreciate trading this off for simplicity or
efficiency. That has been done before (802.11r is subject to domino
effects and it has been accepted as a tradeoff). Unfortunately, the
protocol under discussion doesn't seem to be any simpler than just doing
IKEv2 which is more secure. So, I don't really understand why the
security tradeoff makes sense here. 

Vidya

> From: James Kempf [mailto:[email-masked]] 
> Sent: Thursday, August 17, 2006 12:39 PM
> To: Wassim Haddad; Narayanan, Vidya; Dondeti, Lakshminath
> typical) 
> assumptions 
> > of trust or not-easy-to-compromise on how devices that 
> might be fewer 
> > in numbers, but realistically the IETF cannot ignore the generic 
> > threat model of ARs being compromised.
> >
> 
> I was being conservative. :-) Actually, I don't know of any 
> real deployments where ARs are publically accessable (which 
> of course doesn't mean that there aren't any). 802.11 
> deployments have the APs in accessable places, and the AR in 
> the locked wiring closet. The traditional 802.11 architecture 
> is for the NAS to be located on the AP, but the trend is 
> toward putting the NAS in WLAN switches which can be locked 
> in the wiring closet too. Cellular systems are secured even 
> more. The GGSN or PDSN is usually in a building where there 
> is no access except for authorized personal, the same as for 
> a Class 5 switch such as an MSC. Some operators deploy one 
> GGSN for an entire country, so they need to make really sure 
> the physical security is rock solid. 802.16 has yet to be 
> deployed widely for mobility purposes (though there are some 
> So the deployment model up to now for unlicensed spectrum has 
> been to have very few, physically secured ARs and lots of 
> less secure APs, with the APs as essentially IP bridges, not 
> routers. For licensed spectrum, even the BSs are under heavy 
> physical security.
> 
> Regarding the threat of ARs being compromised, the issue is 
> not whether or not it should be ignored, but rather how much 
> effort should be put into defending against it. Threat 
> mitigation is always an issue of tradeoffs. If the threat is 
> smaller, then heroic efforts to mitigate it from a protocol 
> standpoint, when simple physical security is always in place, 
> are, in a sense, overengineering. An example of where such a 
> tradeoff was made is in the return routability protocol for 
> MIP6 security in RFC 3775. The protocol has a residual 
> vulnerability, but the threat is considered to be relatively 
> minor. But the threat was not ignored, it is described 
> clearly in the Security Considerations section. Any protocol 
> that has a threat from AR compromise would need to indicate 
> that physical security of the AR is required for mitigation.
> 
> 
> > wouldn't we rather not increase the trust on "edge" 
> entities like ARs?  
> > It seems counter-intuitive to having them facilitate key 
> distribution 
> I think the issue from an architectural standpoint is where 
> the trust relationships are, how they are established, etc. 
> One pattern is to have a centralized network entity, such as 
> an AAA server, be the trust anchor. The 802.1x/802.11e three 
> party trust model never ends up with a trust relationship 
> between the AP and the terminal, in the sense that the two 
> authenticate to each other. The AP trusts the terminal 
> because the AAA server does, and likewise between the 
> terminal and the AP. The other pattern is the IKE/IPsec 
> distributed model, where a root of trust between two entities 
> is established, and the trust relationship is bootstrapped 
> from there. In that case, the two entities do trust each 
> other, because of the cert chain back to the root of trust 
> allows them to authenticate each other. 
> I think a key distribution and security protocol that fits 
> into one or the other of these models is much more likely to 
> be understandable and secure than one that attempts to do 
> something different.
> 
>             jak 
> 
> 
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 17 Aug 2006 13:11:09 -0700

Hi James, 

> Like I said in my reply to Lakshminath, I believe the amount 
> of effort to put into threat mitigation should be 
> proportional to the liklihood of the threat. While the 
> attacks you outline below are possible, I believe they are 
> unlikely for a secure router given the way wireless systems 
> are deployed. A security recommendation of "use physical 
> security" when physical security is always used in practice 
> should be sufficient. Other than that, I think the key 
> distribution and security protocol should try to fit into one 
> of the two architectural patterns (centralized/AAA or 
> distributed/IKE) that are well understood, otherwise, it may 
> be quite a long time before the security is well-enough 
> understood that people are willing to agree that it provides 
> protection.
> 

The point you have made above is also one of the points I've been trying
to make for a while now. The protocol being defined is different from
the AAA model and the IKEv2 model. Yet, it is no simpler than IKEv2
(employs a DH exchange and some extra CGA-based stuff, including a key
generated by an AR). In this case, I do think using IKEv2 is simpler and
provides better security. If the goal is to be infrastructureless (i.e.,
no PSKs or no EAP in IKEv2 or no certs), we should look into using CGAs
with IKEv2 rather than inventing a new DH-based protocol. 

> I do think that one must draw a distincition between 
> compromise of a secure router and an attacker masquerading as 
> a router. Particularly for unlicensed systems such as 802.11, 
> masquerading can be an issue if MAC layer security is not 
> used (such as for public hotspots). Do you think that any of 
> these attacks are possible for a masquerading router?
> 

Yes, these attacks are applicable to a masquerading router as you've
described above and that is certainly a concern as well. 

Vidya

> Subject: RE: How probable is compromise of an AR? (was: Re: 
> Thanks for this discussion. I agree with Lakshminath's point 
> that we have to generically look at the threat model and not 
> design for specific cases, especially when we don't have to. 
> Let's look at the various impacts of AR compromise generally 
> in the context of HMIPv6:
> 
> If an MN attaches to such an AR, in the case of 1 above, the 
> MN will realize that the MAP is invalid when it attempts to 
> create an SA with the MAP (in the normal case where the AR is 
> not involved with SA establishment and there is mutual 
> authentication between the MN and MAP). 2 and 3 above can 
> happen when the AR is compromised, but, the impact is limited 
> to the MNs attaching to that AR. Also, there is nothing the 
> MN can do about it.
> 
> By involving the AR in the SA establishment between the MN 
> and MAP, the following additional vulnerabilities are 
> introduced upon AR compromise:
> 
> A. The AR may advertise an invalid MAP and the MN may not be 
> able to detect it. The AR is now capable of spoofing the 
> entire SA (the MN will believe it has an SA with a valid MAP, 
> while it doesn't).
> 
> B. The AR may send a BU, pretending to be the MN, registering 
> a bogus CoA at the MAP, *even after the MN has moved away 
> from the AR*.
> 
> These are important points in security design of protocols. 
> In general, the impact of an entity compromise must be 
> limited to things in control of that entity - in other words, 
> when an AR is compromised, it is vital to ensure that 
> sessions of MNs that are no longer attached to that AR are 
> not affected.
> 
> note, the 
> > APs can be in "accessible" locations, and in some architectures it 
> > might make sense for an AP and AR to be collocated, and 
> thus ARs are 
> > also vulnerable to physical compromise.  The other aspect to this 
> > argument is that the number of ARs is large.  It is easier to place

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Aug 2006 13:50:03 -0700

Vidya,

Perhaps you would like to describe the 802.11 deployments you've seen with 
AR and AP functionality combined?

My experience is quite the opposite. Like I said, one of the primary 
requirements driving WLAN switch deployment has been moving the NAS 
functionality into the wiring closet. The APs then become "lightweight", 
with no local cryptographic material. I also don't think a trend toward 
making cellular BSs IP capable devices means that operators are going to 
deploy them in a way that makes them less physically secure. I think 
operators are always going to want to physically secure these devices, if 
for no other reason than because they cost a substantial amount of money, 
unlike 802.11 APs. So it seems we disagree on this point.

When we did the threat analysis for Neighbor Discovery (RFC 3756), we 
concluded that it was not feasible to mitigate compromise of a previously 
trusted AR. The threat is, however, mentioned. We concentrated on mitigating 
the threat of a masqurading AR, which is not possible to deter using 
physical security, and is a very real threat for 802.11 end nodes.

As for HMIP security, please note the thread topic. This topic has come up 
in other WGs, raised by you and Lakshimath, and I wanted an opportunity to 
discuss the threat specifically with you both, this seemed a good 
opportunity. As I mentioned in the original post, I don't have an opinion on 
the HIMP security protocol (otherwise I would have continued to post under 
the original thread) except that I think it should try to fit 
architecturally with an existing model. If, as you mentioned in a previous 
post, it does not, then I think the authors would do well to reconsider the 
design and try to make it fit.

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Wassim Haddad" 
<[email-masked]>; "Dondeti, Lakshminath" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 17, 2006 1:22 PM
Subject: RE: How probable is compromise of an AR? (was: Re: SEND-based 
protection and related confusions )

James,

Vidya

---

From: Wassim Haddad <[email-masked]>
Date: Fri, 18 Aug 2006 01:52:29 +0300 (EEST)

> security tradeoff makes sense here.

=> IMHO, the way you're considering doing IKEv2 with CGA is not as simple
as what HMIPsec proposes. In fact, what you seem to have in mind MAY
threaten the MAP (I won't expand on this now as I need to look at it
more).

Anyway, as it seems now that you are shifting the discussion from AR
compromise to IKEv2, it would be very helpful if you first highlight a
real weakness/threat that we have missed in the draft instead of just
suggesting an alternative OR talking about AR compromise.

Wassim H.

P.S: BTW, your point 1 in your previous email on compromising AR is
missing the essential as its impact is not at all limited to what you
wrote.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 18 Aug 2006 04:06:30 -0700

At 01:50 PM 8/17/2006, James Kempf wrote:
>Vidya,
>
>Perhaps you would like to describe the 802.11 deployments you've 
>seen with AR and AP functionality combined?
>
>functionality into the wiring closet. The APs then become 
>"lightweight", with no local cryptographic material. I also don't 
>think a trend toward making cellular BSs IP capable devices means 
>that operators are going to deploy them in a way that makes them 
>less physically secure. I think operators are always going to want 
>to physically secure these devices, if for no other reason than 
>because they cost a substantial amount of money, unlike 802.11 APs. 
>So it seems we disagree on this point.

Hi James,

Sorry for barging in on your email to Vidya, but let me take a stab at this.

We can envision a hot-spot model where APs may be deployed in 
accessible locations and ARs may be deployed in let's say 
semi-accessible locations (the APs and one or more ARs comprising a 
hot-spot) and the rest of the backend less and less accessible for 
physical compromise, culminating in MAPs and especially AAA servers 
being in the most secure locations.  Is that a possible deployment model?

If a hot-spot owner controlled the "edge network" and the service 
provider controlled the rest of the network, wouldn't we say that AR 
compromise is a real threat (if nothing, due to administrative 
boundaries)?  Specifically, the service provider would want to avoid 
the domino effect by limiting the impact of a compromise of a 
hot-spot to just that hot-spot's coverage.  Does that make sense?

>When we did the threat analysis for Neighbor Discovery (RFC 3756), 
>we concluded that it was not feasible to mitigate compromise of a 
>previously trusted AR. The threat is, however, mentioned. We 
>concentrated on mitigating the threat of a masqurading AR, which is 
>not possible to deter using physical security, and is a very real 
>threat for 802.11 end nodes.

Right, here the protocol is between the AR and the MN.  If one of the 
parties to the protocol is compromised, we have a tough problem.  The 
best we can hope for is that the MN should be able to identify a 
misbehaving AR.

>As for HMIP security, please note the thread topic. This topic has 
>come up in other WGs, raised by you and Lakshimath, and I wanted an 
>opportunity to discuss the threat specifically with you both, this 
>seemed a good opportunity. As I mentioned in the original post, I 
>don't have an opinion on the HIMP security protocol (otherwise I 
>would have continued to post under the original thread) except that 
>I think it should try to fit architecturally with an existing model. 
>If, as you mentioned in a previous post, it does not, then I think 
>the authors would do well to reconsider the design and try to make it fit.

Right, my motivation in pursuing this topic is to avoid going down 
the slippery slope of unrealistic trust models where (i) edge 
entities are trusted as key distributors, especially to entities 
deeper in the network, and (ii) assumptions of secure links in the 
network.  We cannot realistically assume that the infrastructure and 
edge routers are secure (if we do, for instance, NETLMM doesn't need 
any security protocol between the MAG and the LMA).

thanks,
Lakshminath

>            jak
>
>----- Original Message ----- From: "Narayanan, Vidya" <[email-masked]>

---

From: Wassim Haddad <[email-masked]>
Date: Fri, 18 Aug 2006 17:09:20 +0300 (EEST)

Hello Lakshminath,

On Fri, 18 Aug 2006, Lakshminath Dondeti wrote:

> We cannot realistically assume that the infrastructure and

=> The routing infrastructure is assumed to be SECURE.

Don't you agree with that?

Wassim H.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 18 Aug 2006 04:22:59 -0700

Hi James,

Please see inline:

><snip>  <covered elsewhere>

>Regarding the threat of ARs being compromised, the issue is not 
>whether or not it should be ignored, but rather how much effort 
>should be put into defending against it. Threat mitigation is always 
>an issue of tradeoffs. If the threat is smaller, then heroic efforts 
>to mitigate it from a protocol standpoint, when simple physical 
>security is always in place, are, in a sense, overengineering. An 
>example of where such a tradeoff was made is in the return 
>routability protocol for MIP6 security in RFC 3775. The protocol has 
>a residual vulnerability, but the threat is considered to be 
>relatively minor. But the threat was not ignored, it is described 
>clearly in the Security Considerations section. Any protocol that 
>has a threat from AR compromise would need to indicate that physical 
>security of the AR is required for mitigation.

Oh absolutely.  I am all for agreeing, if there is a consensus, that 
certain threats are noted and considered "manageable."  We are not in 
the business of designing for the non-achievable goal of "perfect" security.

That said, we also follow certain security design principles that are 
considered bare minimum, some of which have been thankfully documented.

One of them is the so called "Internet threat model."  So if the 
binding update is between the MAP and the MN, we can consider 
everything in the middle as "untrusted" just as that threat model 
assumes. This works well in that, as long as there is an 
uncompromised AR between the MAP and the MN, the MN should get 
service.  If a compromised AR were to be involved in key distribution 
at some point in time, until that SA expires, the MAP and the MN 
cannot be sure whether there is a MiTM, and that's not desirable.

>I think the issue from an architectural standpoint is where the 
>trust relationships are, how they are established, etc. One pattern 
>is to have a centralized network entity, such as an AAA server, be 
>the trust anchor. The 802.1x/802.11e three party trust model never 
>ends up with a trust relationship between the AP and the terminal, 
>in the sense that the two authenticate to each other. The AP trusts 
>the terminal because the AAA server does, and likewise between the 
>terminal and the AP. The other pattern is the IKE/IPsec distributed 
>model, where a root of trust between two entities is established, 
>and the trust relationship is bootstrapped from there. In that case, 
>the two entities do trust each other, because of the cert chain back 
>to the root of trust allows them to authenticate each other. I think 
>a key distribution and security protocol that fits into one or the 
>other of these models is much more likely to be understandable and 
>secure than one that attempts to do something different.

In all of this I see the pattern I describe in my paragraph above.  A 
network entity (e.g., AAA, PKI) facilitates SA establishment between 
the MN and an edge (or closer to the edge) entity.  In the HMIPv6sec 
design I saw the opposite, that alarmed and hence I am engaged in 
this discussion.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 18 Aug 2006 07:53:04 -0700

Wassim,

The word "secure" in those two contexts means different things and it 
is imperative that we understand what each means:

First, my sentence: elaborating, we cannot realistically assume that 
the infrastructure and edge routers are secure in that, from 3552, "
we assume that the attacker has nearly complete control
    of the communications channel over which the end-systems communicate.
    This means that the attacker can read any PDU (Protocol Data Unit) on
    the network and undetectably remove, change, or inject forged packets
    onto the wire.
"
That attacker may achieve that either by being on the wire or because 
he/she has control over one or more of the entities along the way (in 
the simplest model).

On your statement: The routing infrastructure is assumed to be 
secure.  Sure, we assume that as long as there is a uncompromised 
path (this is the routing protocol security model some people use) 
between two entities in the network, the packets will get there.  But 
note that there are no other guarantees assumed.  The packets will 
eventually get routed there, perhaps after an attacker as described 
in the previous paragraph may have interfered with the 
communication.  No assurances on that one way or another.

Hope that helps you understand where I am coming from.  Do you agree 
with that differentiation?

Lakshminath

---

From: "James Kempf" <[email-masked]>
Date: Fri, 18 Aug 2006 09:38:20 -0700

Lakshminath,

> Sorry for barging in on your email to Vidya, but let me take a stab at 

No problem.

> We can envision a hot-spot model where APs may be deployed in accessible 
> locations and ARs may be deployed in let's say semi-accessible locations 
> (the APs and one or more ARs comprising a hot-spot) and the rest of the 
> backend less and less accessible for physical compromise, culminating in 
> MAPs and especially AAA servers being in the most secure locations.  Is 
> that a possible deployment model?
>

Service providers don't want people fooling around with their routers, and 
for most deployment circumstances in service provider networks there is no 
reason why routers can't be deployed in secure locations. Routers, unlike 
access points, don't require public deployments in order to achieve good 
radio reception. If there is customer premises equipment involved, its 
possible that the deployment might be less secure if the customer's security 
procedures are sloppy.

> If a hot-spot owner controlled the "edge network" and the service provider 
> controlled the rest of the network, wouldn't we say that AR compromise is 
> a real threat (if nothing, due to administrative boundaries)? 
> Specifically, the service provider would want to avoid the domino effect 
> by limiting the impact of a compromise of a hot-spot to just that 
> hot-spot's coverage.  Does that make sense?
>

This particular case involves propagating information across an 
administrative boundary. In such a case, naturally, the core network service 
provider must take care that the information coming from the access network 
service provider is trustworthy. And the security architecture needs to make 
sure that this threat is accommodated.

However, for this case, I believe the focus of the threat analysis must 
shift to the access network provider. It is incumbent upon the access 
network provider that they secure their access equipment.

>>trusted AR. The threat is, however, mentioned. We concentrated on 
>>mitigating the threat of a masqurading AR, which is not possible to deter 
>>using physical security, and is a very real threat for 802.11 end nodes.
>
> parties to the protocol is compromised, we have a tough problem.  The best 
> we can hope for is that the MN should be able to identify a misbehaving 
> AR.
>
>
>>opportunity. As I mentioned in the original post, I don't have an opinion 
>>on the HIMP security protocol (otherwise I would have continued to post 
>>under the original thread) except that I think it should try to fit 
>>post, it does not, then I think the authors would do well to reconsider 
>>the design and try to make it fit.
>
> Right, my motivation in pursuing this topic is to avoid going down the 
> slippery slope of unrealistic trust models where (i) edge entities are 
> trusted as key distributors, especially to entities deeper in the network, 
> and (ii) assumptions of secure links in the network.  We cannot 
> realistically assume that the infrastructure and edge routers are secure 
> (if we do, for instance, NETLMM doesn't need any security protocol between 
> the MAG and the LMA).
>

I agree with you up to the last sentence. I think there is a difference 
between "assuming" security, and performing a threat analysis in which the 
threats are enumerated and realistic countermeasures are appraised, 
including physical security.

Regarding your point about NETLMM, the security protocol between the MAG and 
LMA is intended to make sure that a) both the MAG and LMA are authenticated 
to each other, so that both can verify that the other is authorized to 
provide mobility service b) if the NETLMM protocol is running over a public 
access network, the protocol exchanges are confidential. Note that neither 
of these protects against the threat of MAG compromise. The cryptomaterial 
used by the MAG to prove authorization is valid for some period of time, and 
until that period elapses (or, alternatively, the compromise is discovered 
and the MAG is put on a CRL), the authentication with the LMA will succeed. 
These security measures are intended to protect against an attacker 
masquerading as an authorized LMA or MAG, not an authorized LMA or MAG that 
is compromised. A compromised LMA or MAG will only be discovered by noting 
differences in its behavior, and then brought off line or put onto the CRL. 
There is an important and critical difference here, IMHO.  Do you agree that 
there is a difference?

Anyway, enough about NETLMM. We should take this to the NETLMM list if you 
want to discuss it further.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 18 Aug 2006 09:57:12 -0700

> certain threats are noted and considered "manageable."  We are not in the 
> business of designing for the non-achievable goal of "perfect" security.
>
> One of them is the so called "Internet threat model."  So if the binding 
> update is between the MAP and the MN, we can consider everything in the 
> middle as "untrusted" just as that threat model assumes. This works well 
> in that, as long as there is an uncompromised AR between the MAP and the 
> MN, the MN should get service.  If a compromised AR were to be involved in 
> key distribution at some point in time, until that SA expires, the MAP and 
> the MN cannot be sure whether there is a MiTM, and that's not desirable.
>

I guess the point I am trying to make is that it is not possible to mitigate 
the threat of AR compromise by protocol security measures alone. As long as 
the AR can prove its authorization, the authorization with the MAP will 
succeed. The only indication that compromise has occured is observation of 
the AR's behavior. Then its cryptomaterial can be revoked and it can be 
brought offline.

Regarding key distribution, the link between the MAP and the AR must 
naturally be secured, so they need to exchange keys. If one or the other is 
compromised, then as above. Compromise can't be detected by the security 
protocol that proves authorization.

> network entity (e.g., AAA, PKI) facilitates SA establishment between the 
> MN and an edge (or closer to the edge) entity.  In the HMIPv6sec design I 
> saw the opposite, that alarmed and hence I am engaged in this discussion.
>

Like I said, I'm not commenting on the security architecture of the 
HMIPv6sec design. My preception is that you believe that it is possible to 
mitigate the threat of router compromise by protocol security measures, and 
I don't believe that is possible.

            jak

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 18 Aug 2006 11:15:34 -0700

There is no mitigation to any "threat" via a protocol design. The threat
exists and it is about mitigating the impact of a resulting attack
(entity compromise, in this case) via a good security protocol. That is
the reason security protocol designers look at the relevant threats and
design protocols to provide maximum protection against attacks resulting
from the existing threats. 

Vidya

> Sent: Friday, August 18, 2006 9:57 AM
> uncompromised 
> > AR between the MAP and the MN, the MN should get service.  If a 
> > compromised AR were to be involved in key distribution at 
> some point 
> > in time, until that SA expires, the MAP and the MN cannot 
> be sure whether there is a MiTM, and that's not desirable.
> >
> 
> I guess the point I am trying to make is that it is not 
> possible to mitigate the threat of AR compromise by protocol 
> security measures alone. As long as the AR can prove its 
> authorization, the authorization with the MAP will succeed. 
> The only indication that compromise has occured is 
> observation of the AR's behavior. Then its cryptomaterial can 
> be revoked and it can be brought offline.
> 
> Regarding key distribution, the link between the MAP and the 
> AR must naturally be secured, so they need to exchange keys. 
> If one or the other is compromised, then as above. Compromise 
> can't be detected by the security protocol that proves authorization.
> 
> > design I saw the opposite, that alarmed and hence I am 
> engaged in this discussion.
> >
> 
> Like I said, I'm not commenting on the security architecture 
> of the HMIPv6sec design. My preception is that you believe 
> that it is possible to mitigate the threat of router 
> compromise by protocol security measures, and I don't believe 
> that is possible.
> 
>             jak 
> 
> 
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 18 Aug 2006 12:42:49 -0700

James,
I'm sorry to see that you consider healthy technical discussions as
disagreement. Nevertheless, I will just point out one contradiction in
your emails and conclude thereafter. 

In your earlier email, you had said "My preception is that you believe
that it is possible to mitigate the threat of router compromise by
protocol security measures, and I don't believe that is possible."

In this email, you have said "Protocol design can mitigate the
consequences of a threat" and go on to say that "I've heard this shorted
to "mitigating the threat"", where I suppose "this" refers to
"mitigating the consequences of the threat". 

The above two clearly seem contradictory to me. I would like to at least
understand what you really meant here and how I've gone wrong in my
interpretation. 

Thanks,
Vidya

> Sent: Friday, August 18, 2006 12:23 PM
> To: Narayanan, Vidya; Wassim Haddad; Dondeti, Lakshminath
> Protocol design can mitigate the consequences of a threat. If 
> you want to split hairs, then, yes, the attack based on the 
> threat is what the protocol design is protecting against.  
> I've heard this shorted to "mitigating the threat", just as 
> when people use the short hand term "mobility management" 
> to mean "modification of packet routing to match changes in 
> host topological location".
> 
> Perhaps I need to include a "Terminology" section in my email? :-)
> 
> Anyway, we're not making much progress. It seems we don't 
> agree about much, so this is the last response I'll make to 
> you on this thread.
> 
>             jak
> 
> Sent: Friday, August 18, 2006 11:15 AM
> There is no mitigation to any "threat" via a protocol design. 
> The threat exists and it is about mitigating the impact of a 
> resulting attack (entity compromise, in this case) via a good 
> security protocol. That is the reason security protocol 
> designers look at the relevant threats and design protocols 
> to provide maximum protection against attacks resulting from 
> the existing threats.
> 
> Vidya
> 
> > I guess the point I am trying to make is that it is not possible to 
> > mitigate the threat of AR compromise by protocol security measures 
> > alone. As long as the AR can prove its authorization, the 
> > authorization with the MAP will succeed.
> observation of the 
> > AR's behavior. Then its cryptomaterial can be revoked and it can be 
> > brought offline.
> >
> > naturally be secured, so they need to exchange keys.
> > If one or the other is compromised, then as above. 
> Compromise can't be 
> > detected by the security protocol that proves authorization.
> >
> > HMIPv6sec design. My preception is that you believe that it is 
> > possible to mitigate the threat of router compromise by protocol 
> > security measures, and I don't believe that is possible.
> >
> >             jak
> >
> >
> >
> 
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 18 Aug 2006 12:22:45 -0700

Vidya,

Protocol design can mitigate the consequences of a threat. If you want to 
split hairs, then, yes, the attack based on the threat is what the protocol 
design is protecting against.  I've heard this shorted to "mitigating the 
threat", just as when people use the short hand term "mobility management" 
to mean "modification of packet routing to match changes in host topological 
location".

Anyway, we're not making much progress. It seems we don't agree about much, 
so this is the last response I'll make to you on this thread.

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Wassim Haddad" 

Vidya

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 19 Aug 2006 09:24:39 +0800

After having read the latest in this thread, let me summarize my take 
on this to avoid misunderstandings.

First, if an entity that is party to a protocol is compromised, we 
have a difficult problem to solve.  (James, you seem to be thinking 
this is the problem we are talking about, but that's not so; please 
read on).  We then go on to think about the impact of AR compromise; 
for instance, would it possible that compromise of an AR might impact 
MNs that are not using that AR?  If so, we should try and mitigate that, etc.

However, we are not talking about that here.  HMIP BUs go from the MN 
to the MAP.  An AR is not a party to this communication 
(sending/receiving BUs/BAcks).  I'd then apply the "Internet threat" 
model to the path in between the MN and the MAP.  As long as there is 
a path between the MN and the MAP, HMIP should work.  In other words 
if one or a few ARs are compromised, as long as there is an 
unhindered path between the MN and the MAP, the MN gets HMIP service.

Additional notes inline:

At 09:57 AM 8/18/2006, James Kempf wrote:
>>Oh absolutely.  I am all for agreeing, if there is a consensus, 
>>that certain threats are noted and considered "manageable."  We are 
>>not in the business of designing for the non-achievable goal of 
>>"perfect" security.
>>
>>That said, we also follow certain security design principles that 
>>are considered bare minimum, some of which have been thankfully documented.
>>
>>service.  If a compromised AR were to be involved in key 
>>distribution at some point in time, until that SA expires, the MAP 
>>and the MN cannot be sure whether there is a MiTM, and that's not desirable.
>
>authorization with the MAP will succeed. The only indication that 
>compromise has occured is observation of the AR's behavior. Then its 
>cryptomaterial can be revoked and it can be brought offline.

But again, as I noted above, in some cases ASs may not need to be 
involved in protocol security.  I have come at this in one angle 
before that generally speaking ARs are more vulnerable to attack 
(more on that in response to your other message).  The other aspect 
of it is to consider whether we need to involve ARs into security 
protocol design.  Where the ARs aren't parties to a protocol, we 
might try and not involve them, especially not when the AR is 
considered an entity in the middle.  So, an example where ARs don't 
need to be involved is in securing HMIP BU/BAcks; and NETLMM is an 
example where ARs are parties to the protocol and so we cannot avoid 
their involvement.

>naturally be secured, so they need to exchange keys. If one or the 
>other is compromised, then as above. Compromise can't be detected by 
>the security protocol that proves authorization.
>
>>network entity (e.g., AAA, PKI) facilitates SA establishment 
>>between the MN and an edge (or closer to the edge) entity.  In the 
>>HMIPv6sec design I saw the opposite, that alarmed and hence I am 

Question: given my clarification, can we revise your note above?  We 
don't really have to consider HMIPv6sec per se, but can focus on the 
high level.  In fact, I am spending so much time on this thread to 
get that baseline established.

thanks,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 19 Aug 2006 09:55:53 +0800

At 12:38 AM 8/19/2006, James Kempf wrote:
<snip>

Concentrating on the hot-spot model:

>>provider controlled the rest of the network, wouldn't we say that 
>>AR compromise is a real threat (if nothing, due to administrative 
>administrative boundary. In such a case, naturally, the core network 
>service provider must take care that the information coming from the 
>access network service provider is trustworthy. And the security 
>architecture needs to make sure that this threat is accommodated.
>
>However, for this case, I believe the focus of the threat analysis 
>must shift to the access network provider. It is incumbent upon the 
>access network provider that they secure their access equipment.

Suppose an SP has contracts with Hotspot-A and Hotspot-B as the 
access network providers.  Wouldn't it make sense, as much as 
possible, for the SP to make sure that compromise of HS-A does not 
compromise HS-B's network and the SP's own network?  I think it does.

Furthermore as I noted in another email, if a protocol is between the 
MN and the MAP (SP's service, let's say), then wouldn't it make sense 
to not involve the ARs to facilitate the property/requirement I 
stated in the previous paragraph.

>><snip>
>>>come up in other WGs, raised by you and Lakshimath, and I wanted 
>>>an opportunity to discuss the threat specifically with you both, 
>>>this seemed a good opportunity. As I mentioned in the original 
>>>post, I don't have an opinion on the HIMP security protocol 
>>>(otherwise I would have continued to post under the original 
>>>thread) except that I think it should try to fit architecturally 
>>>with an existing model. If, as you mentioned in a previous post, 
>>>it does not, then I think the authors would do well to reconsider 
>>network.  We cannot realistically assume that the infrastructure 
>>and edge routers are secure (if we do, for instance, NETLMM doesn't 
>>need any security protocol between the MAG and the LMA).
>
>I agree with you up to the last sentence. I think there is a 
>difference between "assuming" security, and performing a threat 
>analysis in which the threats are enumerated and realistic 
>countermeasures are appraised, including physical security.
>
>Regarding your point about NETLMM, the security protocol between the 
>MAG and LMA is intended to make sure that a) both the MAG and LMA 
>are authenticated to each other, so that both can verify that the 
>other is authorized to provide mobility service b) if the NETLMM 
>protocol is running over a public access network, the protocol 
>exchanges are confidential. Note that neither of these protects 
>against the threat of MAG compromise. The cryptomaterial used by the 
>MAG to prove authorization is valid for some period of time, and 
>until that period elapses (or, alternatively, the compromise is 
>discovered and the MAG is put on a CRL), the authentication with the 
>LMA will succeed. These security measures are intended to protect 
>against an attacker masquerading as an authorized LMA or MAG, not an 
>authorized LMA or MAG that is compromised. A compromised LMA or MAG 
>will only be discovered by noting differences in its behavior, and 
>then brought off line or put onto the CRL. There is an important and 
>critical difference here, IMHO.  Do you agree that there is a difference?

In this case, I was referring to (ii) above, just addressing the 
threats on the paths from LMA to MAGs.

Lakshminath

>Anyway, enough about NETLMM. We should take this to the NETLMM list 
>if you want to discuss it further.
>
>            jak

---

From: "Wassim Haddad \(KI/EAB\)" <[email-masked]>
Date: Sun, 20 Aug 2006 12:25:03 -0400

>your emails and conclude thereafter. 

=> A "healthy" discussion should also *stop* at some point.

Wassim H.

---

From: "Wassim Haddad \(KI/EAB\)" <[email-masked]>
Date: Sun, 20 Aug 2006 13:09:55 -0400

Lakshminath,

>read on).  

=> This is your own summary of your own comments. RFC 4140 does not 
mention anything in the security considerations about node compromise 
nor if the related problem is easy or difficult nor if it needs to be 
solved or not.

In *summary* to your summary, your comments are misleading.

>We then go on to think about the impact of AR compromise; 

=> First, you should back your comments with clear ways to mount such 
attack (other than physical compromise). I can also think about many 
ways to compromise the MAP which is much more interesting for an attacker 
(using means equal to physical compromise) than compromosing an AR during 
one particular interval of time in order to attack the draft that you are 
trying to attack. 

FYI, the operators infrastructures are not open for visitors nor tourists.
(I've personally been involved in deployment in a third world country and
saw how much securing the nodes themselves is critical). 

>(sending/receiving BUs/BAcks).  

=> and in the draft he is not involved in sending/receiving the BU/BA other
than routing.

>I'd then apply the "Internet threat" model to the path in between the MN 
>and the MAP.  

=> The threat analyze for HMIPv6 is well described in RFC4140 and it did
not mention an AR compromise. I think you should ask the authors why such
threat has not been mentioned especially that the AR in HMIPv6 intervenes 
in delivering MAP(s) information to the MNs.

>As long as there is a path between the MN and the MAP, HMIP should work.

=> sure. Add to this: "with only one AR working in the whole MAP domain"... 
which of course makes mobility even more attractive! :)

Wassim H.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Aug 2006 15:28:40 +0300

Lakshminath Dondeti wrote:

> I started with 4140's security considerations; that seems like a good
> starting point.

I read the 4140 security considerations. They are indeed a good
starting point. I particularly liked the description of what
authorization is needed for regional care-of-address
allocation.

There were a few things that I started to wonder
about though, such as:

- How important in reality the service authorization part is?
  You could also view this as an IP level service that is
  simply available in this network. (4140 classifies this
  as a MAY requirement, which I agree with.)

- However, it may be important for the mobile node to
  get an assurance that the MAP is authorized to act
  as a MAP. And perhaps authorized to act as a MAP
  in THIS network?

  That is, do we need security for the discovery of the
  MAP? Or, how does the mobile node authorize the
  MAP? Is it enough that it is one of the trusted MAPs
  in the roaming consortium?

- Is there a privacy requirement with respect to
  disclosing regional care-of-addresses to other
  nodes in the domain (e.g. in a BU sent to a MAP)?

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Mon, 21 Aug 2006 14:12:52 -0700

> involved in protocol security.  I have come at this in one angle before 
> that generally speaking ARs are more vulnerable to attack (more on that in 
> response to your other message).  The other aspect of it is to consider 
> whether we need to involve ARs into security protocol design.  Where the 
> ARs aren't parties to a protocol, we might try and not involve them, 
> especially not when the AR is considered an entity in the middle.  So, an 
> example where ARs don't need to be involved is in securing HMIP BU/BAcks; 
> and NETLMM is an example where ARs are parties to the protocol and so we 
> cannot avoid their involvement.
>

Yes, I agree with this. If there is no need to involve the AR in the 
security protocol, then it should not be involved. That is what I was trying 
to get at (perhaps incomprehensibly) in my earlier text about trust 
relationshps.

> Question: given my clarification, can we revise your note above?  We don't 
> really have to consider HMIPv6sec per se, but can focus on the high level. 
> In fact, I am spending so much time on this thread to get that baseline 
> established.
>

I agree that it makes sense to limit the number of entities involved in a 
security protocol to just those that are necessary.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 21 Aug 2006 14:17:42 -0700

> access network providers.  Wouldn't it make sense, as much as possible, 
> for the SP to make sure that compromise of HS-A does not compromise HS-B's 
> network and the SP's own network?  I think it does.
>

Yes.

> Furthermore as I noted in another email, if a protocol is between the MN 
> and the MAP (SP's service, let's say), then wouldn't it make sense to not 
> involve the ARs to facilitate the property/requirement I stated in the 
> previous paragraph.
>

Of course.

>>Regarding your point about NETLMM, the security protocol between the MAG 
>>and LMA is intended to make sure that a) both the MAG and LMA are 
>>authenticated to each other, so that both can verify that the other is 
>>authorized to provide mobility service b) if the NETLMM protocol is 
>>running over a public access network, the protocol exchanges are 
>>confidential. Note that neither of these protects against the threat of 
>>MAG compromise. The cryptomaterial used by the MAG to prove authorization 
>>is valid for some period of time, and until that period elapses (or, 
>>alternatively, the compromise is discovered and the MAG is put on a CRL), 
>>the authentication with the LMA will succeed. These security measures are 
>>intended to protect against an attacker masquerading as an authorized LMA 
>>or MAG, not an authorized LMA or MAG that is compromised. A compromised 
>>LMA or MAG will only be discovered by noting differences in its behavior, 
>>and then brought off line or put onto the CRL. There is an important and 
> In this case, I was referring to (ii) above, just addressing the threats 
> on the paths from LMA to MAGs.
>

Right. Securing the paths won't reduce threat of node compromise, however. 
That's where physical security comes in, and good security software 
engineering to avoid leaving holes like buffer overflows.

I think we have pretty good agreement on this, thanx for the conversation.

            jak

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 22 Aug 2006 06:55:46 +0800

At 05:17 AM 8/22/2006, James Kempf wrote:

>>>Regarding your point about NETLMM, the security protocol between 
>>>the MAG and LMA is intended to make sure that a) both the MAG and 
>>>LMA are authenticated to each other, so that both can verify that 
>>>the other is authorized to provide mobility service b) if the 
>>>NETLMM protocol is running over a public access network, the 
>>>protocol exchanges are confidential. Note that neither of these 
>>>protects against the threat of MAG compromise. The cryptomaterial 
>>>used by the MAG to prove authorization is valid for some period of 
>>>time, and until that period elapses (or, alternatively, the 
>>>compromise is discovered and the MAG is put on a CRL), the 
>>>authentication with the LMA will succeed. These security measures 
>>>are intended to protect against an attacker masquerading as an 
>>>authorized LMA or MAG, not an authorized LMA or MAG that is 
>>>compromised. A compromised LMA or MAG will only be discovered by 
>>>noting differences in its behavior, and then brought off line or 
>>>put onto the CRL. There is an important and critical difference 
>>>here, IMHO.  Do you agree that there is a difference?
>>
>Right. Securing the paths won't reduce threat of node compromise, 
>however. That's where physical security comes in, and good security 
>software engineering to avoid leaving holes like buffer overflows.

Definitely agree with you there!

>I think we have pretty good agreement on this, thanx for the conversation.

Indeed.  Thank you.

Lakshminath

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 22 Aug 2006 11:49:35 +0300 (EEST)

> Right. Securing the paths won't reduce threat of node compromise, however.

=> I don't think anyone disagree with this.

> That's where physical security comes in,

=> And its existence cannot be ignored especially that the amount of
damage caused by an AR compromise is by far larger than the scope of
HMIPsec.

Wassim H.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 22 Aug 2006 17:09:44 +0800

Wassim,

I think using an AR for HMIP key management increases the impact of 
compromise of the AR (I have explained how in my previous 
emails).  You seem to think otherwise.  So, I have a request for you:

Please provide a comparative threat analysis assuming an AR is 
vulnerable to compromise between the following two cases:
  1) assume IKE (4140's suggestion) as the key management protocol for HMIP.
  2) assume the protocol in draft-haddad-mipshop-hmipv6-security-06 
as the solution.

Perhaps you might also add Vidya's suggestion of CGA-authenticated 
IKE as the solution into the mix and perform the analysis.

Looking forward to hearing from you.

thanks,
Lakshminath

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 22 Aug 2006 23:35:17 +0300 (EEST)

Lakshminath,

> emails).  You seem to think otherwise.  So, I have a request for you:

=> An AR compromise means disrupting the MN's session, preventing
connectivity and disrupting the whole MAP domain and should not mean
less than that. The problem is that you keep insisting on one very
particular scenario in which the AR will be compromised just to hit
an HMIPsec session!

Well, my *poor* understanding and basic assessment is that when the
AR gets compromised then the ability/inability to establish an SA
with the MAP (name the protocol that you want) does not bring any
benefit to the MN.

Or perhaps you can help me guess how a compromised AR would behave
after a MN succeeds in establishing a SA with the MAP? Will it allow
the MN to exchange data or will it simply discard the HoTI and/or
CoTI messages and block the ongoing session without any effect on
the HMIP protocol or will it simply block everything else?

Wassim H.

P.S: I have nothing to add to the above!

>   2) assume the protocol in draft-haddad-mipshop-hmipv6-security-06

=> I don't think you need to compare 1) and 2) when you *are dealing* with a
compromised AR from the beginning. The reason is that beside killing all MN's
sessions and disrupting the whole MAP domain, a compromised AR can allow you
to achieve 1) and get an SA between the MAP and the MN (without any involvement
from the AR) AND it can also allow you to achieve 2) with an involvement from
the compromised AR but your session will never start and you'll never receive
any packets because the main goal for the attacker was/is to discard only the
HoTI and CoTI messages that you're sending to the CN and HA to re-route the
session.

> IKE as the solution into the mix and perform the analysis.

=> I've told Vidya that you don't need IKE when you apply CGA on the MAP
and MN. But of course, if an AR is compromised then even in this case you
won't be able to establish any session.

Wassim H.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 23 Aug 2006 17:07:39 -0700

Wassim,
This has been repeated many times, but let me try again. The scenario we
have been talking about is the compromise of an AR affecting the HMIP
session of an MN even when the MN is no longer attached to the same AR.
It is true that once an AR is compromised, all bets are off for sessions
through that particular AR. However, an MN connected to an uncompromised
AR must still be able to carry on its sessions without interruption. 

Consider this sequence of events: 

1. MN shows up at AR1 and establishes an SA with the MAP, with the help
of a key provided by AR1. 
2. MN moves to ARx and still uses HMIP with the MAP
3. AR1 gets compromised
4. AR1 sends a BU pretending to be the MN, with a fake LCoA
5. Traffic meant to the MN gets redirected to the fake LCoA

Do you think the above sequence will still be feasible even if AR1 was
not involved in setting up the SA with the MAP? If so, please explain
how that will be the case. 

Regards,
Vidya

> Sent: Tuesday, August 22, 2006 1:35 PM
> To: Dondeti, Lakshminath
> Cc: [email-masked]
> Subject: [Mipshop] Re: What happens if an AR is compromised? 
> (Re: How probable is compromise of an AR?)
> 
> Lakshminath,
> 
> > compromise of the AR (I have explained how in my previous emails).  
> > You seem to think otherwise.  So, I have a request for you:
> 
> => An AR compromise means disrupting the MN's session, 
> preventing connectivity and disrupting the whole MAP domain 
> and should not mean less than that. The problem is that you 
> keep insisting on one very particular scenario in which the 
> AR will be compromised just to hit an HMIPsec session!
> 
> Well, my *poor* understanding and basic assessment is that 
> when the AR gets compromised then the ability/inability to 
> establish an SA with the MAP (name the protocol that you 
> want) does not bring any benefit to the MN.
> 
> Or perhaps you can help me guess how a compromised AR would 
> behave after a MN succeeds in establishing a SA with the MAP? 
> Will it allow the MN to exchange data or will it simply 
> discard the HoTI and/or CoTI messages and block the ongoing 
> session without any effect on the HMIP protocol or will it 
> simply block everything else?
> 
> 
> Wassim H.
> 
> => I don't think you need to compare 1) and 2) when you *are 
> dealing* with a compromised AR from the beginning. The reason 
> is that beside killing all MN's sessions and disrupting the 
> whole MAP domain, a compromised AR can allow you to achieve 
> 1) and get an SA between the MAP and the MN (without any 
> involvement from the AR) AND it can also allow you to achieve 
> 2) with an involvement from the compromised AR but your 
> session will never start and you'll never receive any packets 
> because the main goal for the attacker was/is to discard only 
> the HoTI and CoTI messages that you're sending to the CN and 
> HA to re-route the session.
> 
> > Perhaps you might also add Vidya's suggestion of 
> CGA-authenticated IKE 
> > as the solution into the mix and perform the analysis.
> 
> => I've told Vidya that you don't need IKE when you apply CGA 
> on the MAP and MN. But of course, if an AR is compromised 
> then even in this case you won't be able to establish any session.
> 
> 
> Wassim H.
> 
> 
> 
> 
>