Hi Jari--comments inline:
On Aug 26, 2009, at 5:05 AM, Jari Arkko wrote:
Ben,
Thanks for your review!
Wrt. authorization, the document does make it clear that bulk
revocation requires explicit authorization (search for
"authorization"). The document does not say how to achieve this, but
I would assume a global configuration flag or a list of authorized
peers. We could add this to the document, if you think it helps.
I think it would help. Even some non-normative examples might help.
I think the most important thing is to give guidance on what the
implementor needs to consider, and what sort of bad things can happen
without proper authentication.
When it comes to non-bulk revocation messages, I'm not sure their
requirements are any different from the rest of the signaling.
First, the protocol intrinsically enables only the revocation of
sessions created by the two parties. Secondly, existing messages can
already be used to create and delete sessions from clients --
binding revocation simply adds a capability to do that from the
server side as well. Additional requirements for authorization
mechanisms could be added here, but I'm not sure its needed.
I think it would help to add that to the security considerations,
along with some discussion on whether the ability to revoke from the
server side adds any new considerations. I can accept that the answer
may be "no, it doesn't", but that is easier to accept with some
supporting discussion :-)
Jari
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf