[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