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

[Benjamin Kaduk]

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 <kaduk@MIT.EDU> wrote:
>
>> commit 8e0451de7dbdc3abb335bffc79e30d7c51d6c78b
>> Author: Ben Kaduk <kaduk@mit.edu>
>> 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 <kaduk@mit.edu>
>> 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 <kaduk@mit.edu>
>> 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 <kaduk@mit.edu>
>> 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 <kaduk@mit.edu>
>> 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 <kaduk@mit.edu>
>> Date:   Wed Oct 24 23:26:49 2012 -0400
>>
>>     Clarify token expiry
[as is this, becoming a long one]
>
>> commit 0309471e70db7a363892cc345e0e591409c46ac2
>> Author: Ben Kaduk <kaduk@mit.edu>
>> 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]