RE: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ben,
Please see inline.

Regards,
Ahmad
> -----Original Message-----
> 
> >
> >>
> >> I still have concerns about the use of IPSec, though, as without 
> >> IPSec of some other form of authentication, an attacker could 
> >> conceivably impersonate the node that bindings were 
> associated with. 
> >> This is particularly bothersome in use cases that allow a node to 
> >> revoke bindings without having to know the details of each 
> individual 
> >> binding, such as the G-bit, or an included NAI of the form 
> >> "@example.com".
> >>
> >> I'm not saying that this draft needs to make IPSec into a MUST.
> > [Ahmad]
> > If it comes to me, I am comfortably fine with that:)
> >
> >> But it is appropriate for it to point out that if you 
> _don't_ use it, 
> >> bad things could happen. (See my comment on that point 
> further down.)
> >>
> >> It may be that using MIPv6 without IPSec is just as bad 
> without BRI 
> >> as with it--in which case it's fair to say that any 
> attacks enabled 
> >> by not using IPSec with BRI are no worse than using the base 
> >> technologies without BRI. (Such statements are easier to 
> believe with 
> >> some discussion to support them, though :-) )
> >
> > [Ahmad]
> > When IPsec is used, the only issue that we identified that needs 
> > special attention was the Global Revocation with Revocation Trigger 
> > value "Per-Peer Policy" when sent from the MAG [because it 
> deletes all 
> > sessions between the two peers]. Although, some people 
> still disagreed 
> > that there is no great risk in there and no special 
> treatment should 
> > take place. At any rate, since this message coming from a 
> peer in the 
> > visited network, we wanted the home network to have the 
> upper hand and 
> > be able to give specific privileges to peers in the 
> different visited 
> > networks, i.e., MAGs. What this means? the ability to establish an 
> > IPsec SA between the MAG and the LMA does not give the MAG the 
> > automatic privilege to use Global Revocation with 
> Revocation Trigger 
> > value of "per-Peer Policy". That why we required authorization.
> >
> 
> Again, I'm looking for discussion on what the impact of 
> choosing _not_ to use IPSec, since it is only required at a 
> SHOULD strength. I think the answer to the similar point below helps.
[Ahmad]
Ok. 

