Subject: [Mip4] Re: [secdir] SecDir review of draft-ietf-mip4-reg-tunnel-03

From: Pete McCann <[email-masked]>
Date: Thu, 21 Sep 2006 10:56:56 -0500

Hi, Vidya,

[note I copy the MIP4 mailing list on this response; I'd like to make
the list aware of the discussion to get broader review]

Narayanan, Vidya wrote:
> Hi Pete, all,
> 
> <snip> 
> 
>> I do think the MN-GFA authentication extension protects 
>> against packet redirection, no?  If there were a mobile that 
>> could spoof a regional registration, it could redirect the 
>> victim's packets.  Granted, the scope of the attack might be 
>> limited to the region, but this might still be a serious 
>> attack.  
> 
> Actually, regional registration seems to have an interesting twist in the redirection problem. 
 > The scope of the attack is not really limited to the region, since it 
will still be on the HoA
> of the MN, which is scoped to the HA's domain. For instance, the GFA accepts a regional
 > registration for an MN that has a valid home binding. An attacker, 
after observing a successful
 > RRQ/RRP exchange of an MN, may register that MN's HoA with its CoA to 
the GFA using regional
 > registration.

I would assume that the GFA could be configured to reject regional 
registrations from outside its region, whether they come through an FA
(where there would be a security association) or via co-located COAs
which are just outside the GFAs region.  An MN-GFA authentication 
extension (properly bound to the HoA, as you indicate below) could
be enough to protect against this attack.

> In the case of home registrations, the MSA between the MN and HA is "bound" to the HoA,
 > either by administrative means or because the HA assigned that HoA to 
the MN. In the case
 > of regional registrations, the GFA cannot be assumed to have any 
knowledge of the validity
> of the HoA. Strictly speaking, the GFA has no real reason to trust the HA either. So, it
 > is not sufficient to say that there is an SA between the MN and GFA - 
it must be explained
> how this gets "bound" to the HoA in order to successfully avoid redirection. I use the term
> "bound" loosely here - strictly, it implies cryptographic binding to some folks, but I am
 > only using as an identity binding thing here. One potential way in 
which this could work is
> as below: 
> 
> The MN-FA authentication extension MUST be supported for home registrations - in other words,
 > the MN must either establish or use an existing SA with the GFA at 
the time of home registration.
 > The GFA MUST make a note of the HoA and map it to the SA created upon 
receiving a successful
> RRP for that home registration. While I don't think the FA-HA authentication extension needs
 > to be mandated, when used, it will protect against the problem of 
lying and co-operating MN-HA
> pairs and MiTM attacks between the GFA and HA. 

If we really have a problem with co-operating MN-HA pairs then I think 
we would need to fix it.  However, requiring the MN-GFA authentication
extension, verified initially via AAA and bound to an NAI, seems to
prevent these kinds of redirection attacks.  Would you agree?

 > When the MN sends a regional registration request,
 > it MUST use the same SA used in the MN-FA authentication extension in 
the MN-HA authentication
 > extension of the regional RRQ. The GFA will then be able to verify 
that the MN is not claiming
> some other node's address as its HoA. 

The draft defines a new "MN-GFA Authentication Extension."  Isn't that 
the one we would use?  I think it is already called out as mandatory for
regional registrations.

> I think the above mechanism works :) Please also let me know if you see problems with it. 
> 
> In the event that the FA-HA authentication extension is not used for home registrations, if
 > an attacker put a rogue HA somewhere and registered an IP address on 
the HA's subnet as its
 > own HoA, the HA could pretend that it is a valid binding via a fake 
RRP and redirection can
> then occur - but, this is a convoluted attack with limited value - the attacker must be able
 > to put a fake HA that can interfere with the routing system 
successfully to route packets
> belonging to a victim to the GFA, so that such a redirection can occur and the attack is still
 > limited to nodes with IP addresses on the rogue HA's subnet. As long 
as an attacker is able
 > to actually place a rogue HA on a subnet, he already has access to 
the traffic coming to that
 > subnet - there is nothing further that the attacker would really 
achieve via regional
 > registration. This can be successfully thwarted if the GFA and HA 
