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

Liqiang wrote:
> 
> Jeff wrote:
> > This is a good point.  GSS_S_CONTINUE_NEEDED indicates that it will be
> > necessary to make the call again with another token provided by the peer. 
> > When GSS_Init_sec_context or GSS_Accept_sec_context emits an error token, 
> > it should also return an appropriate error status, not 
> > GSS_S_CONTINUE_NEEDED.
> 
> This is not necessary accurate. In the User2User protocol,
> http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.txt,
> the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status.

Returning a KRB_ERROR token along with GSS_S_CONTINUE_NEEDED minor_status
from gss_accept_sec_context() is defintely *NOT* allowed by rfc-1964.

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].

But since the spec is entirely silent about how the client can continue
to produce a successful security context establishment from that point on,
it is sufficiently incomplete to be unusuable.

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.

-Martin

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