Subject: [Mipshop] Review of draft-haddad-mipship-hmipv6-security-04

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 26 Jul 2006 17:53:07 -0700

Summary:  The protocol and key management mechanisms specified in 
draft-haddad-mipshop-hmipv6-security-04 do NOT meet the security 
requirements of HMIPv6 (RFC 4140).  The protocol as specified today 
amounts to an unauthenticated Diffie-Hellman exchange without 
liveness verification.  In its current shape the draft is NOT ready 
to be accepted as a working group document.

It is plausible to extend the protocol to make it an authenticated DH 
protocol, but the question is why that exercise would be 
necessary.  The IETF has developed several protocols using DHE, and 
it would make sense to re-use one of them instead of coming up with 
yet another one.  In fact, 4140 alludes to the use of IKE.  It is not 
clear whether the authors of the draft ruled that out.

Furthermore, it is also not clear whether a DH-based exchange is in 
fact necessary.  It would be worthwhile to start with a set of 
requirements.  I will try and do that in the detailed review below.

Review:
--------

Before the review, let us consider the security requirements of the 
HMIPv6 protocol.  From RFC 4140's security considerations, the 
security relationship between the MN and the MAP MUST
have mutual authentication, integrity protection, and protection 
against replay attacks.  A non requirement is that the RCoA does not 
need to be bound to a particular node and that
a mobile node does not have to initially (before the first binding 
update) prove that it owns its RCoA when it establishes a Security 
Association with its MAP.

Now I am not as intimately familiar with HMIPv6 as the authors, but 
going by the security considerations, it appears that there is no 
need to cryptographically or otherwise bind the RCoA to the 
LCoA.  What's more, in fact, such a binding would force the RCoA to 
change every time the LCoA changes.  So perhaps RCoA derivation as a 
function of LCoA and a key delivered by the AR is not the correct way 
to approach this problem.  Furthermore, if that aspect is taken out, 
perhaps there is no need for a CGA-based approach for HMIPv6 
security.  Perhaps I am missing a requirement that came about after 
4140 was written.  If that is the case, I would like to hear about it.

About the only thing CGAs are used in this draft for is to identify 
the public key of a node without PKI support.  But I think key 
delivery by the AR is not attractive.  More on that in the next paragraph.

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.  Furthermore, even if we make that leap, it is not clear 
why the AR needs to communicate the LCoA to RCoA binding to the 
MAP.  Next, it appears from 4140 that an MN may establish an SA 
associated with an RCoA and then change its LCoA as necessary.  If 
that is the model to be supported, with the solution proposed in the 
draft, the AR (assuming potential compromise of the AR) can always 
insert bogus BUs.

It appears that the goal of the protocol is to derive a Ksm.  For 
that purpose a 1 round-trip unauthenticated DH protocol is 
proposed.   Now, because there is no authentication, any entity in 
the middle can hijack the session.  Furthermore, there are no nonces 
or timestamps associated with the exchange, i.e., there is no replay 
protection.  There is also no integrity protection on the 
messages.  All told, the protocol does not meet even one of the 
requirements listed in 4140.

In summary, this draft is far from ready to be considered as a 
working group draft.

thanks,
Lakshminath

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

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 28 Jul 2006 18:01:21 -0400

Hi Lakshminath,
   Thanks for the comments. Please find my responses inline.

Cheers
Suresh

Lakshminath Dondeti wrote:
<snipped summary>
> HMIPv6 protocol.  From RFC 4140's security considerations, the security 
> relationship between the MN and the MAP MUST
> have mutual authentication, integrity protection, and protection against 
> replay attacks.  A non requirement is that the RCoA does not need to be 
> bound to a particular node and that

It is not a requirement. But what do you think is wrong with doing this?

> going by the security considerations, it appears that there is no need 
> to cryptographically or otherwise bind the RCoA to the LCoA.  What's 
> more, in fact, such a binding would force the RCoA to change every time 
> the LCoA changes.  

Absolutely Not. See explanation below

> So perhaps RCoA derivation as a function of LCoA and 
> a key delivered by the AR is not the correct way to approach this 
> problem.  

The RCoA is bound to the LCoA only in the initial case when the MN 
enters the HMIP domain. When the MN changes the LCoA it DOES NOT have to 
change the RCoA. I am not sure where you are getting this idea.

> Furthermore, if that aspect is taken out, perhaps there is no 
> need for a CGA-based approach for HMIPv6 security.  Perhaps I am missing 
> a requirement that came about after 4140 was written.  If that is the 
> case, I would like to hear about it.
> 
> About the only thing CGAs are used in this draft for is to identify the 
> public key of a node without PKI support.  But I think key delivery by 
> the AR is not attractive.  More on that in the next paragraph.
> 
> 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?

> Furthermore, even if we make that leap, it is not clear why the AR needs 
> to communicate the LCoA to RCoA binding to the MAP.

>  Next, it appears 
> from 4140 that an MN may establish an SA associated with an RCoA and 
> then change its LCoA as necessary.  If that is the model to be 
> supported, with the solution proposed in the draft, the AR (assuming 
> potential compromise of the AR) can always insert bogus BUs.

A compromised AR can just as well null route the traffic. I don't see 
the point.

> 
> It appears that the goal of the protocol is to derive a Ksm.  For that 
> purpose a 1 round-trip unauthenticated DH protocol is proposed.   Now, 
> because there is no authentication, any entity in the middle can hijack 
> the session.  Furthermore, there are no nonces or timestamps associated 
> with the exchange, i.e., there is no replay protection.  There is also 
> no integrity protection on the messages.  All told, the protocol does 
> not meet even one of the requirements listed in 4140.

As I said in the reply to Vidya's mail we are adding replay protection 
mechanisms to the next revision of the draft. I would be happy if you 
can give me an example message exchange when an entity in the middle can 
hijack the session. That said, we are open to adding a MAC to the LBU 
and the BA messages.

> 
> In summary, this draft is far from ready to be considered as a working 
> group draft.
> 
> thanks,
> Lakshminath
> 
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 28 Jul 2006 17:19:18 -0700

Hi Suresh,

Thanks for your response.  There are several topics in the previous 
thread and so I figured it is best to address them separately.  I 
will take up the DH exchange here.

First, let me point out that including the hash of a key does not 
provide entity authentication in a DH exchange.  In fact,  I don't 
know what purpose including a hash of a key serves.  Please explain.

Next, it is important to note that it is very easy to get the design 
of a DH-based key exchange protocol wrong.  It is generally advisable 
to re-use an existing design.  A lot of thought went into the design 
of IKEv2 and that protocol itself is based on SIGMA, which has gone 
through a good amount of analysis and review.  So, I'll reiterate 
that if DH-based key management is the solution for HMIPv6, we should 
just use IKEv2 (trimmed of its non-security related payloads, as necessary).

Since you asked how the protocol in 
draft-haddad-mipshop-hmipv6-security-04 might be hijacked, let's start there:

First the protocol:

MN->MAP:   X = g^a, LCoA, RCoA
MAP->MN:   Y = g^b, h(Ks)

Ksm = g^ab

Attack:

MN->MAP:             X = g^a, LCoA, RCoA
Attacker->MAP:     Z = g^c, LCoA, RCoA
MAP->MN :            Y = g^b, h(Ks)
Attacker->MN:      W = g^d, h(Ks)

MN and Attacker compute Ksm1 = g^ad  (MN thinks the attacker is the MAP)
Attacker and MAP compute Ksm2 = g^bc (MAP thinks the attacker is the MN)

Future BU and BAs can be modified by the attacker at will.

There is also no integrity or replay protection on the messages.  So, 
there is no assurance for either party that the exchange is live or 
unmodified in transit!

