On Fri, 2 Nov 2012, Thomas Keiser wrote:
On Nov 2, 2012 6:16 PM, "Benjamin Kaduk" <[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
