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

Jeffrey Hutzelman wrote:
> 
> 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.

In principle, such an extension would be OK, provided that the spec
was sufficiently clear to provide a fallback continuation of the
security context handshake.

Compliant gss-api mechanisms are not normally sending context tokens with
an unknown TOK_ID, so this change should --in theory-- not break existing
conforming implementations.

I don't remember that such a change was ever discussed, and I consider
it significantly underspecified and hidden.

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

I know that the KRB_ERROR token is part of rfc1964 and understood
by rfc1964 peers, but that is not what I meant.

The interoperability that I was refering to was not the indication
of an error, but the attempt of recovery that Microsoft has built
into their Kerberos SSP and for which the CONTINUE_NEEDED is necessary.
Microsoft's Kerberos SSP will perform a second attempt to establish
the security context on the same security context handle with another
token exchange--and on this feature the other Kerberos 5 implementations
will likely not interoperate (because it is not standardized anywhere).

> 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,

They can and they do use semantics for SSPI that differ from GSS-API,
but that makes them non-conforming to rfc-1964/rfc-4121.
(they still use the same wire-format, but the GSS-API standard
includes API semantics, not just mechanism wire-format.

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

Yup, that's what it will have to do.

My wrapper is currently limited to rfc-1964 Kerberos, so it aborts
on user2user context establishment tokens and aborts with an error
when AcceptSecurityContext returns CONTINUE_NEEDED (because rfc-1964
is limited to 1- and 2-token context establishment handshakes).

Another interoperability problem with Microsoft Kerberos is the
security context lifetime limit required by rfc-1964.
When Microsoft tried to activate that in Windows 2000 beta3
hell broke loose because none of their applications could handle
expiring security contexts.  So they deliberately ignore it.
My gssapi wrapper adds this back in, so that you have consistent
behaviour within the entire Kerberos5 infrastructure.

-Martin

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