If you plan to use timestamps for replay protection, that implies 
secure time synchronization between the MAP and MN, which in itself 
can be hard to support.

regards,
Lakshminath

>>2. The DH exchange is unauthenticated and hence subject to MiTM attacks.
>
>Again. Not true. The exchange is not subject to MiTM attacks. Since 
>the TPHS option contains the hash of the Ks a third party cannot spoof the MAP.

At 03:01 PM 7/28/2006, Suresh Krishnan wrote:
><snipped>
>>the middle can hijack the session.  Furthermore, there are no 
>>nonces or timestamps associated with the exchange, i.e., there is 
>>no replay protection.  There is also no integrity protection on the 
>As I said in the reply to Vidya's mail we are adding replay 
>protection mechanisms to the next revision of the draft. I would be 
>happy if you can give me an example message exchange when an entity 
>in the middle can hijack the session. That said, we are open to 
>adding a MAC to the LBU and the BA messages.
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 28 Jul 2006 17:42:47 -0700

Hi Suresh,

Continuing the discussion on the topic of using the AR as the key distributor.

Generally speaking, edge entities are easy to physically get access 
to and therefore easy to compromise.  The idea of AR as the key 
distributor to a network entity and the MN seems to ignore that 
vulnerability.  Note that in your protocol, a compromised AR can 
continue to send bogus BUs even after the MN has moved away from that AR.

Suppose the credential verification is reliant on AAA servers, then 
the key management protocol would work even if the AR is compromised.

Thoughts?

regards,
Lakshminath

At 03:01 PM 7/28/2006, Suresh Krishnan wrote:

>>the network.

---

From: Wassim Haddad <[email-masked]>
Date: Sun, 30 Jul 2006 17:56:55 +0300 (EEST)

> 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.

> 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.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 30 Jul 2006 10:59:54 -0700

Wassim,

I am not opposed to using SEND in general.  However, I appreciate the 
fact that there are networks which may not want to use SEND; that is 
all.  In fact, SEND works well for the purposes it is defined and 
extending it to do other things is also fine with me.  But we must 
work with a consistent threat model in developing security protocols.

As I noted before, my knowledge of HMIPv6 goes only so far, and if my 
comments are based on any misunderstanding of that protocol, please 
feel free to point that out to me.

Section 12.1 of RFC 4140 discusses MN to MAP security and says that 
the BUs MUST be protected between those entities using AH or 
ESP.  AR  is an entity that happens to be in the middle of that 
communication path.  Are you suggesting that we should ignore MiTM 
attacks?  What is the threat model you use in your analyses?

I reiterate that edge entities are more vulnerable to compromise than 
entities deeper in the network.  I would like to hear others opinions 
and reasoning behind any opposing views on that.

thanks,
Lakshminath

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 31 Jul 2006 10:49:30 -0400

Hi Lakshminath,
   Please find my comments inline.

Thanks
Suresh

<snip>
> Attacker and MAP compute Ksm2 = g^bc (MAP thinks the attacker is the MN)

This is the part I where we disagree. For this to be true one of these 
two conditions have to be true.

a) The attacker is an Access Router who can pull packet X and Y off the 
wire. Otherwise the Packet X will reach the MAP and packet Y will reach 
the MN, right?
b) The attacker is on-path (not a router), manages to see the MNs 
message X going though the wire and somehow creates a new message Z and 
sends it to reach the MAP before X. Likewise it sees message Y, and 
sends message W to reach the MN before Y.

According to me
a) is very unlikely, and even if it is likely is the same issue as the 
AR compromise.
b) is impossible.

So given this, can we agree to close this as an issue?

> If you plan to use timestamps for replay protection, that implies secure 
> time synchronization between the MAP and MN, which in itself can be hard 
> to support.

Point taken. Will use a nonce.

