[AFS3-std] Rx clear identity assertion draft

[Tom Keiser]

On Tue, Jan 12, 2010 at 12:43 PM, Derrick Brashear <shadow@gmail.com> wrote:
> On Tue, Jan 12, 2010 at 11:56 AM, Tom Keiser <tkeiser@sinenomine.net> wrote:
>
> Generally, it looks good.
> As before, I'm uncertain it's reasonable to cite the kolya Rx spec as
> normative given how it's referred to.
>

Hi Derrick,

First, thank you for the feedback.  I've published a new draft with
your suggested reference change.  Note: I inadvertently uncommented
the boilerplate appendix section in the process; I will fix in -02.

http://tools.ietf.org/html/draft-tkeiser-rxrpc-sec-clear-01
http://openafs.sinenomine.net/~tkeiser/draft-tkeiser-rxrpc-sec-clear-01.html
http://openafs.sinenomine.net/~tkeiser/draft-tkeiser-rxrpc-sec-clear-01.xml

/afs/sinenomine.net/user/tkeiser/public_html/draft-tkeiser-rxrpc-sec-clear-01.txt
/afs/sinenomine.net/user/tkeiser/public_html/draft-tkeiser-rxrpc-sec-clear-01.html
/afs/sinenomine.net/user/tkeiser/public_html/draft-tkeiser-rxrpc-sec-clear-01.xml


> The attacks possible on multihome give me pause but given the security
> you get with clear, it's almost certain not worth worrying about.
>

Admittedly, they give me pause as well.  My goal was to provide a
means to work around renumbering on existing connections that: a)
minimizes round trips, and b) requires no changes to existing Rx
applications.  I need to re-read my language to be sure, but I don't
think any of this precludes API-level tunables that allow clients or
servers to explicitly deny seamless renumbering in favor of call error
codes -- which, combined with the new security object,  allow the
caller to introspect into the purported renumbering event and make
informed decisions about how to recover from the fault in a timely
manner.

-Tom