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]

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

Hi Ahmad,
Let me comment on the security issues at a high level up front, since I think I can tie together responses to several of your comments below. More specific comments imbedded:
I think the email from Jari helped clarify things for me to a point that I can make my concerns a little more precise. You clarify further down that mobile nodes are _never_ allowed to revoke bindings that weren't associated with them in the first place. This actually addresses a lot of my concerns, and I think it is fundamental enough to be reiterated in the SecCons section.
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. 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 :-) ) 

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





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? 





Second, I think that there is probably more guidance needed
on authorization decisions even if you do use IPSec. For
example, do you assume that any trusted peer can remove any
binding?

[Ahmad]
No. The revoking mobility entity revokes only those mobility session(s) 
which are registered with it. No mobility node can revoke a mobility
session that is registered with a different trusted mobility node.



Is a trusted peer only allowed to remove bindings
that it previously established using the same SA?

[Ahmad]
I believe I addressed this via another comment earlier. The answer is
NO.


If an SA is
torn down and a new one established, what authorization gets
inherited, if any?

[Ahmad]
When the SA is torn down and a new one is established, the new SA is
valid for both BU/BA and BRI/BRA. In other words, the new SA will still 
have the same SPD which allows the BU/BA and BRI/BRA messages, etc. If
your question is about authorization of Global revocation, that
authorization should be done separately.
So it may seem obvious to you, but it's worth mentioning that the node needs to make sure the new SA is with the same node as the old SA. 




Do you assume that a peer that is trusted
to establish bindings is trusted for BRI?

[Ahmad]
Of course. The node which initiated or granted the registration should
have the authority to revoke it.
Do you see any problem there?




No, if you can be sure the node is really the node you think it is.



Do you need to
provision policies around these, and if so what are the moving parts?


[Ahmad]
The text under the security section was supposed to capture this. The
SPD should be updated to allow MH type of 'Binding Revocation message'. 
If it is not enough, let us know what is missing and we can add/modify
as needed.
Given the "you can only delete your own bindings" constraint, this is probably okay. 









(Perhaps it is required by the underlying technology?
If so, that should be mentioned here.)

[Ahmad]
That is not the intention. Please see above.


You mention that
authorization is required if the G-bit is set, but go on to say
authorization details are out of scope. I think that this

draft needs

to either offer much more guidance on authentication requirements.

[Ahmad]
We could introduce a simple default mechanism inline with

what we have

in RFC5213.


It's possible that might help--can you point to the section
of 5213 you have in mind?


[Ahmad]
Section 4, paragraph 6.
I think that would help, although it's still worth mentioning that for that sort of authorization to be meaningful, you have to have some degree of authentication (IPSec or otherwise). 



It might also be enough to have
more discussion on what an implementor needs to think about
to do authorization correctly. For example, does it make
sense to statically provision that a trusted peer can remove
any binding for "foo.com"?

[Ahmad]
Sure, static configuration what RFC5213 has under section 4. However, in 
our case, is the peer authorized to use Global Revocation or not. This
is not restricted to a certain realm but the restriction as mentioned
above to sessions that is hosted at the revoking mobility node.



