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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
