Now replying to the bits that Jeff trimmed :)
I'll still trim the +1s, and thank you for them.
On Mon, 29 Oct 2012, Andrew Deason wrote:
On Thu, 25 Oct 2012 09:58:03 -0400 (EDT)
Benjamin Kaduk <[email protected]> wrote:
commit 8e0451de7dbdc3abb335bffc79e30d7c51d6c78b
Author: Ben Kaduk <[email protected]>
Date: Wed Oct 24 17:17:42 2012 -0400
The value zero is special for (byte)lifetime
+1. My previous "objections" on this I don't think really matter. I
didn't see what the point of the MUST restriction was, since the
lifetimes are not strictly adhered to anyway. I don't know if any text
really needs to change, but it helps me to think of this like:
My main motivation for change was to get RFC 2119 language in; there was
some rewording to support it.
The connection has one advisory lifetime. The server and client both
pick an advisory lifetime, and the lifetime for the connection is just
the stricter of the two lifetimes chosen. So the server MUST choose one
at least as strict as the client specified, just to accurately represent
what the connection lifetime actually is, even if the server is not
bound to obey it. (Similarly goes for byte-life.)
That makes sense. I am not particularly inclined to keep rewording this
part of the document, though, so you'll forgive me if I don't try to put
this view in the document.
commit 051c46a6d806e0ce4eab737ff91dc14b34b77375
Author: Ben Kaduk <[email protected]>
Date: Wed Oct 24 17:43:10 2012 -0400
The token need not be an encrypted blob
[that thread already exists]
commit ddfa58a6e558139c7d889813bfd8730de05f6d55
Author: Ben Kaduk <[email protected]>
Date: Wed Oct 24 18:06:59 2012 -0400
Add internal cross-references
[...]
@@ -422,7 +426,8 @@ enum RXGK_Level {
the client stores the current timestamp as an rxgk_Time
(start_time for the rest of this discussion), and
then uses this, along with other connection information, to derive a
- transport key from the current user's master key.</t>
+ transport key from the current user's master key
+ (<xref target="derivation" />).</t>
[...]
@@ -519,7 +524,8 @@ enum RXGK_Level {
<list style="hanging" hangIndent="6">
<t hangText="start_time:">The time since the Unix epoch
- (1970-01-01 00:00:00Z), expressed as an rxgkTime.</t>
+ (1970-01-01 00:00:00Z), expressed as an rxgkTime
+ (<xref target="time" />).</t>
I think e.g. (see <xref target="derivation" />) looks a little better
for some outputs, since iirc sometimes the xref is just translated into
e.g. [2] with a link.
I was only looking at one format, sure. I'll amend this in my tree.
commit 74bc8de3886728c5ace1a28a4c0eacf0c2d68275
Author: Ben Kaduk <[email protected]>
Date: Wed Oct 24 22:22:10 2012 -0400
Use RXGK_Levels more appropriately
[...]
@@ -403,7 +403,9 @@ enum RXGK_Level {
</t>
<t>To reduce the potential for denial of service attacks, servers
SHOULD only offer the CombineTokens operation to clients connecting
- over an rxgk secured connection.</t>
+ over an rxgk secured connection. The RXGK_Level of the rxgk
+ connection does not affect the resiliance against denial of
+ service attacks.</t>
I find the purpose of that last sentence ("don't require any particular
RXGK_Level") not immediately clear from that text. This is minor, but
possible suggested text:
- over an rxgk secured connection.</t>
+ over an rxgk secured connection. The server SHOULD accept
+ connections with any RXGK_Level, since the RXGK_Level of the rxgk
+ connection does not affect the resiliance against denial of
+ service attacks.
This came from a note from the Deason/Keiser/Meffie/Vitale conference
call:
* (Paragraph 2) It would be helpful to indicate that rxgk level doesn't matter:
clear is ok because contents are not susceptible to sniffing/
attack, i.e., this policy is merely DoS protection.
I do think your text is more clear than mine, though I would add "SHOULD
accept CombineTokens connections" and maybe something about the resilience
of rxgk being as opposed to a non-secured connection. I'll put rewording
this on my todo list.
commit c23fc51c268fefc460b224a12b63cd9a9672b538
Author: Ben Kaduk <[email protected]>
Date: Wed Oct 24 23:21:29 2012 -0400
Describe the GSSNegotiate errorcode field
[this is already a separate email thread]
commit 13a2d01b722969da997f1878ad176991fb0ffabc
Author: Ben Kaduk <[email protected]>
Date: Wed Oct 24 23:26:49 2012 -0400
Clarify token expiry
[as is this, becoming a long one]
commit 0309471e70db7a363892cc345e0e591409c46ac2
Author: Ben Kaduk <[email protected]>
Date: Wed Oct 24 23:46:36 2012 -0400
Clarify CombineTokens' least-permissiveness
The 'special case' here seems unnecessarily awkward. We can just say
that lifetime, bytelife, and any application-specific data should be
combined so the result is the most restrictive of the two. The other
fields (enctype, level, expiration) should be set to the minimum of the
input tokens.
Okay. We already described the special-ness, and can use "most
restrictive" to catch that; that seems fair. On my todo list.
-Ben
Also, should the combined token enctype really be set to the minimum of
the input tokens? Does the order of enctypes based on integer value
really mean anything? (should this maybe be "most preferable" enctype
based on the input enctypes, or something?)
[two other threads from this one]
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
