Subject: Re: [Mip4] Authentication Mandate for All Registration Reply Messages

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 16 Dec 2009 11:12:37 -0500

We had some discussion on this in Hiroshima but I don't think
we came to a satisfactory conclusion.  Does anyone have an 
objection to requiring authentication on a rejection message?

We'd like to submit 3344bis to the IESG soon, so it would be
good to have a resolution on this issue in the next few days
so that Charlie can submit a revised version.

Thanks,

-Pete

Charles E. Perkins wrote:
> Hello folks,
> 
> I've written up a new Internet Draft for submission next week.
> 
> Here is the abstract.
>>    Some implementations of Mobile IP home agents have been observed
>>    to supply zero authentication data when sending a Registration
>>    Reply to the mobile node that contains rejection code 131 (Mobile
>>    Node Failed Authentication).  This creates a vulnerability
>>    whereby a mobile node could be denied service from its home
>>    agent, and thus lose connectivity to the Internet even though
>>    mobile node and home agent were otherwise functioning properly.
>> 
> 
> If possible, I would like to have a slot at the upcoming IETF to
> discuss this matter.  It would be a short presentation. 
> 
> Regards,
> Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 16 Dec 2009 15:50:43 -0800

Hello folks,

After the last IETF meeting, I received some review comments
from Simon Mizikovsky from Alcatel-Lucent on my proposal.
I have reformatted his comments below. I will follow up with
some additional comments in another message. At the end,
I have included Simon's email address also. These comments
refer to the text in draft-perkins-mip4-authreqd-00.txt, which I
presented during the [mip4] working group meeting.

==========================================
======== Comments from Simon Mizikovsky ==========
==========================================

 > ......... Even if the mobile node does retransmit the
 > Registration Reply message,

Perhaps, Registration Request?

 > In the specific case of rejection Code 131, there is a likelihood
 > that the mobile node's security association with its home agent needs
 > to be refreshed, if the authentication data supplied with the
 > Registration Request message were not correct.

In a real case scenario, when both MN-HA and MN-HA-SPI are
computed from EMSK, the HA will not know the new MN-HA after
re-authentication, but link to the AAA would be broken,
disallowing it to retrieve the new MN-HA.

 > It would be an
 > unfortunate error if a malicious agent were able to trigger re-
 > establishment of the mobile node's Mobility Security Association.

But if RRQ got to bad FA, it would simply not forward it to the HA.

 > Since, for Code 131, there are no retries specified in the Mobile-IP
 > protocol specification [1]. a single malicious packet could trigger
 > the loss of even a newly established and valid Mobility Security
 > Association between the mobile node and the home agent.

Usually, good client implementations allow some grace period for
not immediately issue the re-registration, but rather wait for
another RRP, possibly with properly signed MN-HA AE. The race
condition between right and bogus RRP can not be solved otherwise.

 > We propose that all Registration Reply messages MUST contain a valid
 > Mobile-Home Authentication Extension, with nonzero authentication
 > data generated according to the security algorithm indicated by the
 > SPI present in the Authentication extension. This is required
 > whether or not the Mobile Node is identified putely by its IP
 > address, or if the Mobile Node NAI extension is also supplied.

But this is impossible in absence of a valid MN-HA SA! Presence of
invalid MN-HA-AE or Zero-filled MN-HA AE is as bad as absence of
MN-HA AE with Error Code 131.

 > As specified in section 3.6.2.1 of [1], if a Mobile Node receives a
 > Registration Reply message that does not contain a Mobile-Home
 > Authentication Extension, or one with zero authentication data, the
 > Mobile Node MUST silently discard that packet.

Sorry, I disagree.

 > A mobility security association between the Home Agent and the Mobile
 > node MAY be configured especially For the purpose of supplying the
 > authentication data to the Mobile Node when a Registration Request is
 > rejected, This alternative security association MAY use a default SPI
 > number, or any other different SPI that may be convenient.

If the assumption here is a special SA pre-configured for handling
error cases, than it is a very bad idea. Consider: If all mobile
nodes knew it, than it would not be a secret, and any interloper
could use it to sign a bogus RRP.

 > This may
 > also include an SPI in the range of well-known SPI numbers, but not
 > any reserved value for the SPI.

Another case is not examined: What if there is a MN-FA SA? The
FA then MUST include the MN-FA AE, and a conflicting error case
may occur when either MN-FA-AE or MN-HA-AE is not valid. How
should MN behave then?

 > This document identifies a security exposure that might disrupt a
 > mobile node's ability to connect to the Internet, and proposes a
 > solution to eliminate this exposure. It does not create any new
 > security exposures.

I don’t think this solution works in cases of dynamic HA
assignment and computed MN-HA and MN-FA SAs.

Semyon Mizikovsky
Alcatel Lucent
Wireless Security & Fraud Prevention
Wireless Standards Department
600/700 Mountain Avenue, 3C-506L
Murray Hill, NJ 07974, USA
(O) 1+908-582-0729
(M) 1+732-239-7533
(F) 1+908-743-4361

