Subject: K-ALG negotiation

From: "Ron Hoffman" <[email-masked]>
Date: Sat, 6 Apr 2002 09:44:09 -0500

LIPKEY has a problem if the underlying SPKM-3 mechanism performs K-ALG
negotiation.  LIPKEY assumes that the SPKM-3 context will be established
after 2 messages (REQUEST and REPLY-TI).  However, if K-ALG negotiation
occurs, there will be a REPLY-IT message from the initiator.  There will
be no message returned from the acceptor in response since the SPKM-3
context will now be established.

The problem is how to continue with the LIPKEY context establishment in
this situation.  I think there are 4 options:

1) Ignore this scenario and mandate that K-ALG negotiation cannot occur.
This raises a future interoperability issue if a new K-ALG is
introduced.

2) Have the LIPKEY gss_accept_sec_context() return GSS_S_CONTINUE_NEEDED
and a zero-length output token after processing the REPLY-IT message to
complete the SPKM-3 context establishment.  This means
gss_init_sec_context() would need to be called with a zero-length input
token.  I'm not sure this is legal.  RFC 2743 seems to imply that
GSS_S_CONTINUE_NEEDED indicates the output token is to be sent to the
partner and yet a zero-length token means no token is to be sent.

3) Combine the final output token from gss_init_sec_context() with the
gss_wrap() token for the LIPKEY signon.  This would be for the case
where the SPKM-3 gss_init_sec_context() returned an output token with
GSS_S_COMPLETE status.

4) Define a new LIPKEY token to be sent from the acceptor to the
initiator to handle the case where the SPKM-3 gss_accept_sec_context()
returned GSS_S_COMPLETE and no output token.  This token would trigger
the LIPKEY gss_init_sec_context() to generate the gss_wrap() token
containing the LIPKEY signon.

What do you think?

Ron Hoffman ([email-masked])