>>> protection.  There is also no integrity protection on the messages.  
>>> All told, the protocol does not meet even one of the requirements 
>>> listed in 4140.
>>
>> can give me an example message exchange when an entity in the middle 
>> can hijack the session. That said, we are open to adding a MAC to the 
>> LBU and the BA messages.
>>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 31 Jul 2006 08:26:00 -0700

Hi Suresh,

Please see inline:

At 07:49 AM 7/31/2006, Suresh Krishnan wrote:
>This is the part I where we disagree. For this to be true one of 
>these two conditions have to be true.
>
>a) The attacker is an Access Router who can pull packet X and Y off 
>the wire. Otherwise the Packet X will reach the MAP and packet Y 
>will reach the MN, right?
>message X going though the wire and somehow creates a new message Z 
>and sends it to reach the MAP before X. Likewise it sees message Y, 
>and sends message W to reach the MN before Y.
>
>According to me
>a) is very unlikely, and even if it is likely is the same issue as 
>the AR compromise.
>b) is impossible.
>

No, we cannot close the issue.   I can see where you are coming from 
now, and I think this is not a matter of disagreement between 
us.  You are working with a threat model that I think is not inline 
with the threat models we use at the IETF.

I am tempted to respond to your points a) and b), but that is not 
very useful.  Let's start with the threat model.   Please write it up 
and send it to this list.  We should start the discussion 
there.   I'd use 3552 as a guideline.

I am also very curious to know -- given your statements a and b above 
-- why you are using DH in the first place

>>There is also no integrity or replay protection on the 
>>messages.  So, there is no assurance for either party that the 
>>exchange is live or unmodified in transit!

Note that when you use nonces, the exchange is at the very least a 
3-way exchange.

Lakshminath

>>>Again. Not true. The exchange is not subject to MiTM attacks. 
>>>Since the TPHS option contains the hash of the Ks a third party 
>>>cannot spoof the MAP.
>>>>proposed.   Now, because there is no authentication, any entity 
>>>>in the middle can hijack the session.  Furthermore, there are no 
>>>>no replay protection.  There is also no integrity protection on the messages.
>>>protection mechanisms to the next revision of the draft. I would 
>>>be happy if you can give me an example message exchange when an 
>>>entity in the middle can hijack the session. That said, we are 
>>>open to adding a MAC to the LBU and the BA messages.
>>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 31 Jul 2006 12:04:19 -0700

> a) is very unlikely, and even if it is likely is the same issue as the 

FWIW, I don't think you can assume b). in general, by assuming a)
and b), you seem to be lowering the bar for designing security
protocols.

Vijay

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 31 Jul 2006 16:23:39 -0400

Hi Lakshminath,
   Please see comments inline.

Thanks
Suresh

> now, and I think this is not a matter of disagreement between us.  You 
> are working with a threat model that I think is not inline with the 
> threat models we use at the IETF.
> 
> I am tempted to respond to your points a) and b), but that is not very 
> useful.  Let's start with the threat model.   Please write it up and 
> send it to this list.  We should start the discussion there.   I'd use 
> 3552 as a guideline.
> 

OK. I think our basic disconnect comes from the fact that we (the 
authors) view the routers as trustable entities and you do not. We will 
come up with a threat model and discuss this further. We will have a new 
revision of the draft soon with significant changes to the protocol and 
will add some text to the security considerations as to what threats are 
not covered.

<snip>

> Note that when you use nonces, the exchange is at the very least a 3-way 
> exchange.

That's why we wanted to avoid them in the first place. But since replay 
protection is required we may not have a choice but to include them.

<snip>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 31 Jul 2006 13:46:34 -0700

At 01:23 PM 7/31/2006, Suresh Krishnan wrote:
>>No, we cannot close the issue.   I can see where you are coming 
>>from now, and I think this is not a matter of disagreement between 
>>very useful.  Let's start with the threat model.   Please write it 
>>up and send it to this list.  We should start the discussion 
>authors) view the routers as trustable entities and you do not. We 
>will come up with a threat model and discuss this further. We will 
>have a new revision of the draft soon with significant changes to 
>the protocol and will add some text to the security considerations 
>as to what threats are not covered.