Is authorization policy
dynamically determined by prior actions (i.e. a peer can
revoke all bindings _it_ established for "foo.com", but not
bindings that another device established for "foo.com"?

[Ahmad]
That is the very fundamental requirement for this protocol.
Okay, that helps. It's fundemental enough it might be worth reiterating in the SecCons section. 




Probably more than anything, it would help to discuss the
sort bad things that this authorization is intended to prevent.


[Ahmad]
Ok. We can elaborate and add some text here. Thx.






It would be helpful if the
Security Considerations section discussed the consequences of
security failures, possible attacks, etc.


[Ahmad]
This specification do not introduce any security threats on

the top of

what is being discussed in Client MIP6 and Proxy MIP6, RFC3775 and
RFC5213.


That's a little hard to believe without some supporting text. Again,
this could be my lack of knowledge of IPv6 mobility talking. But for
example, do RFC3775 and/or 5213 already have something a
mechanism for
one mobility element to tell another to drop bindings in bulk?


[Ahmad]
Yes. For example, the client which has multiple Bindings (referenced by 
different Binding IDs) could send a single message (de-registration, a
BU with lifetime zero) and request the server (HA) to delete all
bindings which belong to this Mobile node.
Okay, that supports the idea that BRI considerations are similar those for the base technologies. Does the ability for an HA to delete bindings at a MN change things? 

[...]




In addition,
section 10.2.1. which talks about the use of the (G) bit by

the MAG

and
indicates that whenever the (G) bit is set the (A) bit MUST

be set, is

correctly being referenced in this section and mentioned

before the

text
quoted above.


But this text talks about how you form a BRA, not how the initiator
formed the BRI. Would you expect a responder to just assume (without
checking) that the A bit was set if it sees a G-bit set?

There's a lot of interaction between these bit settings that
make for
some pretty complicated state transitions. As described, it expects
the responder to infer the A bit value based on the G-bit value. It
would be much cleaner to to implement if it were defined so that the
responder always sends a BRA if the A bit is set, and never if it is
not.

As a thought experiment, how would you recommend an implementer to
handle the case where a responder got BRI with the G bit set
and the A
bit not set? (I'm not asking for the draft to specify
that--it's just
a discussion point.)


[Ahmad]
Ok. I guess to close on this issue, It is fair to require that the
responder send BRA only when the (A) bit is set. Because, also, if the
initiator did not set the (A) bit, it may very well not expecting a BRA 
and possibly NOT saving the BRI as an outstanding one to start with.
Thanks; will make sure that is addressed as a global comment and will
make sure that all places are fixed.



Thanks, I think this helps.






-S4, paragraph 2: "verify that the mobile access gateway
sending the binding revocation indication message is
authorized to invoke global revocation"

How does it make such a verification?

[Ahmad]
By checking the identity of the MAG if it is authorized for global
revocation or not. Would a reference to section 9.2.1. makes it
clearer
or you think we need to add more clarification.


Actually, this is really more of a 9.2.1 issue. (I reviewed things
linearly.) I think a reference here would help, but note I
had similar
comments about 9.2.1 further down.

[Ahmad]
This should be addressed as part of the authorization clarification.



Okay
-- Section 7.2, last paragraph: "If a mobility node receives a Binding Revocation Indication message with a Revocation 
Trigger value that is NOT in line with the Binding Revocation
Indication message intent, e.g., the Global (G) bit set and
the Revocation Trigger field vale is a per-MN specific, the
receiving mobility node SHOULD reject the Binding Revocation
Indication message by sending a Binding Revocation
Acknowledgement message with the Status field set to
"Revocation Function NOT Supported"."

This paragraph seems to imply some under-specification around
how to tell the Revocation Trigger value is not in line with
the initiator's intent.

Also, do you really mean to send "... not supported"? This
really sounds like more of a "bad request" scenario.

Did you mean to capitalize the final "NOT"?

[Ahmad]
I thought it was a straight forward combination. If the

Global (G) bit

is set, the Revocation trigger field value MUST contain one of the
Global revocation triggers. If the (G) bit is cleared, the

revocation

trigger MUST contain a per-MN value. Any deviation, means this
functionality is not supported.



The text indicated those as examples. Are they the only scenarios
where the trigger value can be out of line with the "intent"?

[Ahmad]
The valid combinations are:

Global Revocation==>>> (G) bit set and Revocation Trigger = a Global
revocation trigger.
Per-MN Revocation ==>> (G) bit cleared and Revocation Trigger = a per-MN 
revocation trigger.


Okay.





I guess
part of my problem is that "intent" is a vague term here. The
important thing is to make sure that all legal combinations are
specified. I think they may be later on (again, reviewing linearly),
but they are scattered around the draft.

[Ahmad]
The Global Revocation Triggers are defined under section 6.1.


Okay.





As far as why having "NOT" in capital letters, some drafts have the
whole cause value in capital letters, but it is also meant

to say that

this is a bad request.



-- Section 7.3:

RFC3775 already talks about retransmission for Binding Update
messages. Does this really need to be specified separately?


[Ahmad]
Yes. It is a separate protocol.


Okay.




-- 2nd paragraph: "SHOULD retransmit"

Can you offer guidance on when an implementation might
reasonably not do this? (i.e. why not a MUST?)

[Ahmad]
Since sending a BRI message is NOT a MUST to start with, I do not
believe that the retransmission needs to be mandated as a "MUST". A
strong recommendation using "SHOULD" gives more flexibility to the
initiator to retransmit based on the need and the scenario

at hand. In

addition, I did not see anywhere in RFC3775 or RFC5213 where
retransmission is mandated.


A MUST retransmit if you don't get the ack to a BRI does not in any
way imply MUST send a BRI.

[Ahmad]
A good point; but in RFC3775 and RFC5213 there is no MUST for
retransmission either.
For example under section 6.9.4 of RFC5213, it says:

"
  2.  If the mobile access gateway fails to receive a valid matching
response for a registration or re-registration message within the retransmission interval, it SHOULD retransmit the message until a 
      response is received.
"



In this case, my concern is that you have two ways to decide not to
send a retransmission--one is that the value of BRIMaxRetriesNumber
could be set sufficiently low (zero, I assume) to prevent
retransmissions. The second is that the implementator could
choose not
to honor the SHOULD, even if BRIMaxRetriesNumber has a higher value.
If you want to allow the latter, it would help to have some guidance
(or examples) about scenarios where this would make sense, and the
consequences of doing it.


[Ahmad]
I believe 'SHOULD" here is to offer the implementation more flexibility. 
A simple implementation could interpret 'SHOULD' as always retransmits
and moves on and still be compliant to the specification. Others may
build more complex logics which should not be prevented.
In general, SHOULDs should be used when there are specific reasons you think an implementation might not want to do something, not for open ended flexibility. SHOULDs without additional guidance are typically bad for interoperability.
In this case, I'm reasonably convinced that SHOULD is okay here, but I'd like to see some guidance around it. For example, does it make sense to have a note indicating that an implementation might choose not to retransmit if it either does not need reliable delivery, or if it has some other (preferably interoperable) reliability mechanism? (Although one wonders why an implementation would set the A-bit but not retransmit.)
I know that RFC3775/5213 may not do this--but I think it's reasonable to try to improve the way we (as the whole IETF) do things over time. 







-- Last para: "SHOULD NOT"

Why not MUST NOT?

[Ahmad]

The problem we are trying to avoid here is: if we use "MUST NOT"
then we
need to specify the behavior of the receiving node in case it
receives a
BRI with all of the BID(s) included. Considering such case

as an error

scenario is probably not the best way. Allowing it, then it is not
"MUST
NOT" anymore.


On the contrary, it's not necessary to describe what the
responder has
to do for every possible violation of MUST level requirements by the
initiator. But it _is_ necessary to do that for violations of SHOULD
level requirements, because that is much more likely to
happen. So by
making this a SHOULD you've created more work on the part of the
responder than if it were a MUST.

OTOH, if it really doesn't matter to the responder one way or
another,
then I'm not sure you need either.

BTW, It's not necessary for the responder to treat every MUST
violation by the sender as an error--Postel's law should
applies here.
I suspect the real requirement is that the _receiver_ MUST
ignore any
BIDs if present, right?


[Ahmad]
No.
In this case, the mobile node may have registered multiple bindings,
i.e., multiple care-of addresses for the same HoA. Each bindings is
assigned one Binding ID. Let us assume that the MN has BIDs(1, 2, 3, and 
4) just for the sake of this discussion.
The home agent may send a BRI with [BIDs (1,4)], this means ONLY BIDs (1 
& 4) are being revoked. 2 & 3 still active.
The home agent may send a BRI with [BIDs (1, 2, 3, & 4)] to revoke all
of these 4 Bindings (In this case ALL Bindings). Well, this is NOT
recommended, the HA could have sent a BRI with NO BID(s) and accomplish 
the same result.
Okay, I think I understand now--there are two ways to delete all bindings, and you are basically preferring one but not requiring it, right? 

[...]
-- S 11.1, bullet 2: "SHOULD send a Binding Revocation Acknowledgement" 

Can you document reasons why a responder might not send the
BRA, and the consequences thereof? In particular, are there
scenarios where the initiator might go into retries because
the responder chose not to send a BRA?

[Ahmad]
Sure.
In this bullet it says that if the mobile node receives a

BRI message

and the MN has an entry for the binding defined in the received BRI,
then the MN MUST send a BRA. In other words, if the MN successfully
process the BRI and still track this binding and still able

to send a

BRA, then it MUST send a BRA. In all other circumstances,

e.g., the MN

no longer tracking this binding, the MN received the BRI and before
processing the battery went down and no BRA is sent anyway, etc. The
whole idea is to make sure that the mandate on the mobile node is
reasonable and within the mobile node abilities to send a BRA.
Otherwise, we would like to offer the mobile node a

reasonable excuse.

I don't think one needs to worry about scenarios such as "battery
failed" in deciding to make a requirement a MUST or a SHOULD. If we
did, it would not be possible to have _any_ MUSTs.

In this particular case, not sending the BRA appears to do harm, in
that it may induce unnecessary retransmissions on the sender's part.


(You did not follow up on this one)

[...]

Thanks!

Ben.

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.