Hey list: Nico reviewed the rxgk document, his comments are in the quoted
text.
The biggest (not super-big, but a little big) question I want feedback on
is whether we should axe the complete description of the GSS negotiation
loop and just make use of references to other examples/descriptions.
Most of the changes are minor and I've taken them (or a similar version)
without comment. A rendered version is up at
http://web.mit.edu/kaduk/Public/draft-wilkinson-afs3-rxgk.txt (I didn't
see the need to submit a new I-D until the negotiation loop description
question is answered); the XML source is still at
https://github.com/kaduk/openafs/commits/prot
The I-D submission cutoff is on monday, I'd like to get a new revision in
before then.
[more inline]
On Mon, 14 Oct 2013, Nico Williams wrote:
On Fri, Sep 20, 2013 at 12:42:12PM -0400, Benjamin Kaduk wrote:
Is there any chance you could look it over and give your comments?
It's section 6 of
http://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-07 , and
ideally comments would go to the [email protected]
list.
- Section 4, authentication only also does not protect against
eavesdroppers. I know, obvious.
- 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.
- Section 4, the paragraph following the list is redundant.
- 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.)
- 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.
- 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.
- page 6:
What is:
package RXGK_
? Is it unfinished?
This is part of the syntax used by rxgen, basically placing everything
that follows into the RXGK namespace...
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.
- 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.
- 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...
- 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:
OLD:
6.2. GSS Negotiation Loop
The client proceeds through a GSS security context initialization
loop, with alternating calls to GSS_Init_sec_context() and the
GSSNegotiate() RPC, until an error or success condition is reached.
Each call to GSSNegotiate will return an output token from
GSS_Accept_sec_context() and/or an output opaque to be used as an
input for a subsequent call to GSSNegotiate, if such a subsequent
call is necessary.
NEW:
6.2. GSS Negotiation Loop
The client runs a standard loop over GSS_Init_sec_context() [RFC2743]
(see also C example in [RFC2744]). Security context tokens output by
GSS_Init_sec_context() are sent in a GSSNegotiate() RPC, and security
context tokens output by GSS_Accept_sec_context() on the server side
are sent as results of this RPC.
The server calls GSS_Accept_sec_context() to process security context
tokens sent as the input_token_buffer input parameter of the
GSSNegotiate() RPC. The server sends the response token, as well as
an opaque context identifier, in the output_token_buffer and
opaque_out output parameters of the GSSNegotiate() RPC result,
respectively.
This is repeated until the security context token exchange is
complete (i.e., GSS_Init_sec_context() or GSS_Accept_sec_context()
return GSS_S_COMPLETE) or an error results (GSS_Init_sec_context() or
GSS_Accept_sec_context() return any major status other than
GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED). The opaque_out result of
any GSSNegotiate() RPC is sent as the opaque_in input of the next
GSSNEgotiate() call, if any.
I took this, with a few tweaks.
- Section 6.2, third paragraph:
OLD:
Different GSS mechanisms will require a different number of full (or
half) round trips. ...
NEW:
GSS security context token exchanges are synchronous and may involve
any number of context tokens larger than or equal to one.
Implementations MUST NOT assume any number of context tokens for any
one mechanism, but implementations MAY set an upper bound no less
than six (6).
I'm not sure where the number six is coming from, so I haven't taken this
part yet. The rest of the wording is probably okay to take, though.
...
- Section 6.2, structure of loop. I think this is a bit odd and
redundant. The structure of the loop is quite standard; repeating it
is useful when the reader doesn't know anything about the GSS-API,
but otherwise it could be a source of bugs and confusion.
It'd be better to describe the req_flags that MUST/SHOULD and/or MUST
NOT/SHOULD NOT be set, the ret_flags that MUST/SHOULD or MUST NOT/
SHOULD NOT be set on success. Include a RECOMMENDation to send any
context tokens when GSS_Init/Accept_sec_context() return an error.
Less text, mo' better.
For example, I think there's no need to discuss non-sensical GSS
results, like GSS_S_CONTINUE_NEEDED w/ no output sec context token.
- I.e., remove all of the items 1..4 in section 6.2 and replace them a)
with the above text, and b) with text explaining what to do when
GSS_Init/Accept_sec_context() returns GSS_S_COMPLETE. E.g., when
GSS_Init_sec_context() returns GSS_S_COMPLETE *and* an output token
then the client MUST send it in a GSSNegotiate() RPC... the client is
not done until the server returns an rxgk_info... if the context is
fully-established but there's no rxgk_info then the client must close
the connection and delete the security context token...
This hunk is the biggest question remaining.
I think Simon at one point (when the text was pretty broken) said that he
would prefer nothing at all to the (then-) current text, but I'd like to
hear from others, particularly jhutz, before committing to that route.
I do agree that there's nothing particularly special about what we're
doing here and that if an implementor knows how to do a GSS negotiation
loop in general, they should be fine implementing rxgk. The question (to
me) is more of whether we want to assume that level of expertise on the
reader, and whether we think that we can give references/examples to
enough good sources that an inexperienced reader could produce a correct
implementation.
- Section 6.3, first para, first sentence, replace "rxgk_info
contains..." with "rxgk_info contains GSS wrap token (as output by
GSS_Wrap() with the established security context on the server side)
taken over the XDR encoding of an RXGK_ClientInfo structure. If
confidentiality protection is available (i.e., conf_ret_flag was
set), then conf_flag MUST be set to true in the call to GSS_Wrap())."
- 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.
- Section 6.3, what is 'K0'? Maybe it should be defined first? Or
maybe it should be named later?
- Section 6.3, s/K, the desired output length/The required output
length (here denoted as K)/
That didn't quite match up with the structure of the list, with the item
being described appearing first.
Although I'd want this to be K_len or something more indicative of
its meaning (K tends to denote "key" to me).
- Section 6.3, reference RFC4401 where GSS_Pseudo_random() is first
mentioned?
- 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.
- 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.
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]
Feel free to share this with Simon or anyone else.
The list is "anyone else", yay.
Thanks again for the review.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
