Subject: Re: [Mip4] Authentication Mandate for AllRegistration Reply Messages

From: Ahmad Muhanna <[email-masked]>
Date: Wed, 13 Jan 2010 02:16:44 -0500

Hello Charlie,

I believe your idea is valuable and worth adding to MIP4. As a matter of fact, it introduces a mechanism which more deterministic and does NOT depend on trial and error/guessing, for example, client waiting for the next RRP after receiving the first RRP with code 131. In order to make sure that we are in sync I would like to list the details of my understanding of the proposal:

1. We should be able to reserve an SPI that is for "MN-HA default SA", this SPI should be less than 255.

2. Whenever the HA receives a RRQ message with MN-HA AE that failed authentication based on the MN-HA SA that the HA believes is the current MN-HA SA with this MN, the HA should send an RRP message using the default MN-HA SA and SPI value of "MN-HA default SA"

3. When the MN receives the RRP with code 131 with MN-HA AE based on the default MN-HA SA and the "MN-HA default SA" SPI, the MN should be able to validate the RRP.

What is the characteristics for this default MN-HA SA?

1. This default MN-HA SA could be statically configured with a long lifetime as you suggested, or

2. If people are worried about this SA being statically configured with a long lifetime and AAA is used to derive dynamic MN-HA SA for the MN, I am sure that mechanism can be used to also generate another MN-HA SA to be called the default MN-HA SA and indexed with SPI "MN-HA default SA". This will be very helpful in the case (mentioned by Simon) when the HA is NOT able to access the AAA server for example.

BTW: In case the MN does not have a default MN-HA SA, the current logic should work. I believe the text can be tweaked to preserve backward compatibility in the case when the default MN-HA SA is not used.

Regards,
Ahmad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles E. Perkins
Sent: Thursday, December 17, 2009 3:07 PM
To: Mizikovsky, Semyon B (Simon)
Cc: Mobile IPv4 Mailing List
Subject: Re: [Mip4] Authentication Mandate for AllRegistration Reply
Messages

Hello Simon,

Mizikovsky, Semyon B (Simon) wrote:
>
>>> 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.
>>
>
> 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.

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.

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

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

>
>
>>
>>> 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.
>>
>
> 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?
>
> [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!

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.

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

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.

--
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 13 Jan 2010 09:44:21 -0800

Hello Ahmad,

> 1. We should be able to reserve an SPI that is for "MN-HA default SA", this SPI should be less than 255.

This is a separable part of the proposal.  It's not necessary, but it
might be useful.

> 2. Whenever the HA receives a RRQ message with MN-HA AE that failed authentication based on the MN-HA SA that the HA believes is the current MN-HA SA with this MN, the HA should send an RRP message…

Right -- or, whatever SPI has been assigned to the "special"
MN-HA security association, in case it isn't in the reserved section.

> 3. When the MN receives the RRP with code 131 with MN-HA AE based on the default MN-HA SA and the "MN-HA default SA" SPI, the MN should be able to validate the RRP.

Yes.

> ...

Right.  In fact, I am pretty sure that no text is required in order
to enable use of such a "special" or "secondary" MN-HA
security association.  However, it might be valuable to insert
a paragraph explaining the value of maintaining the alternative
MN-HA SA for use in the case of code 131.  I can do that
quickly if the idea meets WG approval.

Regards,
Charlie P.

---

From: "Mizikovsky, Semyon B (Simon)" <[email-masked]>
Date: Wed, 13 Jan 2010 11:47:21 -0600

Sorry, I disagree with both Charles and Ahmad. The default SA does not work. If it is defined THE SAME  for all Mobile Nodes, it might as well be ALL ZEROS, or not exist at all. If it is defined INDIVIDUALLY for each Mobile Node, than the HA may not be able to get it from the AAA, the same way it may not be able to get an actual real active SA. So defining the default MN-HA and SPI makes no sense.

In fact, the default SA may even become quite dangerous, as it will be known to the malicious node masquerading itself as the HA, and signing the RRP "Reject" with it thus throwing the Mobile out of existing valid binding.

What I have suggested to Charles is the following:

1. If HA has a SA which is assumed valid, even though it has been refreshed on the MN, the HA SHALL use this assumed valid SA to sign the RRP. This will cause situations when MN has an updated MN-HA(2) and MN-HA-SPI(2) while HA still has an old (but still live) MN-HA(1) and MN-HA-SPI(1). The SPI(2) received by the HA in the RRQ will cause the HA to access the AAA querying for the MN-HA(2) associated with SPI(2). If this link is unavailable, or AAA responds with Access Reject, the HA SHALL use the MN-HA(1) and MN-HA-SPI(1) to sign the RRP "Reject". The Mobile SHALL retain the MN-HA(1) and MN-HA-SPI(1) until either their lifetime expiration or until it receives an RRP signed with the updated MN-HA(2), whichever comes first. At this time the MN-HA(1) and associated SPI(1) are purged.

2. If HA  has no valid SA with the mobile, it SHALL respond with unsigned 131.

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]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ahmad Muhanna
Sent: Wednesday, January 13, 2010 2:17 AM
To: [email-masked]
Subject: Re: [Mip4] Authentication Mandate for AllRegistration Reply Messages

