[SPKM] Re: Comments on draft-zhu-pku2u-01.txt

On Monday, March 19, 2007 04:25:34 PM +0100 Martin Rex <martin.rex@sap.com> 
wrote:

> There seems to be text describing a backward incompatible change in
> rfc-4121 last paragraph of section 4.1, (top of page 5) which
> allows such misbehaviour for the specific case of an unknown token ID:
>
>    If an unknown token identifier (TOK_ID) is received in the initial
>    context establishment token, the receiver MUST return
>    GSS_S_CONTINUE_NEEDED major status, and the returned output token
>    MUST contain a KRB_ERROR message with the error code
>    KRB_AP_ERR_MSG_TYPE [RFC4120].

That looks to me like an error in RFC4121.  Clearly the status in this case 
should not be GSS_S_CONTINUE_NEEDED.

> SSPI has been returning KRB_ERROR tokens along with CONTINUE_NEEDED
> status from the beginning, in an undocumented/unspecified fashion,
> non-interoperable with rfc-1964 based Kerberos implementations.

Oh, it interoperates, because initiators respond to the KRB-ERROR by 
returning an error, so the application gives up and never sends a token 
back.  The problem is that returning GSS_S_CONTINUE_NEEDED in this case is 
likely to confuse a GSS-API application on the acceptor side, because it 
expects to receive another token from the client.  OTOH, since you're 
describing the behavior of SSPI, not GSS-API, and CONTINUE_NEEDED is an API 
construct, this situation is perfectly fine -- SSPI can establish different 
(even broken) semantics for its applications, and an API translation module 
such as the one you maintain will have to deal.  I'd assume you would do 
this by "knowing" when the mechanism is Kerberos, peeking inside the token, 
and turning GSS_S_CONTINUE_NEEDED into something else if the token is a 
KRB-ERROR token.  Ugly, but perhaps necessary.

-- Jeff

_______________________________________________
SPKM mailing list
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm