[AFS3-std] New Version Notification for draft-wilkinson-afs3-rxgk-06.txt (fwd)

[Jeffrey Hutzelman]

On Thu, 2013-07-11 at 15:40 -0400, Benjamin Kaduk wrote:

> > BTW, this may also mean that the server needs to do some sort of replay
> > protection with its opaque tokens.  An exported partially-established
> 
> The GSS tokens, or the ones used to serialize server state across 
> nominally-stateless RPCs (the "opaque_out" and "opaque_in" arguments of 
> the GSSNegotiate RPC)?  I assume the latter.

Yes.


> > context ought to be re-importable only once.  I don't really recall what
> > the API spec says about dealing with this.
> 
> The GSS tokens should only be usable once, I agree.
> In practice, this probably means that you can't call GSSNegotiate against 
> one vlserver and then try to finish against a different vlserver.

Yeah, I wouldn't expect that to be portable.  Whatever the server does
to manage partially-established contexts, whether it's an encrypted
export-context token or a reference into a private table, it's not going
to work across servers.  I don't think rxgk-base needs to say much about
that, though.


> My rough plan for implementing multi-round-trip mechanisms on the 
> server-side was to cache partially-constructed GSS security contexts, with 
> a cap on how many can be cached at once and an expiration timer on them. 
> That would eliminate any need to either export/import the 
> partially-constructed context or replay GSS tokens.

Yes, I think that's better than depending on the GSS mechanism
implementation supporting export of partially-established contexts.


> >>> - Don't conflate GSS_S_CONTINUE_NEEDED with an output token.  The
> >>>  GSS_S_CONTINUE_NEEDED flag indicates that another call with an input
> >>>  token is expected, not that an output token was provided.  So...
> >>
> >> Right.
> >>
> >>>  + If GSS_Init_sec_context produced a token when the server wasn't
> >>>    expecting one, or failed to produce one when it was, that is an
> >>>    error, and negotiation fails.
> >>>
> >>>  + If GSS_Accept_sec_context produced a token when the client was
> >>>    not expecting one, or failed to produce one when it was, that is
> >>>    an error, and negotiation fails.
> >>
> >> These will both be caught by the counterparty's next GSS call and need not
> >> be handled explicitly.
> >
> > I'm not convinced.  This is an authentication exchange with an untrusted
> > party; if something fails locally, you have to fail it locally, not
> > depend on the other party to fail.
> 
> I guess (part of) the problem is that our story for reporting errors from 
> the server to the client is lousy (the bootstrapping problem abpve).  I 
> think there probably will need to be some place for Rx aborts, and we'll 
> need to make the client do the least bad thing.

Well, whether it's an abort or something else, there comes a point where
the server decides that the negotiation has failed.  It doesn't _have_
to return any particular error, but it needs to commit to that exchange
never succeeding, and ideally it should not call GSS_Accept_sec_context
again for that exchange.  It would be polite to return an error, but I
suppose it could do something else.


> >> Are you claiming that the breakdown in step 4 is an invalid decomposition?
> >
> > I believe it's incorrect.  In that breakdown, if the server asserts that
> > another cycle is needed but the client's last call returns
> > GSS_S_COMPLETE, then the loop terminates successfully.  But this is
> > actually a failure condition.
> 
> The client will (must!) fail if there is no usable ClientInfo returned. 
> I'm not sure that we need to be terribly concerned about whether we call 
> this a negotiation failure or just a failure.
> 
> I'm not sure I understand your statement, though.

Oh, hm.  s/returns/returned/ may make it clearer.

If the client calls GSS_Init_sec_context and gets GSS_S_COMPLETE with a
token, and then calls GSSNegotiate() with that token and the server
asserts CONTINUE_NEEDED, then your description in step 4 says

       *  If the most recent call to GSS_Init_sec_context() returned the
          major status code GSS_S_COMPLETE and an output token, the
          negotiation loop is in a success condition and terminates.

But in fact, the loop is not "in a success condition"; it's in a
condition that can only occur if the client and server state machines
are out of sync, which is an error.

I do think we should be explicit about this sort of thing, because what
we're essentially doing is telling people in no small amount of detail
what API calls to make when and what to do with the results.


> >> I believe I used to have an explicit case for the client expecting a token
> >> and the server not returning one, but Simon noted that we can just
> >> continue the loop and the next Init_sec_context call will detect the
> >> error.
> >
> > If the server asserts CONTINUE_NEEDED and does not send a token, that's
> > always an error.  The SSH text appears to presume that an empty token is
> > the same as no token at all.  I can't remember offhand if that's true,
> > but we tried to be fairly careful writing that particular bit of text
> > (well, actually, it was pretty bad at first, and then there was a round
> > of careful editing and rewriting), so it probably is.
> 
> Do you think we should change all occurrences of "output token" to 
> "non-empty output token"?

Oh, hm; there were two separate statements there:

1) CONTINUE_NEEDED without a token is an error, and we should treat it
as such, rather than calling GSS_Init_sec_context with no input token,
which means something rather different.

2) I can't remember whether "empty token" and "no token" are distinct.
That requires a rereading of the spec, and if the answer is that they
are not, then yes, I think we should word things in terms of non-empty
tokens.



> > FWIW, there may be _non-security_ reasons to favor an output parameter
> > over an abort, and I have no problem with that (but avoid synthesizing
> > GSS errors, especially since the client can't actually interpret them
> > anyway).
> 
> I don't think we should add a non-abort non-gss-status "error code" output 
> parameter other than the one already in the ClientInfo.

That's fine.  I'm not proposing adding such a thing, just clarifying
that I'm not objecting to avoiding aborts, only to avoiding them on the
grounds that the failure indication needs to be secure.


> I will work on updates to the document.

OK.  I look forward to seeing a new one.

-- Jeff