Ok, will look forward to that.  Could you send brief notes on the 
threats you are considering and the potential adversaries, so I can 
start thinking about this problem too?  As I was noting, in the 
limited model you are considering, DH may not even be necessary.

I have a related question.  Given that you are working with a limited 
threat model and given that the problem of malicious/compromised 
routers is a concern in some networks, are you suggesting that 
MIPSHOP would work on another solution for HMIPv6 security to address 
a more common/generic threat model?

thanks,
Lakshminath

>That's why we wanted to avoid them in the first place. But since 
>replay protection is required we may not have a choice but to include them.
>
>>Lakshminath
>
><snip>
>

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 31 Jul 2006 23:54:12 +0300 (EEST)

> and b), you seem to be lowering the bar for designing security

=> can you explain why? Note that the protocol starts with building a
trust between the MN and the AR then relying on the fact that links
between routers within the MAP tree are secure.

Wassim H.

P.S: this seems to be the beginning of a discussion which may require at
some stage a comparaison with the security of the RO mode in MIPv6... But
let's start with this one).

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 31 Jul 2006 14:00:46 -0700

Wassim Haddad wrote:
> => can you explain why? 

the assumption b) is about ordering of the packets. Suresh
claimed that the message Z cannot reach the MAP before X.
I don't think you can assume this.

> some stage a comparaison with the security of the RO mode in MIPv6... 

I guess you want to compare MN-AR-MAP to MN-HA-CN. correct?
the trust assumed between MN-HA and between MN-AR is different.
from what I see the mechanisms are different too.

Vijay

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 1 Aug 2006 00:08:00 +0300 (EEST)

> limited model you are considering, DH may not even be necessary.

=> IMHO the DH is necessary to establish a long lifetime bidirectional
SA between the MN and the MAP during the first BU/BA exchange. Note that
there is a compromise made in the draft which exploits the existence of
SEND to allow the MN to use the key between the AR and the MAP *just*
during the first BU/BA message. So if you want to analyze the threat model
you should consider the compromise made at the beginning.

> a more common/generic threat model?

=> IMHO, we are not working with a limited threat model. There is a compromise
which is based on SEND (without SEND it would have been impossible to use it).

Wassim H.

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 1 Aug 2006 00:18:24 +0300 (EEST)

> I don't think you can assume this.

=> can you please elaborate more? There is a clear assumption in the draft
about the security between routers in the HMIPv6 tree.
> from what I see the mechanisms are different too.

=> I prefer to compare the the existence of a malicious node between the
HA and the CN able to read the HoT message and to send its own CoTI message.

Wassim

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 31 Jul 2006 14:26:19 -0700

> about the security between routers in the HMIPv6 tree.

the routers just forward packets from whoever it is. what is
preventing the message Z from reaching the MAP before message
X?

> HA and the CN able to read the HoT message and to send its own CoTI message.

the security model for the return routability mechanism is
explained in RFC 4225. nobody claimed the return routability
mechanism is perfect. it is susceptible to attackers on the
HA-CN path. you shouldn't use that to justify other work.

Vijay

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 31 Jul 2006 14:44:41 -0700

Hi Wassim,

Thanks for your response.  Please see inline:

>SA between the MN and the MAP during the first BU/BA exchange.

Hmm, why do you need DH for that?  Can't we use a scheme that works 
using nonces, for instance the protocol described in

Entity Authentication and key distribution
Authors: M. Bellare and P. Rogaway
Ref: Extended abstract in Advances in Cryptology - Crypto 93 
Proceedings, Lecture Notes in Computer Science Vol. 773, D. Stinson 
ed, Springer-Verlag, 1994.