Hello Charlie,

Regards,
Ahmad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles E. Perkins
Sent: Thursday, December 17, 2009 3:07 PM
To: Mizikovsky, Semyon B (Simon)
Cc: Mobile IPv4 Mailing List
Subject: Re: [Mip4] Authentication Mandate for AllRegistration Reply Messages

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

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.

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

the Registration
differently?
> 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.
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.

that may be convenient.
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?

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.

---

From: Ahmad Muhanna <[email-masked]>
Date: Wed, 13 Jan 2010 13:04:42 -0500

Hello Charlie,
Please see inline.
________________________________________
From: Charles E. Perkins [[email-masked]]
Sent: Wednesday, January 13, 2010 11:44 AM
To: Ahmad Muhanna
Cc: [email-masked]
Subject: Re: [Mip4] Authentication Mandate for AllRegistration  Reply   Messages

Hello Ahmad,

[Ahmad]
I agree it is NOT necessary and a solution can exist without it. However, since this MN-HA SA serves a very specific role for a very specific case, there is absolutely no harm to define a well known SPI. That will also be helpful in case the default MN-HA SA is dynamically allocated.

[Ahmad]
Sure, please see my comment above.

Yes.

[Ahmad]
I agree.
After reading the text that Pete quoted in his other email, I think the existing text cover this case. However, an explanation of the error code 131 as Pete quoted it probably worth adding somewhere. It would help. Also, as you said adding some text as an example wont hurt.

Regards,
Charlie P.

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 13 Jan 2010 13:18:52 -0500

Hi, Simon,

I tend to agree that the text of 3344bis should not call out
a designated "default" SPI.  Nothing in the text prevents you
from configuring such an SA if you want in a particular deployment,
but the configuration of SAs has always been out of scope of the
base document.

By the same reasoning, it would seem that the particular scheduling
of when to purge a previous SA would also be out of scope.  So I'm
not sure what kind of text we would add to implement part (1) of your
suggestion.  Maybe just a clarification that the HA should always use
what it thinks is a valid SA when sending a Reply?

As for part (2), what is the value of sending a Reply with no 
authentication?  It seems to have the same drawbacks that you mention 
for the case of a "default" SA.  Why would an MN in any way act
on such an unsigned Reply?

-Pete