> 
> 
> >>
> >> More inline:
> >>
> >> On Aug 27, 2009, at 1:32 PM, Ahmad Muhanna wrote:
> >>
> >>> Hi, Ben,
> >>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>>
> >>>>>> Summary: This draft is on the right track, but there are
> >>>> open issues.
> >>>>>> Additionally, I have a number of editorial comments.
> >>>>>>
> >>>>>> Major issues:
> >>>>>>
> >>>>>> -- I think the security considerations need quite a bit of
> >>>> work. In
> >>>>>> particular, there is very little guidance on authorization for 
> >>>>>> sending BRI messages. This seem to me have utility for DoS
> >>>> attacks,
> >>>>>> particularly with the G bit set.
> >>>>>> There is mention of reusing existing security associations
> >>>> if IPSec
> >>>>>> is used--but no mention of what to do if IPSec is not used.
> >>>>> [Ahmad]
> >>>>> Binding Revocation is used between two peers to
> >> revoke/terminate a
> >>>>> mobility session(s) that have been created using an 
> IPv6 mobility 
> >>>>> protocol signaling (Client Mobile IPv6 or Proxy MIP6).
> >> RFC3775 and
> >>>>> RFC5213, which are the main protocols targeted by this
> >>>> specification,
> >>>>> specify that "IPsec SHOULD" be used. On the other hand,
> >> there is NO
> >>>>> other standard track specification which specify other security 
> >>>>> mechanisms to secure the IPv6 mobility signaling.
> >>>> Therefore, Binding
> >>>>> Revocation specification assumes the use of whatever security 
> >>>>> mechanism that currently available to secure the IPv6 mobility 
> >>>>> signaling.
> >>>>
> >>>> I think there are still a couple of issues here. First, 
> Since the 
> >>>> underlying RFCs only specify IPSec at SHOULD strength, 
> this draft 
> >>>> needs to discuss the consequences of not using it for BRI.
> >> Depending
> >>>> on those consequences, it might be enough to just warn
> >> implementors
> >>>> that, if you don't use IPSec, certain bad things can happen.
> >>> [Ahmad]
> >>> It is NOT expected that BRI/BRA will use a different security 
> >>> mechanism than what is being used for securing IPv6 mobility 
> >>> signaling.
> >>> Therefore,
> >>> in order to alert implementors of the danger if IPsec is 
> NOT used, 
> >>> IMO, that needs to be discussed in related IPv6 mobility 
> >>> specifications, e.g., RFC3775 and RFC5213, which is already
> >> there. On
> >>> the other hand, it is very difficult to anticipate the 
> criteria of 
> >>> other security mechanisms that would possibly be used in
> >> the future to
> >>> secure IPv6 mobility signaling and consequently BRI/BRA.
> >>>
> >>
> >> Sure--but it's appropriate for the BRI spec to say "If BRI is used 
> >> without IPSec, these bad things can happen in addition to the bad 
> >> things that might happen if you use the base technology without 
> >> IPSec." Or alternatively,
> >
> >> "The bad things
> >> that can happen with BRI without IPSec are functionally 
> identical to 
> >> those for the base technology, so the IPSec related security 
> >> considerations are identical to those in RFCXXXX/YYYY).
> > [Ahmad]
> > We can add something similar to this. Thx.
> 
> Okay, thanks!
> 
> 
> 
> >
> >
> >>
> >>
> >>>
> >>>> OTOH, it might be that BRI has
> >>>> greater security risks than for 3775/5213, and you might (for
> >>>> example) need to strengthen the IPSec requirement for BRI.
> >>>>
> >>>> I admit to not being an expert on 3375/5213, so it may be
> >> true that
> >>>> BRI is no riskier than the underlying technology--but even
> >> if that is
> >>>> true I'd like to see some discussion to support it.
> >>> [Ahmad]
> >>> Both IPv6 mobility signaling and BRI/BRA use the same IPv6 layer 
> >>> signaling. I am not sure what impact the underlying
> >> technology has on
> >>> BRI./BRA that does not have on BU/BA.
> >>
> >> If I use just BU/BA without IPSec, is there a way an 
> attacker could 
> >> delete bindings in bulk without having to know all the details for 
> >> each binding?
> >
> > [Ahmad]
> > Well, there is no mechanism with BU/BA to delete mobility 
> sessions in 
> > bulk as proposed in Binding Revocation; On the other hand, If BU/BA 
> > are used without IPsec, Operators will run out of money 
> quickly:) and 
> > they probably will use Global BRI/BRA (without security) to stop the
> > bleeding:)
> >
> 
> Heh :-)
> 
> So is it true that using bulk revocation without IPSec could make it  
> possible for an attacker to masquerade as an authorized party, and  
> delete large numbers of bindings with a single BRI? 
[Ahmad]
Well, we need to be a little careful here:) I think what you meant to
say here is without any security mechanism.
So, If no valid SA is being used to protect the binding revocation
signaling and, I assume, the MIP6/PMIP6 signaling, then a lot of bad
things could happen.


> Or there  
> underlying architectural features that prevent or make this hard? 
[Ahmad]
I am not quite sure what you mean by the underlying architectural
features in this context. But I can say the following: If no security
mechanism (SA) is being used, neither BU/BA nor BRI/BRA are allowed to
be used for establishing nor revoking mobility sessions. 
  
> think just discussing that in the SecCon would go a long way towards  
> addressing my concerns.)
[Ahmad]
I am in the process of rewriting the security section and the whole
draft to address all comments. Will revaluate before publishing whether
we need anything specific here.


Regards,
Ahmad

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]