Re: WG Last Call: draft-ietf-sasl-gs2-02.txt

[Alexey Melnikov <alexey.melnikov@xxxxxxxxx>]

Simon Josefsson wrote:

> > > 4.2.  Context Token
> > [...]
> >    
> > >  The client calls GSS_Init_sec_context, passing in
> > >  input_context_handle of 0 (initially), mech_type of the GSSAPI
> > >  mechanism for which this SASL mechanism is registered, the
> > >  chan_binding is set to NULL, and 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
> > The GS1 has the note marker (*) after the "GSS_C_NT_HOSTBASED_SERVICE",
> > the note reads:
> >
> >  (*) - Clients MAY use name types other than
> >  GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but
> >  only when they have a priori knowledge that the servers support
> >  alternate name types.  Otherwise clients MUST use
> >  GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names.
> >
> > This is to address recent Nico's proposal to allow for domain based names.
> I've added this.
>
> Is something similar needed for the server side too?

I thinks something like (from GS1) is sufficient:

  (**) - Use of server's principal names having
  GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
  where "service" is the service name specified in the protocol's
  profile, is RECOMMENDED.

So basically this allows for other name types.

> > [...]
> >    
> > >  If the client will be requesting a security
> > >  layer, it MUST also supply to the GSS_Init_sec_context a
> > >  mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
> > >  integ_req_flag of TRUE.  If the client will be requesting a security
> > >  layer providing confidentiality protection, it MUST also supply to
> > >  the GSS_Init_sec_context a conf_req_flag of TRUE.
> > >      
> > This text got replaced with the following in GS1:
> >
> >  When calling the GSS_Init_sec_context the client
> >  MUST pass the integ_req_flag of TRUE.  If the client will be
> >  requesting a security layer, it MUST also supply to the
> >  GSS_Init_sec_context a mutual_req_flag of TRUE, and a
> >  sequence_req_flag of TRUE.  If the client will be requesting a
> >  security layer providing confidentiality protection, it MUST also
> >  supply to the GSS_Init_sec_context a conf_req_flag of TRUE.    
> Thanks, I had already made that change.  I had also added:
>
>      The client MUST
>      verify that the requested flags become enabled in the
>      context.
>
> Because, if I understand correctly, setting the flags does not
> necessarily mean that they will be set, so the client has to check
> that they were indeed enabled.

That seems reasonable.