Subject: Re: [kitten] OAuth SASL new version -05

From: [email-masked] (Martin Rex)
Date: Thu, 20 Sep 2012 06:10:48 +0200 (CEST)

I don't know whether your question was already answered
(I'm trying to catch up on old email...)

Simon Josefsson wrote:
> Thanks for update, I think we are getting there...
> 
> On error messages, the section reads:
> 
>    In the case where authorization fails the server sends an error
>    result, then client MUST then send an additional message to the
>    server in order to allow the server to finish the exchange.  Some
>    protocols and common SASL implementations do not support both sending
>    a SASL message and finalizing a SASL negotiation, the additional
>    client message in the error case deals with this problem.
> 
> The reason is not lack of support in protocols/implementations, it is
> RFC 4422 that requires that behaviour, quoting it:
> 
>    The protocol may include an optional additional data field in this
>    outcome message.  This field can only include additional data when
>    the outcome is successful.
> 
> So I would rewrite the above paragraph into:
> 
>    Section 3.6 of [RFC4422] explicitly prohibits additional information
>    in an unsuccessful authentication outcome.  Therefor, the error
>    message is sent in a normal message.  The client MUST then send an
>    additional empty message to the server in order to allow the server
>    to finish the exchange.
> 
> There may be some considerations for the GSS-API mechanism side here,
> I'm not sure if the client should return GSS_S_COMPLETE or
> GSS_S_CONTINUE_NEEDED on the first gss_init_sec_context call.  Is it
> permitted for applications to call gss_init_sec_context again, with a
> new token from the server, if it has already returned GSS_S_COMPLETE?  I
> suspect so, but I can't find the text in RFC 2743 now.  In this case,
> gss_init_sec_context would then return GSS_S_FAILURE afterwards which is
> a bit odd but maybe fine.

It is an error to pass a context-level token to the local context
establishment iteration call (gss_init_sec_context() on the initiator
side and gss_accept_sec_context() on the acceptor side) once the
security context has been established, i.e. when the previous call
returned GSS_S_COMPLETE.  You have to pass such a context token
to gss_process_context_token() instead.  This situation can arise
when an error is detected on the final leg of the handshake by
the recipient of the final regular context level token, and the
implementation wants to send back an error token.

See the description of gss_process_context_token()
in rfc2743, Section 2.2.4 GSS_Process_context_token call:

  http://tools.ietf.org/html/rfc2743#page-55

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Sep 2012 09:06:04 +0200

>   http://tools.ietf.org/html/rfc2743#page-55

Nice observation!  I had forgotten about gss_proecss_context_token.
However, I don't think the OAuth GSS-API mech could use it since it has
to be compatible with GS2 which would never use
gss_process_context_token.  I'll have to think more about how to resolve
this...

/Simon