[AFS3-std] Re: afs3-rxgk-updates for 03

Benjamin Kaduk kaduk@MIT.EDU
Fri, 2 Nov 2012 19:07:20 -0400 (EDT)


On Fri, 2 Nov 2012, Thomas Keiser wrote:

> On Nov 2, 2012 6:16 PM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
>>
>> Good point.  I've got in my local copy:
>>
>>          SHOULD only offer the CombineTokens operation to clients
> connecting
>> -        over an rxgk secured connection.</t>
>> +        over an rxgk secured connection, with an RXGK_Level of
> RXGK_LEVEL_AUTH
>> +        or higher.</t>
>>
>> I'm wavering on higher vs. better (or something else).
>>
>
> Higher would imply a hierarchy of levels.  I cannot recall offhand: did we
> elide the (experimental) 'bind' level for the moment?  (For those
> unfamiliar, my recollection from Edinburgh is that 'bind' was envisioned to
> permit future boot-strapping of, e.g., rxgk-protected rxtcp on top of TLS.)
> If we've removed 'bind' from the working document, then your implication
> may be defensible.  Failing that, I think we would need to reach a decision
> on whether the 'bind' level warrants the additional complexity of
> prescribing a means to evaluate relative level strength.  If we decide to
> deal with the complexity attendant with 'bind', then perhaps 'stronger'
> would be the best term?

'bind' is included in this draft.  We have:
enum RXGK_Level {
     RXGK_LEVEL_CLEAR = 0;
     RXGK_LEVEL_AUTH = 1;
     RXGK_LEVEL_CRYPT = 2;
     RXGK_LEVEL_BIND = 3;
};

Channel-binding reduces the authentication problem to a lower-level 
protocol, so there is no denial of service possibility if connections must 
be made over a channel-bound connection.  That's why I'm okay with 
"higher" in this context, though I agree that it may require further 
evaluation for use in other contexts.

-Ben