Next, the lifetime would be dependent on the freshness and size of 
the nonces or the freshness of the key itself (the latter, when one 
party delivers a key).

>Note that

Are you saying that the compromise is the key distribution done by 
the AR to the MN and the MAP?  If I may summarize it here:

'the AR selects a secret (Ks), encrypts it with the MN's CGA public 
key and sends it in the unicast RtAdv message.'

I see problems with that key delivery, for instance, the MN has no 
way of knowing who sent the Ks it receives, or whether the entity 
that sent the key is live or not.  What are your thoughts on those issues?

Next, how do you expect the key Ks to be used?  All I see in the I-D 
is that the MAP sends a hash of Ks in a BA to the MN.  I am not sure 
what the hash of Ks is supposed to achieve.  Could you please explain 
the properties of that design?  Thanks.

Finally, can you elaborate the notion of the SEND-based key delivery 
used for "just during the first BU/BA message?"  I think I have 
already explained that the compromise in the design is exploitable as 
long as the SA derived thereof is in use.

>which is based on SEND (without SEND it would have been impossible to use it).

We can agree to disagree.  I have pointed out the many things your 
design is not taking into consideration or otherwise not 
addressing.  As Suresh noted, a clearly defined threat model may help 
us all get on the same track on the limitations or comprehensiveness 
of your design.

thanks,
Lakshminath

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 1 Aug 2006 00:45:42 +0300 (EEST)

> preventing the message Z from reaching the MAP before message

=> Obviously am missing somthing here (am on holiday or supposed to
be!! so I have not read the previous emails yet). Again the assumption is
taht all links are secure within the MAP tree. Please explain how under
this assumption the attack can occur.

> HA-CN path. you shouldn't use that to justify other work.

=> have nothing to add here!

Wassim H.

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 1 Aug 2006 01:25:44 +0300 (EEST)

> that sent the key is live or not.  What are your thoughts on those issues?

=> The Mn can know who sent Ks in the same way as it can know who sent the
RA message.

> the properties of that design?  Thanks.

=> The hash of the key is sent by the MAP in the BA message to allow the
MN to detect if the BA message is valid or not. However, this is clearly
not enough and an authentication is needed and has been added to avoid
potential issues in case the MN misses the BA message and re-sends a BU
message.

> long as the SA derived thereof is in use.

=> It means that after establishing the bidirectional SA, Ks is removed
from the MAP BCE. I don't see how you can exploit such design excpet if
the AR is compromised in which case the harm goes beyond such attack.
Peraps you can explain.

> We can agree to disagree.

=> OK. Hope the new security consideration will make it clearer and we
won't have to agree on disagreeing.

Regards,
Wassim H.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 31 Jul 2006 16:49:00 -0700

>=> The Mn can know who sent Ks in the same way as it can know who sent the

Ok, works as long as the RA messages are signed and include a 
nonce/TS as per SEND.  My mistake.  Thanks.

>potential issues in case the MN misses the BA message and re-sends a BU

Good.  So, the hash of the key is being removed in the revised design?

>the AR is compromised in which case the harm goes beyond such attack.

A couple of things here.  First, yes, the AR compromise issue looms 
of course.  Parking that for the moment, the second issue is 
unauthenticated DH exchange.  You said earlier that that is being 
fixed in the revised design.  I will look forward to that.

>won't have to agree on disagreeing.

We can discuss again once the new draft is published with the threat 
model, revised design and revised security considerations.  One 
thing, I will ask you guys to consider is what happens when an AR is 
compromised.  Sure when an AR is compromised, all kinds of things 
might go wrong, but what if an MN moves away from that AR (after 
noticing lack of or substandard service)?  Can the AR continue to 
disrupt MN's communications?  If the AR is involved in key 
distribution, the answer is yes (when the AR launches an active 
attack on the DHE).  If it is not involved in key distribution, the 
answer is no.

Thanks,
Lakshminath