used the FA-HA authentication
 > extension between each other. I would say that a SHOULD on the FA-HA 
authentication extension
> would be good to cover this. 

If every registration contains an MN-GFA authentication extension bound 
to the NAI of the MN, and if the NAI is included in each registration,
do we still have a problem?

> Based on the above, I think the following must be recommended for regional registrations: 
> 
> Home registrations:
> ===================
> 
> MN-HA authentication extension - MUST (as in RFC3344)
> MN-FA authentication extension - MUST (deviation from RFC3344, but doesn't impact HAs)
> FA-HA authentication extension - SHOULD (between GFA and HA)
> 
> Regional registrations: 
> =======================
> 
> MN-HA authentication extension - MUST use the same SA as the MN-FA MSA used for home registrations
 >                                  (i.e., between MN and GFA)

I think this is called an MN-GFA security association in the draft, right?

> MN-FA authentication extension - MAY 
> FA-HA authentication extension - MAY
> 
> 
>> Anyway, I think we both agree that the MN-GFA 
>> authentication extension is needed.
>>
> 
> Yes, but I think clarifications are needed along the lines I have explained above. The
> behavior of the GFA in handling the MN-FA and MN-HA authentication extensions in the home
 > and regional registration cases must be clearly specified.
> 
>>>> I think it is important to go through the document with an 
>> analysis 
>>>> along these lines to clean
>>  >> up the language on authentication extensions.
>>
>> If you could provide some specific pointers to where you 
>> think the language is vague, it would be extremely helpful to 
>> Eva as she produces the next rev.
>>
> 
> I hope the above pointers can be used to clarify the text in appropriate places in the
> document. If something is still unclear, please let me know. 

Thanks for the discussion - it has been illuminating.  Eva, do you have 
enough information to produce a revised draft?

-Pete

>>>> Also, there are some other inconsistencies in the document 
>> as well - 
>>>> for e.g., section 5.1
>>  >> states that the HFA extension MUST be placed before the 
>> MN-HA authentication extension if  >> the MN has no 
>> established MSA with the GFA - I am guessing this means that 
>> the protection  >> for that extension is using the MN-HA MSA. 
>> There is no documented HA behavior for this -  >> given that 
>> the HFA extension is skippable, does the HA skip this one, 
>> but include it for  >> authentication purposes?
>>
>> The authentication is always over the entire message, 
>> including unknown extensions.
>>
>>  >> Also, why is it okay for the GFA to sometimes verify this 
>> and the  >> HA to verify this some other times? What threat 
>> are you protecting against and how are the  >> two equivalent?
>>
>> I think in a realistic deployment scenario there would be 
>> some kind of integration between this draft and RFC 3012, so 
>> there would be a challenge-response and an MN-AAA 
>> authentication extension that could be verified by the GFA.  
>> Absent that, the GFA seems to be depending on the HA for 
>> verification of the extension.  I think the main threat to 
>> guard against here is again packet redirection of a victim's 
>> traffic to the given HFA care-of address.  If there is no SA 
>> between the GFA and the HA, then the protocol would be open 
>> to attacks from collaborating MN, HA
>> pairs: a home registration could be performed that fools the 
>> GFA into redirecting packets for a given MN.  I think a case 
>> could be made to always require e.g., MN-AAA authentication 
>> extension to cover the HFA extension in this case or at least 
>> require that a security association be developed during the 
>> home registration.  Development of the security association 
>> would involve verifying the whole registration request at the GFA.
>>
> 
> I think the HFA extension needs more clarity. Section 5.1 seems to indicate that the
 > extension may be sent to the HA, in which case, the HA behavior 
should be specified.
> OTOH, section 9.2 says the following about this extension - "When the receiving FA
 > receives the registration message, it MUST remove the the HFA 
extension added by the
 > sending FA" indicating that the HA must never see this extension. So, 
this seems
 > inconsistent and confusing to me.
> 
> Thanks,
> Vidya
> 
> 
>> -Pete
>>
>>>> Hope that helps in taking an approach for analyzing the 
>> applicability of the various MSAs
>>  >> to the protocol.
>>>> Regards,
>>>> Vidya
>>>>
>>>>  
>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] 
>>>>> On Behalf Of Pete McCann
>>>>> Sent: Wednesday, September 06, 2006 10:44 AM
>>>>> To: Eva Fogelström
>>>>> Cc: [email-masked]; [email-masked]; [email-masked]; 
>>>>> [email-masked]; [email-masked]; 
>>>>> [email-masked]
>>>>> Subject: Re: [secdir] SecDir review of 
>> draft-ietf-mip4-reg-tunnel-03
>>>>> Eva, Pasi, all,
>>>>>
>>>>> One of the final changes we did to this draft before 
>>>>> submitting was to remove a lot of the text describing dynamic 
>>>>> key exchange, because it wasn't clear whether the existing 
>>>>> mechanisms (RFC 3957 et cetera) could do the job of 
>>>>> distributing all of the necessary key material.
>>>>> Rather than go through the exercise of figuring this out, and 
>>>>> because the intention was to submit this draft as 
>>>>> Experimental, we decided it was good enough to assume that 
>>>>> all the Mobility Security Associations might be pre-configured.
>>>>>
>>>>> I re-read the draft this morning, and have a few 
>> additional points:
>>>>> * On the specific SHOULD that Pasi notes below, I think 
>> it would be
>>>>>   ok to change this to a MUST because we can assume 
>>>>> pre-configured SAs
>>>>>   in the visited domain between FAs and GFAs.
>>>>>
>>>>> * On page 17, section 6.1: there is text here (the final 
>> paragraph of
>>>>>   Section 6.1) that describes putting a challenge 
>> response into the
>>>>>   Identification field.  I think this is wrong, because RFC 
>>>>> 3012 doesn't
>>>>>   work that way: the challenge is appended as a separate 
>>>>> extension and
>>>>>   the MN-AAA authentication extension is used to authenticate it.
>>>>>
>>>>> * On page 24, section 9.3: the replay protection style is just one
>>>>>   aspect of a Mobility Security Association that is 
>> assumed to exist
>>>>>   between the MN and GFA.  While the Initial Identification field
>>>>>   is needed to establish the synchronization of the MSA, it isn't
>>>>>   clear to me that the Replay Protection Style value needs to be
>>>>>   transmitted at this point because it should already be a part
>>>>>   of the pre-established MSA.
>>>>>
>>>>> -Pete
>>>>>
>>>>>
>>>>> Eva Fogelström wrote:
>>>>>    
>>>>>
>>>>>> Hi Pasi,
>>>>>>
>>>>>> Thanks for reviewing the document.
>>>>>>
>>>>>> Two comments. Regional registrations build on the 
>> assumption that 
>>>>>> certain security associations are established during home 
>>>>>>      
>>>>>>
>>>>> registration.
>>>>>    
>>>>>
>>>>>> How these security associations are established is not 
>> specified in 
>>>>>> this draft, but in other RFCs. I could clarify the text in 
>>>>>>      
>>>>>>
>>>>> this draft, 
>>>>>    
>>>>>
>>>>>> so that it is easier to understand exactly what the 
>>>>>>      
>>>>>>
>>>>> assumptions are, 
>>>>>    
>>>>>
>>>>>> and what the different solutions are.
>>>>>>
>>>>>> Also, as you mention, there are a couple of places in the 
>>>>>>      
>>>>>>
>>>>> draft saying 
>>>>>    
>>>>>
>>>>>> "SHOULD be protected". In the Mobile IPv4 protocol, some 
>>>>>> authentication extensions are optional, and I would assume 
>>>>>>      
>>>>>>
>>>>> that's why 
>>>>>    
>>>>>
>>>>>> they are also optional for regional registrations. I 
>>>>>>      
>>>>>>
>>>>> personally think 
>>>>>    
>>>>>
>>>>>> some of these could be changed from SHOULD to MUST, so I 
>> could go 
>>>>>> through the draft and tighten up the requirements on 
>>>>>>      
>>>>>>
>>>>> authentication extensions.
>>>>>    
>>>>>
>>>>>> Do you want me to go ahead and do these changes?
>>>>>> Eva
>>>>>>
>>>>>> [email-masked] wrote:
>>>>>>
>>>>>>      
>>>>>>
>>>>>>> I have reviewed this document as part of the security 
>>>>>>>        
>>>>>>>
>>>>> directorate's 
>>>>>    
>>>>>
>>>>>>> ongoing effort to review all IETF documents being 
>> processed by the 
>>>>>>> IESG.  These comments were written primarily for the 
>> security area 
>>>>>>> directors, but are copied to the document's editors and 
>>>>>>>        
>>>>>>>
>>>>> the WG chairs 
>>>>>    
>>>>>
>>>>>>> for their information and to allow them to address any 
>>>>>>>        
>>>>>>>
>>>>> issues raised.
>>>>>    
>>>>>
>>>>>>> Summary for security ADs: Someone who knows MIP4 better 
>>>>>>>        
>>>>>>>
>>>>> needs to take 
>>>>>    
>>>>>
>>>>>>> a careful look at this.
>>>>>>>
>>>>>>> Longer version:
>>>>>>>
>>>>>>> First, I must admit that I am not an expert on the current MIP4 
>>>>>>> security mechanisms. Thus, the comments may be partly due to 
>>>>>>> incomplete understanding of how this document is 
>> supposed to fit 
>>>>>>> together with the existing mechanisms.
>>>>>>>
>>>>>>> However, sentences such as "it is assumed that a 
>> mobility security 
>>>>>>> association is established between the MN and GFA during 
>>>>>>>        
>>>>>>>
>>>>> registration 
>>>>>    
>>>>>
>>>>>>> with the HA", and "Dynamic GFA assignment requires means 
>>>>>>>        
>>>>>>>
>>>>> for securely 
>>>>>    
>>>>>
>>>>>>> sending Registration Requests from the GFA to the HA", and 
>>>>>>>        
>>>>>>>
>>>>> "How the 
>>>>>    
>>>>>
>>>>>>> keys are distributed is outside the scope of this draft" 
>>>>>>>        
>>>>>>>
>>>>> do not give 
>>>>>    
>>>>>
>>>>>>> me a warm fuzzy feeling that everything is OK.
>>>>>>>
>>>>>>> I think someone who knows this area better should take a 
>>>>>>>        
>>>>>>>
>>>>> careful look 
>>>>>    
>>>>>
>>>>>>> at this to determine if the existing mechanisms (that are 
>>>>>>>        
>>>>>>>
>>>>> outside the 
>>>>>    
>>>>>
>>>>>>> scope of this draft) actually do what this draft expects 
>>>>>>>        
>>>>>>>
>>>>> of them, or 
>>>>>    
>>>>>
>>>>>>> whether there are gaps. For example, the draft assumes 
>>>>>>>        
>>>>>>>
>>>>> that a large 
>>>>>    
>>>>>
>>>>>>> number of different security associations between 
>>>>>>>        
>>>>>>>
>>>>> different entities 
>>>>>    
>>>>>
>>>>>>> somehow exist or are created; are all of these really 
>> there at the 
>>>>>>> right time when they're needed?
>>>>>>>
>>>>>>> At least there seems to be some confusion on the issue. 
>>>>>>>        
>>>>>>>
>>>>> For example, 
>>>>>    
>>>>>
>>>>>>> Section 5.2 says that when FA appends HFA extension to the 
>>>>>>>        
>>>>>>>
>>>>> end of the 
>>>>>    
>>>>>
>>>>>>> message, "it SHOULD be protected by a Foreign-Foreign (FA-FA) 
>>>>>>> Authentication extension", meaning it's not always 
>>>>>>>        
>>>>>>>
>>>>> protected? But is 
>>>>>    
>>>>>
>>>>>>> this because the security association is not there, or due 
>>>>>>>        
>>>>>>>
>>>>> to other 
>>>>>    
>>>>>
>>>>>>> reasons?
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Pasi
>>>>>>>
>>>>>>>
>>>>>>>        
>>>>>>>
>>>>> _______________________________________________
>>>>> secdir mailing list
>>>>> [email-masked]
>>>>> https://mailman.mit.edu/mailman/listinfo/secdir
>>>>>
>>>>>    
>>>>>
>>>>
>>>>  
>>>>
>>>
>>>
>>
> 

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 21 Sep 2006 22:55:55 -0700

