Subject: RE: GSS-SPNEGO

From: Paul Leach <[email-masked]>
Date: Thu, 11 Feb 1999 18:11:52 -0800

That is almost correct. I am planning to submit an I-D for it for this IETF.
Here's a first crack.

1. GSS-SPNEGO mechanism

   The mechanism name associated with the "Simple and Protected GSS-API
   Negotiation Mechanism" (aka SPNEGO) [RFC 2478] employing the
   GSSAPI [RFC 2078] is "GSS-SPNEGO".

1.1 Client side of authentication protocol exchange

   The client calls GSS_Init_sec_context, passing in 0 for
   input_context_handle (initially) and a targ_name equal to output_name
   from GSS_Import_Name called with input_name_type of
   GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
   "service@hostname" where "service" is the service name specified in
   the protocol's profile, and "hostname" is the fully qualified host
   name of the server.  The client then responds with the resulting
   output_token.  If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED,
   then the client should expect the server to issue a token in a
   subsequent challenge.  The client must pass the token to another call
   to GSS_Init_sec_context, repeating the actions in this paragraph.

   When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes
   the following actions: If the last call to GSS_Init_sec_context
   returned an output_token, then the client responds with the
   output_token, otherwise the client responds with no data.
   The security layer to use is as negotiated by SPNEGO. The
   maximum size output_token the client is able to receive is specified
   by the application protocol.

1.2 Server side of authentication protocol exchange

   The server passes the initial client response to
   GSS_Accept_sec_context as input_token, setting input_context_handle
   to 0 (initially).  If GSS_Accept_sec_context returns
   GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
   to the client in challenge and passes the resulting response to
   another call to GSS_Accept_sec_context, repeating the actions in this
   paragraph.

   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes
   the following actions: If the last call to GSS_Accept_sec_context
   returned an output_token, the server returns it to the client in a
   challenge and expects a reply from the client with no data.
   After these steps, the authentication process is
   complete. The security layer to use is negotiated by SPNEGO. The
   maximum size output_token the server is able to receive is specified
   by the application protocol.

> -----Original Message-----
> From: Bill Ricker [mailto:[email-masked]]
> Sent: Thursday, February 11, 1999 3:59 PM
> To: [email-masked]; Paul Leach
> Cc: [email-masked]; [email-masked]
> Subject: GSS-SPNEGO
> 
> 
> Hi John and Paul,
> 
> We're curious about a specification for GSS-SPNEGO. Since 
> none is listed we're
> assuming that it is the GSSAPI mechanism as specified in RFC 
> 2222 using 
> SPNEGO as the underlying GSS mechanism. Is that correct? If 
> not, is there a
> specification we can get hold of.
> 
> 
> Thanks
> bill
> 
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]