PLEASE NOTE MY NEW EMAIL ADDRESS:
[email-masked]
===========================================

Regards,
Charlie P.

PS. Simon also pointed out a few typos which I have not
reproduced in this email.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 16 Dec 2009 16:32:25 -0800

Yes (oops).

> disallowing it to retrieve the new MN-HA.

In this case, what remedy is made available?

> But if RRQ got to bad FA, it would simply not forward it to the HA.

Yes, that is true.  Or maybe the bad FA would just originate
a lot of bad traffic to the HA.  There are many such annoying
behaviors possible.

> condition between right and bogus RRP can not be solved otherwise.

I think this is a good idea.  Perhaps it should be specified as
something the mobile node SHOULD do.  I realize it is not
required (strictly speaking) for interoperability, but it might be
the best solution for the problem with code 131.

> MN-HA AE with Error Code 131.

Well, O.K., but see below...

> > Mobile Node MUST silently discard that packet.

Here is the language:

                                                                   If 
the Registration
           Reply was generated by the home agent but no Mobile-Home
           Authentication Extension is found, or if more than one
           Mobile-Home Authentication Extension is found, or if the
           Authenticator is invalid, the mobile node MUST silently
           discard the Reply and SHOULD log the event as a security
           exception.

That seems pretty definite to me.  Do you think it should be
worded differently?

> could use it to sign a bogus RRP.

How about if it were particular to the mobile node, but had a very
very long lifetime?

> may occur when either MN-FA-AE or MN-HA-AE is not valid. How

If the MN-HA authentication is valid, but the MN-FA authentication
is not valid, then I'm not sure what to suggest.  A conservative
approach is to try to re-establish the MN-FA security association
and then re-register with the home agent.  I can imagine several other
approaches, each of which might satisfy different network administrators.
As far as I'm concerned, the mobile node could consider itself
registered, but in the service area of a flaky access router.
> assignment and computed MN-HA and MN-FA SAs.

You've identified some serious problems!  Still, perhaps other
scenarios might benefit from some additional specification.

Regards,
Charlie P.

---

From: "Mizikovsky, Semyon B (Simon)" <[email-masked]>
Date: Thu, 17 Dec 2009 13:05:35 -0600

Charles, please see in-line with [sm]

Semyon Mizikovsky
Alcatel Lucent

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Wednesday, December 16, 2009 7:32 PM
To: Mizikovsky, Semyon B (Simon)
Cc: Mobile IPv4 Mailing List
Subject: Re: [Mip4] Authentication Mandate for All Registration Reply Messages

Charles E. Perkins wrote:
> > ......... Even if the mobile node does retransmit the Registration
> > Reply message,
>

Yes (oops).

> > that the mobile node's security association with its home agent
> > needs to be refreshed, if the authentication data supplied with the
> In a real case scenario, when both MN-HA and MN-HA-SPI are computed
> from EMSK, the HA will not know the new MN-HA after re-authentication,
> but link to the AAA would be broken, disallowing it to retrieve the
> new MN-HA.

In this case, what remedy is made available?
[sm] One thing comes to mind: MN should not purge the old MN-HA before it received an RRP signed by the new MN-HA. Thant way, the HA may sign the RRP with old existing MN-HA because it could not access the AAA and retrieve the new MN-HA based on the new SPI. MN would be able to verify the RRP using the old MN-HA, and get an indication that HA is on its own. The old MN-HA would have to coexist with the new MN-HA until its natural death, after which it will not exist in either MN or HA. From that point on, the RRP Reject with code 131 - unsigned - would be appropriate.

> But if RRQ got to bad FA, it would simply not forward it to the HA.

Yes, that is true.  Or maybe the bad FA would just originate a lot of bad traffic to the HA.  There are many such annoying behaviors possible.

> Usually, good client implementations allow some grace period for not
> immediately issue the re-registration, but rather wait for another
> RRP, possibly with properly signed MN-HA AE. The race condition
> between right and bogus RRP can not be solved otherwise.

I think this is a good idea.  Perhaps it should be specified as something the mobile node SHOULD do.  I realize it is not required (strictly speaking) for interoperability, but it might be the best solution for the problem with code 131.

[sm] I think so. Can not think of anything as clean and as cheap.

> invalid MN-HA-AE or Zero-filled MN-HA AE is as bad as absence of MN-HA
> AE with Error Code 131.

Here is the language:

                                                                   If the Registration

That seems pretty definite to me.  Do you think it should be worded differently?

[sm] Let's go over the scenarios:
MN sent the RRQ with the MN-HA-AE containing unknown SPI. HA needs to send the RRP but it can not get the proper MN-HA associated with this SPI. In other words, there is no valid security association between MN and HA. HA can:
1) Send the RRP signed by its current existing MN-HA (if it exists), different from the one used by the MN in RRQ. If MN retains the old MN-HA, we are home free.

2) Send the RRP with 131 unsigned. The MN will assume this is temporary outage (not DoS) and resend the RRQ after a short while, hoping for the best. If in a grace period the right RRP does not come, and retry comes again unsigned, then - sorry - access unsuccessful.

