[AFS3-std] Last Call: afs3-rxgk-04, afs3-rxgk-afs-02

[Benjamin Kaduk]

On Fri, 26 Apr 2013, Jeffrey Hutzelman wrote:

> On Fri, 2013-04-26 at 13:03 -0400, Benjamin Kaduk wrote:
>
>> Well, this document does not define a token format, so there remains work
>> for any application wishing to use rxgk.
>
> Not necessarily.  rxgk-afs needs to define a token format, because its
> tokens are expected to be shared across multiple servers (and services).
> For a generic application, this is not the case, and the token format
> can be implementation-dependent.  I had sort of assumed from the
> beginning that the token format would be private to each rxgk
> implementation, and applications don't need to get into it at all.

My point was that the application, even internally, needs to have 
something to use as a token in order to use rxgk.  Whether or not you call 
that "integration" is a matter of semantics that I don't have much 
interest in debating.


>>
>>>>       typedef opaque RXGK_Data<>;
>>> [ ... ]
>>>>           RXGK_Data token;
>>>
>>> Given we're limiting everything else, should we also put some kind of
>>> upper limit on the size of the token? We do need to consider, though,
>>> that a token may contain non-Kerberos identities, and X509 (in
>>> particular) identities can be very large.
>>
>> There should probably be a limit of some sort.  It's unclear whether this
>> limit should be different from a hypothetical global default limit on the
>> size of an opaque type (per the thread Andrew started).  (My picture of
>> this is that openafs's rxgen would translate opaque<> into, say,
>> opaque<16k>, but that opaque<1m> given explicitly would still be allowed.
>> Numbers not guaranteed to bear resemblence to reality.)
>>
>> If we were to explicitly limit the size of a token (or a generic
>> RXGK_Data, I suppose), what would such a limit be?  If we start talking
>> about X.509 identities, maybe 16k is too small?
>
> Some care is called for here.  We've had issues in the past with limits
> on token sizes, so we should try to avoid setting one that is too small.
>
>
> I think perhaps the right thing here might be to say that the limit is
> implementation-defined (or subject to local policy), but MUST NOT be
> less than a certain value.

I could see doing something like that.

>>>>  client_start  The client params structure detailed above.  This
>>>>         should remain constant across the negotiation
>>>
>>> "should" or SHOULD, or even MUST?
>
> "will".  Be descriptive, not prescriptive.

Okay.

>>> 12.3 Nonce Lengths
>>> ------------------
>>>
>>>>  The client_nonce is important for using the MIC of the StartParams
>>>>   structure as a defense against man-in-the-middle attacks,
>>>
>>> I'm not sure what this sentence is trying to say?
>>
>> The hypthetical scenario here is where a client gets two tokens using the
>> same kerberos service ticket.  In my thought experiment, an active
>> attacker could change the startparams for the second request to the
>> server, and replace the 'mic' field in RXGK_ClientInfo with the value from
>> the first request.  Oops, but RXGK_ClientInfo is encrypted for
>> transmission, so things would break pretty fast.
>>
>> Anyway, since client_nonce is sent in the clear, it is not adding secure
>> randomness.  It does make each request unique.
>
> It allows servers to cache and reject replays, no?

I suppose so.  For krb5, the krb5 replay cache could do so as well.

Thanks for the suggestions,

Ben