Mizikovsky, Semyon B (Simon) wrote:
> Sorry, I disagree with both Charles and Ahmad. The default SA does
> not work. If it is defined THE SAME  for all Mobile Nodes, it might
> as well be ALL ZEROS, or not exist at all. If it is defined
> INDIVIDUALLY for each Mobile Node, than the HA may not be able to get
> it from the AAA, the same way it may not be able to get an actual
> real active SA. So defining the default MN-HA and SPI makes no sense.
>
> In fact, the default SA may even become quite dangerous, as it will
> be known to the malicious node masquerading itself as the HA, and
> signing the RRP "Reject" with it thus throwing the Mobile out of
> existing valid binding.   
>
> 1. If HA has a SA which is assumed valid, even though it has been
> refreshed on the MN, the HA SHALL use this assumed valid SA to sign
> the RRP. This will cause situations when MN has an updated MN-HA(2)
> and MN-HA-SPI(2) while HA still has an old (but still live) MN-HA(1)
> and MN-HA-SPI(1). The SPI(2) received by the HA in the RRQ will cause
> the HA to access the AAA querying for the MN-HA(2) associated with
> SPI(2). If this link is unavailable, or AAA responds with Access
> Reject, the HA SHALL use the MN-HA(1) and MN-HA-SPI(1) to sign the
> RRP "Reject". The Mobile SHALL retain the MN-HA(1) and MN-HA-SPI(1)
> until either their lifetime expiration or until it receives an RRP
> signed with the updated MN-HA(2), whichever comes first. At this time
> the MN-HA(1) and associated SPI(1) are purged.           
> 
> I believe your idea is valuable and worth adding to MIP4. As a matter
> of fact, it introduces a mechanism which more deterministic and does
> NOT depend on trial and error/guessing, for example, client waiting
> for the next RRP after receiving the first RRP with code 131. In
> order to make sure that we are in sync I would like to list the
> details of my understanding of the proposal:     
> 
> 2. Whenever the HA receives a RRQ message with MN-HA AE that failed
> authentication based on the MN-HA SA that the HA believes is the
> current MN-HA SA with this MN, the HA should send an RRP message
> using the default MN-HA SA and SPI value of "MN-HA default SA"   
> 
> 3. When the MN receives the RRP with code 131 with MN-HA AE based on
> the default MN-HA SA and the "MN-HA default SA" SPI, the MN should be
> able to validate the RRP.  
> 
> 2. If people are worried about this SA being statically configured
> with a long lifetime and AAA is used to derive dynamic MN-HA SA for
> the MN, I am sure that mechanism can be used to also generate another
> MN-HA SA to be called the default MN-HA SA and indexed with SPI
> "MN-HA default SA". This will be very helpful in the case (mentioned
> by Simon) when the HA is NOT able to access the AAA server for
> example.      
> 
> BTW: In case the MN does not have a default MN-HA SA, the current
> logic should work. I believe the text can be tweaked to preserve
> backward compatibility in the case when the default MN-HA SA is not
> used.   
> 
> Regards,
> Ahmad
> 
> 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.       
>> 
> 
> 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
>     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, ...?
> 
>    should wait for another RREP.    If no RREP arrives, the mobile
>    node should probably act as if its registration security
> association is invalid. 
> 
> 
>>            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. 
>> 
> SPI. In other words, there is no valid security association between
> MN and HA. HA can:  
> hoping for the best. If in a grace period the right RRP does not
> come, and retry comes again unsigned, then - sorry - access
> unsuccessful.   
>> 
>> So, sending RRP without MN-HA-AE or with bogus "all zero" MN-HA-AE
>> is the same! 
>> 
> 
>         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. 
> 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. 
> 
>> 
>>> 
>>>> association MAY use a default SPI number, or any other different
>>>> SPI that may be convenient. 
>>>> 
> 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).            
> 
>

---

From: Ahmad Muhanna <[email-masked]>
Date: Wed, 13 Jan 2010 13:20:27 -0500

Hello Simon,
Please see inline [Ahmad].
________________________________________
From: Mizikovsky, Semyon B (Simon) [[email-masked]]
Sent: Wednesday, January 13, 2010 11:47 AM
To: Ahmad Muhanna; [email-masked]
Subject: RE: [Mip4] Authentication Mandate for AllRegistration  Reply   Messages

Sorry, I disagree with both Charles and Ahmad. The default SA does not work. If it is defined THE SAME  for all Mobile Nodes, it might as well be ALL ZEROS, or not exist at all. 

[Ahmad] Why do we need to mandate the default MN-HA SA needs to be the same for all MN?

If it is defined INDIVIDUALLY for each Mobile Node, than the HA may not be able to get it from the AAA, the same way it may not be able to get an actual real active SA. 

[Ahmad]
Please read the whole text of my posting and please see other people views. We can not think of everything based on a single usecase and a single mechanism. The new proposal does not break anything and it should work as well as the one you are referring to, if not better. If the HA is not able to communicate with the AAA server, I believe there is far more serious problems than a MN is rejected registration using error code 131. At any rate, the HA can always fall back to the current logic. I do not see any problem there.

So defining the default MN-HA and SPI makes no sense.
[Ahmad]
I disagree. But I respect your opinion.

[Ahmad]
You keep making your argument around a single case. Please try to see other usecases. As I said to Pete, we probably do not need to add any new normative text anyway. However, I believe using a special SPI can be very useful.

[Ahmad]
Yes, I read that earlier. If your implementation would like to continue to use this logic, there is NO problem. Let us NOT prevent other alternative which IMO is very useful.

Regards,
Ahmad

Semyon Mizikovsky
Alcatel Lucent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ahmad Muhanna
Sent: Wednesday, January 13, 2010 2:17 AM
To: [email-masked]
Subject: Re: [Mip4] Authentication Mandate for AllRegistration Reply Messages

Hello Charlie,

Regards,
Ahmad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles E. Perkins
Sent: Thursday, December 17, 2009 3:07 PM
To: Mizikovsky, Semyon B (Simon)
Cc: Mobile IPv4 Mailing List
Subject: Re: [Mip4] Authentication Mandate for AllRegistration Reply Messages

Hello Simon,

the Registration
differently?
the same!

But:

that may be convenient.
very long lifetime?

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 13 Jan 2010 11:02:09 -0800

Hello Simon,

What if we suppose that the "default" (better, the "alternative") SA is only
suggested as a solution in cases where the operational difficulties cited
by you do not pertain?

For one thing, Mobile IP can be operated independently of AAA.
So, in those circumstances, your concern may not be applicable.
For another thing, there are systems where the HA is nearly
guaranteed to have access to AAA.  For such systems, likewise it
should be quite possible to expect to get access to the alternative SA.

> In fact, the default SA may even become quite dangerous, as it will be known to the malicious node masquerading itself as the HA, and signing the RRP "Reject" with it thus throwing the Mobile out o…

Can't we have security that is secure, and to write
the specification to maintain the secure security?  I have a hard
time believing that it is infeasible to install a particular security
association in a secure way.

> 1. If HA has a SA which is assumed valid, even though it has been refreshed on the MN, the HA SHALL use this assumed valid SA to sign the RRP. This will cause situations when MN has an updated MN-H…

As best I can tell, this isn't able to be specified without
reference to AAA, and I don't think the upcoming revision
of the document should introduce mechanisms related to
AAA protocol actions.  Wouldn't this be done better as
a separate Internet Draft?  If you like, I could help write
it up for additional comment outside the context of rfc3344bis.

> 2. If HA  has no valid SA with the mobile, it SHALL respond with unsigned 131.

This doesn't conform to "silently discard".

Regards,
Charlie P.

---

From: "Mizikovsky, Semyon B (Simon)" <[email-masked]>
Date: Wed, 13 Jan 2010 13:50:46 -0600

Charles, Pete,

I tend to agree with your comment that in absence of the valid SA, the HA SHALL silently discard the RRQ. We could also discuss if the HA MAY send the unsigned 131 for record-keeping purposes. I have no strong opinion about this.

Regarding the "default" or "alternative" SA at the HA - it still makes no sense to me. Sorry Ahmad and Charles. The valid SA is either available or not. If it is available (alive), it needs to be used to validate the MN-HA AE in the RRQ and generate the MN-HA AE in RRP. Of course this SA may be pre-configured or retrieved. In case it is pre-configured, it MUST exist in the MN as well, and there would be no case of it existing only in MN or only in HA. Therefore all invalid RRQs SHALL be rejected with the 131 signed by the valid SA. In case it is retrieved, it could be fresher in the MN than in the HA, in which case the SPI will indicate this. Again, if HA can retrieve the fresh SA - it SHALL use it to validate the RRQ sign the RRP. If it can not retrieve it - it SHALL sign the RRP with its current living SA.