Hi Pete, 

> From: Pete McCann [mailto:[email-masked]] 
> Sent: Thursday, September 21, 2006 8:57 AM
> To: Narayanan, Vidya
> Cc: Jari Arkko; Eva Fogelström; [email-masked]; [email-masked]
> Subject: Re: [secdir] SecDir review of draft-ietf-mip4-reg-tunnel-03
> 
> Hi, Vidya,
> 
> [note I copy the MIP4 mailing list on this response; I'd like 
> to make the list aware of the discussion to get broader review]
> 
> Narayanan, Vidya wrote:
> > Hi Pete, all,
> > 
> > <snip>
> > 
> >> I do think the MN-GFA authentication extension protects against 
> >> packet redirection, no?  If there were a mobile that could spoof a 
> >> regional registration, it could redirect the victim's packets.  
> >> Granted, the scope of the attack might be limited to the 
> region, but 
> >> this might still be a serious attack.
> > 
> > Actually, regional registration seems to have an 
> interesting twist in the redirection problem. 
>  > The scope of the attack is not really limited to the 
> region, since it will still be on the HoA
> > of the MN, which is scoped to the HA's domain. For 
> instance, the GFA 
> > accepts a regional
>  > registration for an MN that has a valid home binding. An 
> attacker, after observing a successful  > RRQ/RRP exchange of 
> an MN, may register that MN's HoA with its CoA to the GFA 
> using regional  > registration.
> 
> I would assume that the GFA could be configured to reject 
> regional registrations from outside its region, whether they 
> come through an FA (where there would be a security 
> association) or via co-located COAs which are just outside 
> the GFAs region.  

