[AFS3-std] Finishing the core rxgk document

[Nico Williams]

On Thu, Oct 17, 2013 at 11:08:18PM -0400, Benjamin Kaduk wrote:
> On Mon, 14 Oct 2013, Nico Williams wrote:
> 
> >- rxkad is mentioned (first in Section 4) without definition nor
> >  references.
> 
> It's a bit awkward, since we're sort of bootstrapping the
> standardization of AFS, and there's no real reference for rxkad.  I
> talked about it a little in the introduction, at least.

I meant (but should have been explicit about) that you should have a
paragraph explaining what rxkad was.  No need to have a specification
for it.

> >- Section 5, is there any latency expectation regarding how long it
> >  takes to identify a client user from a token?
> 
> I don't think there are any particularly concrete expectations.
> The client does have some timeouts at the connection level, but
> those will be seconds at least.  (I don't know the concrete values
> offhand.)

I was just curious as to what implementation alternatives besides
"encrypted token" are permitted.  Note that if the token concept is not
nailed down in detail then different implementations of servers in a
cell may not interop.

Oh, speaking of which, should the term "cell" be defined?  It's odd to
read this I-D and not see "cell" come up at all.

> >- Section 5, maybe the notional *minimal* contents (decrypted or
> >  looked-up) of the token should be described with an XDR struct?  See
> >  comment below about K0; it'd help to state that the root session key
> >  is part of the token.
> 
> I think I could picture a scenario when only the session key is
> needed, amusingly enough.  (The negotiation service only issues
> tokens to authorized users, all users have full permissions, and no
> one cares about expiry.)  The companion document
> draft-wilkinson-afs3-rxgk-afs does have an explicit token format for
> the use with the AFS protocol.

Hmm, but the user ID info has to be in there for ACL evaluation
purposes.  An ACL-less server wouldn't need that... but that'd be
boring.

> >- Section 6, what language is used for the data description?  It's not
> >  XDR proper...  If it's a superset of XDR, maybe we can express the
> >  input and output parameters of the GSSNegotiate() RPC as structs,
> >  just as... ONC RPC does.  Then you get the benefit of being able to
> >  use rpcgen(1), if nothing else to validate the spec.
> 
> It's written so as to be compatible with rxgen(1), our fork of
> rpcgen(1); the language itself is called "RPC-L" which is basically
> XDR for structures plus a syntax for writing RPC prototypes and
> their names.

Ah, thx.

> >  Later this operation is referred to as RXGK_GSSNegotiate, then later
> >  again as GSSNegotiate, so I suspect there is a formatting error here.
> >  If nothing else it's confusing.
> 
> ...so the routine that clients will call from the C code is
> RXGK_GSSNegotiate().  But, it's probably easiest to continue
> referring to the RPC as just GSSNegotiate() in the document, there
> was only one instance with the RXGK_ prefix, so I removed the prefix
> in that instance.

Yes, thanks.

> >- Section 6, the gss_minor/major_status values need to be explicitly
> >  described as entirely optional and informative -- of no normative
> >  value, even in error conditions, EXCEPT that the major status is of
> >  normative value IFF the no output_token_buffer field is absent, and
> >  the gss_major_status value is present.
> >
> >  Please RECOMMEND that error tokens be sent (as output_token_buffer).
> >
> >  No need to say anything about whether to bother sending
> >  gss_major/minor_status.  UNLESS successfully established security
> >  contexts can be rejected by the server, though even then, no
> >  gss_major/minor_status code could be of use in conveying such
> >  authorization decisions.  (Ah, but I see that successful sec ctx
> >  establishment is not sufficient, and that subsequent non-GSS errors
> >  can be communicated via the errorcode of the RXGK_ClientInfo.
> >
> >  Is gss_major_status strictly optional?  Is it possible for rxgk_info
> >  to be present but gss_major_status to be absent?  I think it's
> >  important to be clear on this point.  Actual implementation behavior
> >  for existing implementations may be relevant.
> 
> Unfortunately, we are using gss_major_status as an indicator for
> whether the contents of rxgk_info are valid.  This is not a great
> situation to be in, given that the abstract GSS-API does not seem do
> indicate that GSS_S_COMPLETE has value 0 (as jhutz has actually
> pointed months ago on this list, which I noticed as I was reviewing
> the old threads just now).
>
> I added some text calling out GSS_S_COMPLETE as 0, and noting that
> any distinction between different non-zero values is purely
> informational, but this setup is kind of ugly.  I think the protocol
> as currently set up does need an external indicator that the
> rxgk_info has valid contents, though (that is, that the server is
> GSS_S_COMPLETE and has produced a token), and this field is probably
> the best place to do so.

So specify the use of the C bindings' major status codes.  I.e.,
reference RFC2744 for this.

> >- Section 6, bytelife is described as informative, not normative, but
> >  similar detail is not provided for lifetime.
> >
> >- Section 6, but maybe client_nonce shouldn't be too large...  Dual_EC
> >  DRBG comes to mind!
> 
> I mentioned that it SHOULD NOT be longer than the actual key it's
> producing, but from the DUAL_EC_DBRG standpoint, even the 160 bits
> we give as a minimum may be too much...

Yes, I think so.  But, whatever, I think we should eventually start to
design protocols with minimal amounts of cleartext nonce data, and
minimal amounts of confounders where the attacker can select plaintexts
that produce leaky confounders.  For this protocol it's too late.

> >- Section 6.2, first paragraph, I think we should describe the context
> >  token exchange as much as possible in terms that reference RFCs 2743
> >  and 2744.  My suggestion:
> 
> I took this, with a few tweaks.

OK.

> >- Section 6.3, first para, third sentence: I'm confused.  Is it ever
> >  OK to not use conf prot?  The first sentence seems to imply "yes" (if
> >  the mech does not support conf prot).
> 
> I went back and looked at the history for why that bit was added.
> Basically, a lack of confidentiality is a failure, but it's a
> failure that we report in the errorcode of the RXGK_ClientInfo.
> Since we need to return the ClientInfo inside a GSS_Wrap token, we
> have to allow non-confidential wrapping in that case, but the idea
> is to only allow it in that case.  I hope the updated text is more
> clear on this matter.

Ahhh, got it.  Thanks.  So it's an error, and it is reported as strongly
as possible, and it's fatal.

> >- Section 7, hmmm, so KRB5-FX-CF2 takes two peppers as arguments, but
> >  in its description they are labelled just octet strings.  It's not
> >  clear that those strings are the peppers referenced afterwards in
> >  RFC6113.  No big deal.
> 
> Yeah, not much we can do on our end, here.

Well, you can point it out.  Anyways, not terribly important as it
becomes obvious enough on close reading of RFC6113.

It also seems to me that RFC6113 should have been marked as "updates
RFC3961", since it adds to the Kerberos crypto API...

> >- Security considerations: should we now note that nonces present an
> >  opportunity for a) exploiting backdoored RNGs, b) a covert way to
> >  sneak out session key data?
> 
> I'm not really convinced that we're doing anything special enough to
> merit mentioning this.  Yes, it is a theoretical issue, and it's
> getting some coverage elsewhere at present, but I don't really want
> to do much more than (potentially) refer to some other description
> of the issue.

It's not theoretical.  Other than that, I agree.

> >That's it for now.  I'll review section 8 some other time.
> 
> [I got a note on IRC that there were no comments about section 8]

Correct.

Nico
--