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

Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt



Hi Sri,

Sri Gundavelli wrote:


On Mon, 16 Mar 2009, Vijay Devarapalli wrote:

Sri Gundavelli wrote:
> > >  Does the LMA keep a list of MAGs that are authorized for
> >  sending bulk revocations? How is this list configured? In
> >  addition, I think this authorization step is unnecessary and
> >  should be removed.
>

 Bulk revoc is a high security risk operation, requiring such
 authorization check will allow the system to build some
 configurability into the system.

 Even for a single binding, if you recall and as Ahmad pointed
 out, we do require this in 5213. We added this per IESG note.

This authorization check was added in a very early version of the PMIPv6 draft in response to a review from Lakshminath. Not due to the IESG. One of the options suggested was to have the LMA check if the MN is really attached to the MAG before allowing the MAG to create a binding for the mobile node. But this has nothing to do with the authorization check for bulk revocation.


No. That's not true. I've added this during the AD review. We may
have discussed this earlier, but this specific authorzation check
was added per the AD review. We may have discussed this very
early and I remember that discussion as well.

http://www.ietf.org/mail-archive/web/netlmm/current/msg04144.html

This is incorrect. draft-ietf-netlmm-proxymip6-00 that was submitted in April 2007 had the following

   However, the local mobility anchor MUST allow only authorized mobile
   access gateways to create binding cache entries on behalf of the
   mobile nodes.  The actual mechanism by which the local mobility
   anchor verifies if a specific mobile access gateway is authorized to
   send Proxy Binding Updates on behalf of a mobile node is outside the
   scope of this document.  One possible way this could be achieved is
   sending a query to the policy store such as by using AAA
   infrastrucure.

See http://tools.ietf.org/html/draft-ietf-netlmm-proxymip6-00

AD review happened in Jan 2008.

 Before the MAG can create a binding, the LMA is required to check
 if the given MAG is authorized to perform such an operation. The
 same goes for dereg, its enforced indirectly, there is a check
 for binding's Proxy-CoA to match the PBU's Proxy-CoA, before the
 dereg is allowed.

When the MAG de-registers a mobile node's session, there is no authorization check. The LMA only makes sure that it the same MAG that is responsible for the binding.

No, there is a indirect check. The MAG before deregistering,
will match the Proxy-CoA in the request to that present in
the binding. Prior to that BCE creation, the LMA allowed only
a authorized MAG to create that binding. So, this check at dereg
will indirectly enforce the same.

This is NOT an indirect authorization check. As I have said in this thread many times, the MAG that created the binding is allowed to delete the binding. Simple. There is no authorization check when deleting the binding.

Sorry, I am not convinced that this authorization check is needed for bulk revocation from the MAG.

Vijay


 Now, this check for bulk dereg spanning many MN's is for the
 specific operation, if its allowed or not. This is a requirement
 for a good system design, from OM perspective. Has no bearing
 on protocol interop. I dont think this can be an issue, one
 can always add a * rule to permit every MAG to perform such
 operation.

This does not make sense. If we are going to create a rule allowing all MAGs to perform bulk revocation, then why do we need the authorization check?

Building the rule into the system is for defining an authorization model,
relaxing that rule in a given system deployment is a SDO/deployment
choice. That's the operator's choice based on the security considerations
in their operating environment.


 If your concern is maintaing that list, we can always state in
 a secure network, the MAG can just have one flat rule to allow
 such operation from all the configured peers that it knows.
 Will that work ?

You mean the LMA, right? The LMA is the one that does this check.


Yes, typo

Your email does not address my question on how this list is created at the LMA. Why is one MAG special and allowed to do bulk revocation while another MAG is not allowed? The MAGs are all part of the same PMIPv6 domain.


There is not much to address. We require the LMA to maintain a list
of MAG's authorized to perform certain functions. We need a very similar
list, or add an attribute to the above maintained list, with finer
access control as who can perform bulk dereg operations.


Sri



Vijay