That itself is not the issue - the CoA can be within the region, but there is no way for the GFA to tell that the HoA doesn't belong to that MN. 

> An MN-GFA authentication extension 
> (properly bound to the HoA, as you indicate below) could be 
> enough to protect against this attack.
> 

Regardless of the check on CoAs, this is true. 

>  > either by administrative means or because the HA assigned 
> that HoA to the MN. In the case  > of regional registrations, 
> the GFA cannot be assumed to have any knowledge of the validity
> > of the HoA. Strictly speaking, the GFA has no real reason 
> to trust the 
> > HA either. So, it
>  > is not sufficient to say that there is an SA between the 
> MN and GFA - it must be explained
> > how this gets "bound" to the HoA in order to successfully avoid 
> > redirection. I use the term "bound" loosely here - strictly, it 
> > implies cryptographic binding to some folks, but I am
>  > only using as an identity binding thing here. One 
> potential way in which this could work is
> > as below: 
> > 
>  > the MN must either establish or use an existing SA with 
> the GFA at the time of home registration.
>  > The GFA MUST make a note of the HoA and map it to the SA 
> created upon receiving a successful
>  > to be mandated, when used, it will protect against the 
> problem of lying and co-operating MN-HA

Without mandating the FA-HA authentication extension on the home registration, we can't fix the co-operating MN-HA problem. But, the reason I felt a SHOULD on that would be okay is because of the rather complicated nature of the attack - if you dropped an HA on a network, you have access to packets coming there anyway. Redirection using MIP or regional registration doesn't seem like an additional attraction to the attacker in that scenario. 

> the one we would use?  I think it is already called out as 

My understanding was that the MN-GFA authentication extension is defined to protect the HFA extension in a home registration while using CCoA mode, not for protection of the regional registration itself. Did I misunderstand? Basically, the SA is between the MN and GFA - so, it doesn't really matter what it is called, although consistency is important to avoid confusion. 

> > belonging to a victim to the GFA, so that such a 
> redirection can occur and the attack is still

Without the FA-HA extension for home registration, you still have the issue of co-operating MN-HA pairs as I said above. 

> > MN-HA authentication extension - MUST use the same SA as 
> the MN-FA MSA used for home registrations

Same comment as above on my understanding of the MN-GFA SA. 

Thanks,
Vidya