Pete, regarding my comment for purging the old SA: it can be written as recommendation that in case when security associations change, the old SA needs to be retained by the peer until there is a positive confirmation that the new SA is used by the other peer, or until its lifetime expires.

Semyon Mizikovsky
Alcatel Lucent

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Wednesday, January 13, 2010 2:02 PM
To: Mizikovsky, Semyon B (Simon)
Cc: Ahmad Muhanna; [email-masked]
Subject: Re: [Mip4] Authentication Mandate for AllRegistration Reply Messages

Hello Simon,

What if we suppose that the "default" (better, the "alternative") SA is only suggested as a solution in cases where the operational difficulties cited by you do not pertain?

For one thing, Mobile IP can be operated independently of AAA.
So, in those circumstances, your concern may not be applicable.
For another thing, there are systems where the HA is nearly guaranteed to have access to AAA.  For such systems, likewise it should be quite possible to expect to get access to the alternative SA.

> In fact, the default SA may even become quite dangerous, as it will be known to the malicious node masquerading itself as the HA, and signing the RRP "Reject" with it thus throwing the Mobile out o…

Can't we have security that is secure, and to write the specification to maintain the secure security?  I have a hard time believing that it is infeasible to install a particular security association in a secure way.

> 1. If HA has a SA which is assumed valid, even though it has been refreshed on the MN, the HA SHALL use this assumed valid SA to sign the RRP. This will cause situations when MN has an updated MN-H…

As best I can tell, this isn't able to be specified without reference to AAA, and I don't think the upcoming revision of the document should introduce mechanisms related to AAA protocol actions.  Wouldn't this be done better as a separate Internet Draft?  If you like, I could help write it up for additional comment outside the context of rfc3344bis.

Regards,
Charlie P.

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 15 Jan 2010 13:21:21 -0500

Ok, let's see if we can come to some conclusion here.

Let me suggest we modify the *'d bullets under
3.8.2.1 (a).  They currently say:

       *  If there is a valid Foreign-Home authentication extension, the
          home agent MUST send a Registration Reply with Code 131.

       *  Otherwise, if there is no Foreign-Home security association,
          the home agent MAY send a Registration Reply to the mobile
          node with Code 131.  The home agent MUST then discard the
          Request and SHOULD log the error as a security exception.

What if we change them to this:

       *  If there is a valid Foreign-Home authentication extension, the
          home agent MUST send a Registration Reply with Code 131.

       *  Otherwise, if there is no Foreign-Home security association,
the
          home agent MAY send a Registration Reply with Code 131.

       If the home agent sends a Registration Reply, it MUST contain a
valid Mobile-Home
       Authentication Extension.  Note that in the case of an invalid
Authenticator
       in a Registration Request, it is very likely that either the
mobile node's
       or the home agent's security association database is out of date.
In
       constructing the Reply, the home agent SHOULD choose a security
association
       that is likely to exist in the mobile node; for example, this may
be an
       older security association or one with a longer lifetime than the
one that
       was attempted to be used by the mobile node in its Request.
Deployments
       should take care when updating security associations to ensure
that there
       is at least one common security association shared between the
mobile node
       and home agent.

       In any case of a failed Authenticator, the home agent MUST then
discard 
       the Request without further processing and SHOULD log the error
as a 
       security exception.

That might be wordier than necessary, but I think I captured everyone's
concerns.
Any comments?

-Pete

