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

From: Ahmad Muhanna <[email-masked]>
Date: Fri, 15 Jan 2010 17:31:37 -0500

Hi, Pete,

It looks good. However, since you indicated that the text may be wordier :), can we optimize it by dropping the following sentence from the last paragraph...

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

I believe your proposed text without the above sentence will be just fine without loosing any of the intended meaning.

"
   If the home agent sends a Registration Reply, it MUST contain a valid
   Mobile-Home Authentication Extension.  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.
"

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

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
> 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: 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.
>
>
> On 1/13/2010 9:47 AM, 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.
>>
>
> 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.
>
>> 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.
>>
>
> 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: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 19 Jan 2010 18:22:07 -0500

Sounds reasonable.

Any other comments?  Should we go with this?

-Pete

Ahmad Muhanna wrote:
> Hi, Pete,
> 
> It looks good. However, since you indicated that the text may be
> wordier :), can we optimize it by dropping the following sentence
> from the last paragraph...  
> 
> "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."  
> 
> I believe your proposed text without the above sentence will be just
> fine without loosing any of the intended meaning. 
> 
> "
>    valid Mobile-Home Authentication Extension.  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
>    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.
> 
>        *  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.
> 
> 
> That might be wordier than necessary, but I think I captured
> everyone's concerns. 
> Any comments?
> 
> -Pete
> 
> 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 20 Jan 2010 11:12:58 -0800

Hello folks,

This proposal looks good to me.  I can revise the document
accordingly and submit the new revision in the next couple
of days, if there is no other objection.

Do we need any more text that recommends that a mobile
node, after receiving an invalid Registration Reply (e.g., bad
or zero authenticator), should simply wait for a good one
to arrive instead of trying immediately to re-establish its
security association?

Regards,
Charlie P.

On 1/19/2010 3:22 PM, McCann Peter-A001034 wrote:
>>> Wireless Security&  Fraud Prevention

---

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

Pete, the remaining text looks good to me.

Semyon Mizikovsky
Alcatel Lucent

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

Hello folks,

This proposal looks good to me.  I can revise the document accordingly and submit the new revision in the next couple of days, if there is no other objection.

Do we need any more text that recommends that a mobile node, after receiving an invalid Registration Reply (e.g., bad or zero authenticator), should simply wait for a good one to arrive instead of trying immediately to re-establish its security association?

Regards,
Charlie P.

On 1/19/2010 3:22 PM, McCann Peter-A001034 wrote:
>>> 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.
>>> 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
>>> 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
>>>
>>> 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(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
>>> 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.

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 20 Jan 2010 14:39:01 -0500

I think the text in 3.6.2.1 (b) covers this case:

>   b.  If the Code field indicates that service is denied by the home
>       agent, or if the Code field indicates that the registration was
>       accepted by the home agent, exactly one Mobile-Home
>       Authentication Extension MUST be present in the Registration
>       Reply, and the mobile node MUST check the Authenticator value in
>       the Extension.  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.

It's not clear to me that we need to say anything about events
that might trigger a re-establishment of a security association.

-Pete

Charles E. Perkins wrote:
> accordingly and submit the new revision in the next couple of days,
> if there is no other objection.  
> 
> Do we need any more text that recommends that a mobile node, after
> receiving an invalid Registration Reply (e.g., bad or zero
> authenticator), should simply wait for a good one to arrive instead
> of trying immediately to re-establish its security association?   
> 
> Regards,
> Charlie P.
> 
> 
>>>     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. 
>>> 
>>>     discard the Request without further processing and SHOULD log
>>>     the error as a security exception.
>>> "
>>> 
>>> Regards,
>>> Ahmad
>>>         *  If there is a valid Foreign-Home authentication
>>>            extension, the home agent MUST send a Registration Reply
>>> with Code 131. 
>>> 
>>>            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. 
>>> 
>>>         *  If there is a valid Foreign-Home authentication
>>>            extension, the home agent MUST send a Registration Reply
>>> with Code 131. 
>>> 
>>>            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 
>>>         or one with a longer lifetime than the one that was
>>>         should take care when updating security associations to
>>>         ensure that there is at least one common security
>>>         then discard the Request without further processing and
>>>         SHOULD log the error as a security exception.
>>> 
>>> 
>>> everyone's concerns. Any comments?
>>> 
>>> -Pete
>>> 
>>> 
>>> 
>>>> 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 
>>>> 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
>>>> 
>>>>> 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
>>>>> 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. 
>>>>> 
>>>>> 
>>>>> 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. 
>>>>> 
>>>>>

---

From: "Mizikovsky, Semyon B (Simon)" <[email-masked]>
Date: Wed, 20 Jan 2010 14:03:01 -0600

Agree with Pete. The trick of waiting for a good RRP is implementation specific.

Semyon Mizikovsky
Alcatel Lucent

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

security
>       exception.

It's not clear to me that we need to say anything about events that might trigger a re-establishment of a security association.

-Pete

Charles E. Perkins wrote:
> Hello folks,
>
> This proposal looks good to me.  I can revise the document accordingly
> and submit the new revision in the next couple of days, if there is no
> other objection.
>
>>>            MUST then discard the Request and SHOULD log the error as
>>> a security exception.
>>>
>>> mobile node's or the home agent's security association database is
>>> out of date.
>>> In
>>>> 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
>>>>> 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.
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>