[AFS3-std] Rx Clear security class

[Derrick Brashear]

Only concern I can see is conflicting uses of the private bits such
that my client and your server don't use them the same way. I don't
think this is your problem to solve, however, the potential perils of
it probably do merit a sentence in the document.

Otherwise, looks good to me!

On Mon, Apr 19, 2010 at 1:31 PM, Tom Keiser <tkeiser@sinenomine.net> wrote:
> Hi All,
>
> I released a new version of the Rx Clear security class I-D the other
> day. =A0I am hereby soliciting comments on this new version of the
> draft.
>
> http://tools.ietf.org/html/draft-tkeiser-rxrpc-sec-clear-02
> http://openafs.sinenomine.net/~tkeiser/i-d/draft-tkeiser-rxrpc-sec-clear-=
02.html
> http://openafs.sinenomine.net/~tkeiser/i-d/draft-tkeiser-rxrpc-sec-clear-=
02.xml
> http://openafs.sinenomine.net/~tkeiser/i-d/draft-tkeiser-rxrpc-sec-clear-=
01-02.xml.diff
>
> The major changes in this version of the document are:
>
> * new introductory section that better explains the relationship
> between Rx and AFS-3 so that the document is more approachable for
> novices
>
> * additional prose in the security considerations section which better
> explains how this security object changes the attack vectors, as well
> as a brief mention of securing rxnull/rxclear with IPsec
>
> * flesh out the AFS assigned numbers registrar section with formal
> specifications for each newly requested registry
>
> * change the endpoint identifier type enumeration from 32-bits to
> 8-bits, as the larger size seemed quite wasteful
>
> * mark several security header fields as reserved for future use
>
> * I added a number of informative references to Transarc and CMU ITC
> tech reports
>
>
> As always, any feedback welcomed...
>
> Thanks,
>
> -Tom
>
> _______________________________________________
> AFS3-standardization mailing list
> AFS3-standardization@openafs.org
> http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardi=
zation
>



--=20
Derrick