3) Send the RRP with MN-HA-AE set to Zeros. This case is not different from (2) because the treatment by the MN would be just the same.

So, sending RRP without MN-HA-AE or with bogus "all zero" MN-HA-AE is the same!

>
>
> > A mobility security association between the Home Agent and the
> > Mobile node MAY be configured especially For the purpose of
> > supplying the authentication data to the Mobile Node when a
> > Registration Request is rejected, This alternative security
> > association MAY use a default SPI number, or any other different SPI that may be convenient.
>
>
> error cases, than it is a very bad idea. Consider: If all mobile nodes
> knew it, than it would not be a secret, and any interloper could use
> it to sign a bogus RRP.

How about if it were particular to the mobile node, but had a very very long lifetime?

[sm] How would HA know it? What if HA is dynamically assigned? HA would have to query the AAA for it, so why would not it query AAA for the right MN-HA in the first place?

> Another case is not examined: What if there is a MN-FA SA? The FA then
> MUST include the MN-FA AE, and a conflicting error case may occur when
> either MN-FA-AE or MN-HA-AE is not valid. How should MN behave then?

If the MN-HA authentication is valid, but the MN-FA authentication is not valid, then I'm not sure what to suggest.  A conservative approach is to try to re-establish the MN-FA security association and then re-register with the home agent.  I can imagine several other approaches, each of which might satisfy different network administrators.
As far as I'm concerned, the mobile node could consider itself registered, but in the service area of a flaky access router.
> I don't think this solution works in cases of dynamic HA assignment
> and computed MN-HA and MN-FA SAs.

You've identified some serious problems!  Still, perhaps other scenarios might benefit from some additional specification.

[sm] I think we all appreciate that somehow, and thanks to you Charles, MIPv4 works as is, without these changes. Have a nice Holiday Season!

Simon

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 17 Dec 2009 13:07:07 -0800

Hello Simon,

> [sm] One thing comes to mind: MN should not purge the old MN-HA before it received an RRP signed by the new MN-HA. Thant way, the HA may sign the RRP with old existing MN-HA because it could not ac…

Suppose the mobile node receives a RREP with code 131.  Then there
are multiple cases:
- MN-HA security association is valid, and the RREP can be authenticated.
    Then, what should the mobile node do?  This could happen if a malicious
    node sent a bogus RREQ to the home agent.    In fact, it could happen
    even if the mobile node did not recently send any RREQ message at all.
    If so, maybe it is safer for the mobile node to re-register with a 
proper
    RREQ, but always doing so would enable a malicious node to make
    additional cryptographic work for the mobile node.  Maybe such a
    re-registration should only be done when the mobile node has in fact
    recently sent a re-registration.  Or, ...?

- MN-HA authentication data cannot be validated in the RREP.  This is
   the case I think we have been discussing.  Here, the mobile node should
   wait for another RREP.    If no RREP arrives, the mobile node should
   probably act as if its registration security association is invalid.

> [sm] I think so. Can not think of anything as clean and as cheap.

O.K.  I will write up something along these lines.

> So, sending RRP without MN-HA-AE or with bogus "all zero" MN-HA-AE is the same!

O.K.  We can agree that those two cases in your last sentence are 
practically
equivalent.

But:
- I thought you were disagreeing with "silently discard".
- "silently discard" is compatible with "wait for another RREP to arrive"
- "silently discard" isn't 100% compatible with "expunge MN-HA 
association and
        begin to establish a new MN-HA security association".

I thought that there was some train of thought whereby it was better to 
have zero
authentication data instead of a missing MN-HA authentication extension, 
because of
the way that some people had read the original specification language.  
But anyway
I agree with you and don't see any technical difference except that the 
former
approach wastes a little more bandwidth over the air.
was "better" than a missing.

Nevertheless it might be reasonable to specify something about when
the mobile node ought to re-establish its security association.

Except that MIPv4 never did anything like that in the past.  It was
all laid out in the AAA specifications, as far as I remember.

> [sm] How would HA know it? What if HA is dynamically assigned? HA would have to query the AAA for it, so why would not it query AAA for the right MN-HA in the first place?

Well, the idea is to enable solutions sometimes even if not every system
design can make use of the solution.  So, if HA has to query AAA to get
the longer-lived key, that doesn't bother me.  Mobile IP was designed a
long time before AAA anyway.  If this were a different discussion, I'd
complain a lot about typical AAA system designs, but here I will have to
forgo that opportunity.  However sometimes I wish someone would explain
to me why operators insist on using the most time-consuming and heavyweight
approaches imaginable, and then wonder why they can't get sufficient
performance.  More round trips over the network and queueing delays
at the servers?  No problem, right??  They should just use Mobile IP and
be done with it.  The HA was, after all, designed to be a secure router
with a near-trivial update protocol.  (<== easy to understand).

Thanks for your holiday wishes.  I hope that many good things
are routed your way.

Regards,
Charlie P.