Mizikovsky, Semyon B (Simon) wrote:
> Charles, Pete,
> 
> I tend to agree with your comment that in absence of the valid SA,
> the HA SHALL silently discard the RRQ. We could also discuss if the
> HA MAY send the unsigned 131 for record-keeping purposes. I have no
> strong opinion about this.   
> 
> Regarding the "default" or "alternative" SA at the HA - it still
> makes no sense to me. Sorry Ahmad and Charles. The valid SA is either
> available or not. If it is available (alive), it needs to be used to
> validate the MN-HA AE in the RRQ and generate the MN-HA AE in RRP. Of
> course this SA may be pre-configured or retrieved. In case it is
> pre-configured, it MUST exist in the MN as well, and there would be
> no case of it existing only in MN or only in HA. Therefore all
> invalid RRQs SHALL be rejected with the 131 signed by the valid SA.
> In case it is retrieved, it could be fresher in the MN than in the
> HA, in which case the SPI will indicate this. Again, if HA can
> retrieve the fresh SA - it SHALL use it to validate the RRQ sign the
> RRP. If it can not retrieve it - it SHALL sign the RRP with its
> current living SA.            
> 
> Pete, regarding my comment for purging the old SA: it can be written
> as recommendation that in case when security associations change, the
> old SA needs to be retained by the peer until there is a positive
> confirmation that the new SA is used by the other peer, or until its
> lifetime expires.    
> 
> 
> Semyon Mizikovsky
> Alcatel Lucent
> What if we suppose that the "default" (better, the "alternative") SA
> is only suggested as a solution in cases where the operational
> difficulties cited by you do not pertain?  
> 
>> INDIVIDUALLY for each Mobile Node, than the HA may not be able to
>> get it from the AAA, the same way it may not be able to get an
>> actual real active SA. So defining the default MN-HA and SPI makes
>> no sense.      
>> 
> Can't we have security that is secure, and to write the specification
> to maintain the secure security?  I have a hard time believing that
> it is infeasible to install a particular security association in a
> secure way.   
> 
>> and MN-HA-SPI(1). The SPI(2) received by the HA in the RRQ will
>> cause the HA to access the AAA querying for the MN-HA(2) associated
>> with SPI(2). If this link is unavailable, or AAA responds with
>> Access Reject, the HA SHALL use the MN-HA(1) and MN-HA-SPI(1) to
>> sign the RRP "Reject". The Mobile SHALL retain the MN-HA(1) and
>> MN-HA-SPI(1) until either their lifetime expiration or until it
>> receives an RRP signed with the updated MN-HA(2), whichever comes
>> first. At this time the MN-HA(1) and associated SPI(1) are purged.  
>> 
> 
> As best I can tell, this isn't able to be specified without reference
> to AAA, and I don't think the upcoming revision of the document
> should introduce mechanisms related to AAA protocol actions. 
> Wouldn't this be done better as a separate Internet Draft?  If you
> like, I could help write it up for additional comment outside the
> context of rfc3344bis.     
>

---

From: "Mizikovsky, Semyon B (Simon)" <[email-masked]>
Date: Fri, 15 Jan 2010 14:19:49 -0600

Pete, I agree with this wording. We might need to cover one more case:
"...If the home agent sends a Registration Reply, it MUST contain a valid Mobile-Home Authentication Extension..."

There might be a case when there is no valid Mobile-Home security association. For instance, the last valid MN-HA lifetime expired, and died out and purged, while the new one indicated by the MN can not be retrieved. In such case, HA MUST silently discard the request.

Semyon Mizikovsky
Alcatel Lucent

-----Original Message-----
From: McCann Peter-A001034 [mailto:[email-masked]]
Sent: Friday, January 15, 2010 1:21 PM
To: Mizikovsky, Semyon B (Simon); Charles E. Perkins
Cc: [email-masked]; Ahmad Muhanna
Subject: RE: [Mip4] Authentication Mandate for AllRegistration Reply Messages

       *  Otherwise, if there is no Foreign-Home security association, the
          home agent MAY send a Registration Reply with Code 131.

       If the home agent sends a Registration Reply, it MUST contain a valid Mobile-Home
       Authentication Extension.  Note that in the case of an invalid Authenticator
       in a Registration Request, it is very likely that either the mobile node's
       or the home agent's security association database is out of date.
In
       constructing the Reply, the home agent SHOULD choose a security association
       that is likely to exist in the mobile node; for example, this may be an
       older security association or one with a longer lifetime than the one that
       was attempted to be used by the mobile node in its Request.
Deployments
       should take care when updating security associations to ensure that there
       is at least one common security association shared between the mobile node
       and home agent.

       In any case of a failed Authenticator, the home agent MUST then discard
       the Request without further processing and SHOULD log the error as a
       security exception.

That might be wordier than necessary, but I think I captured everyone's concerns.
Any comments?

-Pete

Mizikovsky, Semyon B (Simon) wrote:
> Charles, Pete,
>
> I tend to agree with your comment that in absence of the valid SA, the
> HA SHALL silently discard the RRQ. We could also discuss if the HA MAY
> send the unsigned 131 for record-keeping purposes. I have no
> Regarding the "default" or "alternative" SA at the HA - it still makes
> no sense to me. Sorry Ahmad and Charles. The valid SA is either
> pre-configured, it MUST exist in the MN as well, and there would be no
> case of it existing only in MN or only in HA. Therefore all invalid
> RRQs SHALL be rejected with the 131 signed by the valid SA.
> In case it is retrieved, it could be fresher in the MN than in the HA,
> in which case the SPI will indicate this. Again, if HA can retrieve
> the fresh SA - it SHALL use it to validate the RRQ sign the RRP. If it
> can not retrieve it - it SHALL sign the RRP with its
> current living SA.
>
> For another thing, there are systems where the HA is nearly guaranteed
> to have access to AAA.  For such systems, likewise it should be quite
> possible to expect to get access to the alternative
> SA.
>
>
> to maintain the secure security?  I have a hard time believing that it
> is infeasible to install a particular security association in a
> secure way.
>
>> RRP "Reject". The Mobile SHALL retain the MN-HA(1) and
> to AAA, and I don't think the upcoming revision of the document should
> introduce mechanisms related to AAA protocol actions.

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 15 Jan 2010 15:25:53 -0500

Hi, Simon,

I think your point is covered by the existing text in the second
paragraph of option (a):

       If the home agent receives a Registration Request from a Mobile
       Node with which it does not have any security association, the
       home agent MUST silently discard the Registration Request.

So, hopefully we don't need to repeat this.

-Pete

Mizikovsky, Semyon B (Simon) wrote:
> "...If the home agent sends a Registration Reply, it MUST contain a
> valid Mobile-Home Authentication Extension..." 
> 
> There might be a case when there is no valid Mobile-Home security
> association. For instance, the last valid MN-HA lifetime expired, and
> died out and purged, while the new one indicated by the MN can not be
> retrieved. In such case, HA MUST silently discard the request.   
> 
> Semyon Mizikovsky
> Alcatel Lucent
>        *  If there is a valid Foreign-Home authentication extension,
>           the home agent MUST send a Registration Reply with Code 131.
> 
>        *  If there is a valid Foreign-Home authentication extension,
>           the home agent MUST send a Registration Reply with Code 131.
> 
>        *  Otherwise, if there is no Foreign-Home security
>           association, the home agent MAY send a Registration Reply
> with Code 131. 
> 
>        If the home agent sends a Registration Reply, it MUST contain
>        a valid Mobile-Home Authentication Extension.  Note that in
>        the case of an invalid Authenticator in a Registration
>        Request, it is very likely that either the mobile node's or
> the home agent's security association database is out of date. 
> In
>        constructing the Reply, the home agent SHOULD choose a
>        security association that is likely to exist in the mobile
>        node; for example, this may be an older security association
>        or one with a longer lifetime than the one that was attempted
> to be used by the mobile node in its Request. 
> Deployments
>        that there is at least one common security association shared
>        between the mobile node and home agent.
> 
>        In any case of a failed Authenticator, the home agent MUST
>        then discard the Request without further processing and SHOULD
>        log the error as a security exception.
> 
>

---

From: "Mizikovsky, Semyon B (Simon)" <[email-masked]>
Date: Fri, 15 Jan 2010 14:32:44 -0600

Yes, this covers it.

Thanks much, Pete.

Semyon Mizikovsky
Alcatel Lucent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of McCann Peter-A001034
Sent: Friday, January 15, 2010 3:26 PM
To: Mizikovsky, Semyon B (Simon); Charles E. Perkins
Cc: [email-masked]; Ahmad Muhanna
Subject: Re: [Mip4] Authentication Mandate for AllRegistration Reply Messages

Hi, Simon,

I think your point is covered by the existing text in the second paragraph of option (a):

-Pete

Mizikovsky, Semyon B (Simon) wrote:
>        Request, it is very likely that either the mobile node's or the
> home agent's security association database is out of date.
> In