Subject: Re: GS2 update
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Date: Mon, 30 Oct 2006 20:06:10 +0000
List-Id: <ietf-sasl.imc.org>

Simon Josefsson wrote:

>The first issue above should be easy to close fast if someone can
>independently compute the GS2 mech name for Kerberos V5 OIDs.  I'm
>worried about the lack of response on this matter, it would be a
>simple thing to resolve for anyone with interest in GS2.  Does it
>indicate that nobody is interested in and/or committed to GS2?
>
>  
>
I am interested, but I am somewhat busy at the moment.

Date: Wed, 25 Oct 2006 13:15:32 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re:I-D ACTION:draft-ietf-sasl-gs2-03.txt 
Sender: [email-masked]

Please review this revision to ensure issues raised during
the previous WG last call were adequately addressed.

-- Kurt

At 12:50 PM 10/25/2006, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.
>
>        Title           : Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
>        Author(s)       : S. Josefsson
>        Filename        : draft-ietf-sasl-gs2-03.txt
>        Pages           : 22
>        Date            : 2006-10-25
>        
>This document describes how to use a Generic Security Service
>   Application Program Interface (GSS-API) mechanism in the the Simple
>   Authentication and Security Layer (SASL) framework.  This is done by
>   defining a new SASL mechanism family, called GS2.  This mechanism
>   family offers a number of improvements over the previous SASL/GSS-API
>   mechanism: it is more general, uses fewer messages for the
>   authentication phase in some cases, and supports a SASL-specific
>   notion of channel binding.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-03.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>[email-masked] with the word unsubscribe in the body of 
>the message. 
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username "anonymous" and a password of your e-mail address. After 
>logging in, type "cd internet-drafts" and then 
>"get draft-ietf-sasl-gs2-03.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>        [email-masked].
>In the body type:
>        "FILE /internet-drafts/draft-ietf-sasl-gs2-03.txt".
>        
>NOTE:   The mail server at ietf.org can return the document in
>        MIME-encoded form by using the "mpack" utility.  To use this
>        feature, insert the command "ENCODING mime" before the "FILE"
>        command.  To decode the response(s), you will need "munpack" or
>        a MIME-compliant mail reader.  Different MIME-compliant mail readers
>        exhibit different behavior, especially when dealing with
>        "multipart" MIME messages (i.e. documents which have been split
>        up into multiple messages), so check your local documentation on
>        how to manipulate these messages.
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-sasl-gs2-03.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sasl-gs2-03.txt>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-gs2-03.txt 
Date: Wed, 25 Oct 2006 15:50:04 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	Author(s)	: S. Josefsson
	Filename	: draft-ietf-sasl-gs2-03.txt
	Pages		: 22
	Date		: 2006-10-25
	
This document describes how to use a Generic Security Service
   Application Program Interface (GSS-API) mechanism in the the Simple
   Authentication and Security Layer (SASL) framework.  This is done by
   defining a new SASL mechanism family, called GS2.  This mechanism
   family offers a number of improvements over the previous SASL/GSS-API
   mechanism: it is more general, uses fewer messages for the
   authentication phase in some cases, and supports a SASL-specific
   notion of channel binding.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sasl-gs2-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-gs2-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-gs2-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-gs2-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 23 Oct 2006 12:25:10 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Non-integrity GSSAPI mechanisms in GS2
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, Oct 20, 2006 at 01:56:31AM +0200, Simon Josefsson wrote:
> I'm struggling with how to support non-integrity GSSAPI mechanisms in
> GS2.  It seems to open for some undesirable complexity, although my
> lack of GSSAPI knowledge may be leading me in the wrong way.
> 
> It is not clear to me whether people wants GS2 to support 1) or 2), or
> possibly both 1) and 2), where 1) and 2) are:

(1) only.  (2) presumes interfaces that we don't have yet.  Sure, KITTEN
is working on some of those, but why wait for KITTEN?  Once the APIs
needed to support (2) come along then GS2 can be updated to explain how
to use (2).

Note also: there's no channel binding in GS2 w/o integrity protection in
the GSS mech.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 23 Oct 2006 15:44:40 +0200
Sender: [email-masked]

All:

I have submitted an updated version of GS2.  Until it shows up in the
repository, you can view it from:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-03.txt

I believe it closes all open issues, except for two that I have
requested help on before:

1) Compute Kerberos V5 mech name.

2) Support for non-integrity capable GSS mechanisms.

However, there has been many changes, and I may have missed some
suggestions.  Please consider the latest version ready to go except
for the two issues above.

The first issue above should be easy to close fast if someone can
independently compute the GS2 mech name for Kerberos V5 OIDs.  I'm
worried about the lack of response on this matter, it would be a
simple thing to resolve for anyone with interest in GS2.  Does it
indicate that nobody is interested in and/or committed to GS2?

The second might warrant more discussion.  I'd welcome text to solve
this, because I'm not sure how it should work, in particular with
regards to the integ_req flag.  Personally, I see no point in
supporting non-integrity authentication mechanisms -- it seems to
weaken GS2, so I would rather drop the feature and have those
interested in weak authentication schemes specify their own SASL
mechanism.  Further, nobody has presented a specific use-case for this
feature, so it seems to me be feature creepism.  However, text
proposals to resolve the problem is fine.

/Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Non-integrity GSSAPI mechanisms in GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 20 Oct 2006 01:56:31 +0200
Sender: [email-masked]

I'm struggling with how to support non-integrity GSSAPI mechanisms in
GS2.  It seems to open for some undesirable complexity, although my
lack of GSSAPI knowledge may be leading me in the wrong way.

It is not clear to me whether people wants GS2 to support 1) or 2), or
possibly both 1) and 2), where 1) and 2) are:

1) The client knows a-priori that the mechanism don't support
integrity, and the client uses GS2 in non-integrity mode directly
(i.e., integ_req_flag is FALSE when calling GSS_Init_sec_context).

2) The client doesn't know that the mechanism doesn't support
integrity, or the client knows that the mechanism supports integrity
but the credential may not support it, and the client attempts to
negotiate integrity (i.e., integ_req_flag is TRUE), but will
gracefully fallback to the non-integrity case when it realizes this
situation (i.e., integ_avail is FALSE when the context has been
established).

Further, is there any opinions regarding the use of, or even
requirement, of TLS for non-integrity capable GSS mechanisms?  PLAIN
and CRAM-MD5 seems comparable to a non-integrity capable GSS
mechanisms, and TLS is a MUST-option for PLAIN.

If TLS is required, there is a problem that, at least for 2), the
client may not know that the mechanism doesn't support integrity until
it has started the SASL handshake, and then it is typically too late
to enable TLS.

If there isn't convergence on this issue within the next 1-2 days (the
I-D cutoff is Monday), I'll leave non-integrity mechanisms for a later
update of the draft.

Thanks,
Simon

Nicolas Williams <[email-masked]> writes:

> On Thu, Sep 07, 2006 at 12:07:01PM -0400, Sam Hartman wrote:
>> 
>> >>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>> 
>>     Simon> Is the consensus that GS2 should support GSS-API mechanisms
>>     Simon> that doesn't offer integrity protection?
>> 
>> My opinion is yes, but that's an individual, not as an AD.
>
> Jeff Hutzelman and I worked out the implications of this off-line just
> now.
>
> If we allow use of GSS-API mechanisms that don't offer integrity
> protection then:
>
> a) GS2 has to be modified so the client sends the authzid without
>    wrapping;
>
> b) SASL applications must be able to inquire which GS2 mechanisms offer
>    integrity protection so they can avoid negotiating a mechanism that
>    cannot provide what they want;
>
> c) GSS mechs that can provide integ prot but fail to provide it for a
>    given security context are a problem -- GS2 should fail
>    authentication for such mechanisms when the security context fails to
>    provide integrity protection and either the application wanted a
>    security layer or wanted channel binding.
>
> I take no position on whether GS2 should support GSS-API mechanisms that
> cannot provide integrity protection.  Though I can probably be convinced
> that it should.
>
> Nico
> -- 

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-10.txt 
Date: Tue, 10 Oct 2006 15:50:02 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: Using Digest Authentication as a SASL Mechanism
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sasl-rfc2831bis-10.txt
	Pages		: 45
	Date		: 2006-10-10
	
This specification defines how HTTP Digest Authentication (RFC 2617)
   can be used as a Simple Authentication and Security Layer (SASL, RFC
   4422) mechanism for any protocol that has a SASL profile. It is
   intended both as an improvement over CRAM-MD5 (RFC 2195) and as a
   convenient way to support a single authentication mechanism for web,
   mail, LDAP, and other protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-10.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sasl-rfc2831bis-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-rfc2831bis-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 04 Oct 2006 13:21:38 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Originator-Info: login-token=Mulberry:01/pXrj2j9YANK4GMQMRMb/pUHIrqFyWRrChn0NBU=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, October 04, 2006 10:00:14 AM +0200 Simon Josefsson 
<[email-masked]> wrote:

>> I would change "desired" to "recommended", but otherwise this looks Ok.
>
> Since recommended is a RFC 2119 word, I've though it best to avoid
> using them when the RFC 2119 interpretation is not intended.  I think
> the sentence reads fine if "desired" is removed entirely, though, so I
> changed it into:

I agree, it reads fine if you remove "desired" entirely.  However, changing 
it to "recommended" is also fine, since the sentence in question describes 
specifically how to generated the service name RECOMMENDED (RFC2119) by the 
preceding sentence.

-- Jeff

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 04 Oct 2006 10:00:14 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

>>>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.
>>>    
>>>
>>OK.  I added the explanation for "hostname" and the reference to
>>GSS_Import_name, that were both lost, so the entire sentence now
>>reads:
>>
>>      <t>(**) - 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, and "hostname" is the fully qualified host
>>	name of the server, is RECOMMENDED.  The desired server name
>>  
>>
> I would change "desired" to "recommended", but otherwise this looks Ok.

Since recommended is a RFC 2119 word, I've though it best to avoid
using them when the RFC 2119 interpretation is not intended.  I think
the sentence reads fine if "desired" is removed entirely, though, so I
changed it into:

      <t>(**) - 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, and "hostname" is the fully qualified host
	name of the server, is RECOMMENDED.  The server name is
	generated by calling GSS_Import_name with input_name_type of
	GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
	"service@hostname".</t>

>>	is generated by calling GSS_Import_name with input_name_type
>>	of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
>>	"service@hostname".</t>
>>
>>Perhaps GS1 should have a similar update, in AUTH48 or so.
>
> I can do, if others agree.

I think it would be useful.  Right now, the definition of "hostname"
and the reference to GSS_Import_name is missing from the section that
discuss the server side.

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 04 Oct 2006 09:56:15 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Simon Josefsson wrote:
>
>>Alexey Melnikov <[email-masked]> writes:
>>  
>>
>>>>>And the text quoted above is followed by additional text which is not
>>>>>currently in GS2:
>>>>>
>>>>> Upon successful establishment of the security context and if the
>>>>> server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
>>>>> credential handle, the server SHOULD also check using the
>>>>> GSS_Inquire_context that the target_name used by the client matches:
>>>>>
>>>>> -  the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
>>>>>    where "service" is the service name specified in the application
>>>>>    protocol's profile.
>>>>>
>>>>> When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
>>>>> examines the context to ensure that it provides a level of protection
>>>>> permitted by the server's security policy.
>>>>>          
>>>>>
>>>>Thanks, I added this, but changed the SHOULD into MUST, because
>>>>otherwise it seems we open up to a mitm.
>>>>      
>>>>
>>>No, the SHOULD is here because the server could have used a specific
>>>principal during GSS_Import_Name. In such case there would be no need to
>>>do the check.
>>>    
>>>
>>The text applies only when GSS_C_NO_NAME and/or GSS_C_NO_CREDENTIAL
>>was used, and in that case I think the test is necessary.  Or Is there
>>another reason to not do the test?
>>  
>>
> A server implementation can have some external knowledge about the
> principal that will be selected when GSS_C_NO_NAME and/or
> GSS_C_NO_CREDENTIAL is used. I guess this can be interpreted as
> compliance with the SHOULD?

Yes, that makes sense.  I reverted it to SHOULD.

Thanks,
Simon

Date: Tue, 03 Oct 2006 17:14:56 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
>  
>
>>>>And the text quoted above is followed by additional text which is not
>>>>currently in GS2:
>>>>
>>>> Upon successful establishment of the security context and if the
>>>> server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
>>>> credential handle, the server SHOULD also check using the
>>>> GSS_Inquire_context that the target_name used by the client matches:
>>>>
>>>> -  the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
>>>>    where "service" is the service name specified in the application
>>>>    protocol's profile.
>>>>
>>>> When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
>>>> examines the context to ensure that it provides a level of protection
>>>> permitted by the server's security policy.
>>>>   
>>>>        
>>>>
>>>Thanks, I added this, but changed the SHOULD into MUST, because
>>>otherwise it seems we open up to a mitm.
>>>      
>>>
>>No, the SHOULD is here because the server could have used a specific
>>principal during GSS_Import_Name. In such case there would be no need to
>>do the check.
>>    
>>
>The text applies only when GSS_C_NO_NAME and/or GSS_C_NO_CREDENTIAL
>was used, and in that case I think the test is necessary.  Or Is there
>another reason to not do the test?
>  
>
A server implementation can have some external knowledge about the 
principal that will be selected when GSS_C_NO_NAME and/or 
GSS_C_NO_CREDENTIAL is used. I guess this can be interpreted as 
compliance with the SHOULD?

Date: Tue, 03 Oct 2006 16:45:15 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
>  
>
>>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.
>>    
>>
>OK.  I added the explanation for "hostname" and the reference to
>GSS_Import_name, that were both lost, so the entire sentence now
>reads:
>
>      <t>(**) - 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, and "hostname" is the fully qualified host
>	name of the server, is RECOMMENDED.  The desired server name
>  
>
I would change "desired" to "recommended", but otherwise this looks Ok.

>	is generated by calling GSS_Import_name with input_name_type
>	of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
>	"service@hostname".</t>
>
>Perhaps GS1 should have a similar update, in AUTH48 or so.
>  
>
I can do, if others agree.

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: Obtaining credentials in GSSAPI/GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 03 Oct 2006 17:16:04 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Oct 03, 2006 at 11:27:50AM +0200, Simon Josefsson wrote:
>> Simon Josefsson <[email-masked]> writes:
>> >>   Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
>> >>   or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
>> >>   GSS-API mechanism for which this SASL mechanism is registered
>> >> (*). Servers MAY use
>> >>   GSS_C_NO_CREDENTIAL as an acceptor credential handle.  Servers MAY
>> >>   use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred
>> >>   for the server's principal name(s) (**) and the
>> >>   GSS-API mechanism for which this SASL mechanism is registered.
>> >>
>> >>   (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
>> >>   GSS-API mechanism as an input parameter.  The OID set can be created
>> >>   by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member.  It can
>> >>   be freed by calling the GSS_Release_oid_set.
>> >>
>> >>   (**) - 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.
>> >>
>> >>   Upon successful establishment of the security context (i.e.
>> >>   GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
>> >>   verify that the negotiated GSS-API mechanism is indeed the registered
>> >>   one.  This is done by examining the value of the mech_type
>> >>   parameter returned from the GSS_Accept_sec_context call.  If the
>> >>   value differ SASL authentication MUST be aborted.
>> >>
>> >> (I've edited the text not to reference Kerberos)
>> >
>> > Thanks, this seems good for GS2, but I wonder about the value of this
>> > in GSSAPI.  It seems to make my RFC 2222 conforming implementation
>> > violate the first SHOULD.  I'll bring this up separately...
>> 
>> After re-reading RFC 2222, it seems that the old document was
>> under-specified in this area -- it doesn't discuss how servers should
>> obtain the credentials at all.
>
> Thus the new text in GS1.  Please copy it.

I have, with some modifications (see other posts).

>>                                 However, it may be reasonable to
>> assume that the RFC 2222 server side should be similar to the RFC 2222
>> client side, which implies using GSS_Import_name, and thus breaking
>> the SHOULD above about using GSS_C_NO_NAME.  Both Cyrus SASL and GNU
>> SASL work that way, and thus break the SHOULD above.
>
> It may seem reasonable, but it isn't useful.

Why not?  Popular implementations still do things this way.  If there
is anything wrong with that behaviour, I think it should be brought up
in the "Changes since RFC 2222" section.

>  See the archives.

Pointers would be appreciated...  Is this related to non-hostbased
names?

>> I wonder whether any existing implementations of "GSSAPI" will be
>> updated to follow the above SHOULD.  Given the deployed working base,
>> and no incentive to update GSSAPI beyond RFC 2222, I kind of doubt it.
>
> SHOULD is not MUST.

Understood, but violating a SHOULD typically require a good argument.
I don't see one here.

It seems to me that this change could potentially cause interop
problems with RFC 2222 "GSSAPI" implementations and gssapi-08 draft
"GSSAPI" implementations.  For example, it is not clear that
GSS_C_NO_NAME will lead to using the same server name as using
GSS_Acquire_cred with a server name derived by GSS_Import_name from
"service@hostname".

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 03 Oct 2006 17:06:39 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

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

OK.  I added the explanation for "hostname" and the reference to
GSS_Import_name, that were both lost, so the entire sentence now
reads:

      <t>(**) - 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, and "hostname" is the fully qualified host
	name of the server, is RECOMMENDED.  The desired server name
	is generated by calling GSS_Import_name with input_name_type
	of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
	"service@hostname".</t>

Perhaps GS1 should have a similar update, in AUTH48 or so.

/Simon

Date: Tue, 3 Oct 2006 09:34:49 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Obtaining credentials in GSSAPI/GS2 (was: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt)
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Oct 03, 2006 at 11:27:50AM +0200, Simon Josefsson wrote:
> Simon Josefsson <[email-masked]> writes:
> >>   Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
> >>   or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
> >>   GSS-API mechanism for which this SASL mechanism is registered
> >> (*). Servers MAY use
> >>   GSS_C_NO_CREDENTIAL as an acceptor credential handle.  Servers MAY
> >>   use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred
> >>   for the server's principal name(s) (**) and the
> >>   GSS-API mechanism for which this SASL mechanism is registered.
> >>
> >>   (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
> >>   GSS-API mechanism as an input parameter.  The OID set can be created
> >>   by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member.  It can
> >>   be freed by calling the GSS_Release_oid_set.
> >>
> >>   (**) - 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.
> >>
> >>   Upon successful establishment of the security context (i.e.
> >>   GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
> >>   verify that the negotiated GSS-API mechanism is indeed the registered
> >>   one.  This is done by examining the value of the mech_type
> >>   parameter returned from the GSS_Accept_sec_context call.  If the
> >>   value differ SASL authentication MUST be aborted.
> >>
> >> (I've edited the text not to reference Kerberos)
> >
> > Thanks, this seems good for GS2, but I wonder about the value of this
> > in GSSAPI.  It seems to make my RFC 2222 conforming implementation
> > violate the first SHOULD.  I'll bring this up separately...
> 
> After re-reading RFC 2222, it seems that the old document was
> under-specified in this area -- it doesn't discuss how servers should
> obtain the credentials at all.

Thus the new text in GS1.  Please copy it.

>                                 However, it may be reasonable to
> assume that the RFC 2222 server side should be similar to the RFC 2222
> client side, which implies using GSS_Import_name, and thus breaking
> the SHOULD above about using GSS_C_NO_NAME.  Both Cyrus SASL and GNU
> SASL work that way, and thus break the SHOULD above.

It may seem reasonable, but it isn't useful.  See the archives.

> I wonder whether any existing implementations of "GSSAPI" will be
> updated to follow the above SHOULD.  Given the deployed working base,
> and no incentive to update GSSAPI beyond RFC 2222, I kind of doubt it.

SHOULD is not MUST.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 03 Oct 2006 16:28:26 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

>>>>  The server passes the first client response to GSS_Accept_sec_context
>>>>      
>>>>
>>>I suggest s/first/initial, as "initial client response" is a SASL term.
>>>    
>>>
>>
>>GS2 should support a missing "initial client response", so it is
>>actually the first context token received by the server which should
>>be used.  Does this looks better?
>>
>>    <t>The server passes the first context token to
>>      GSS_Accept_sec_context as input_token, setting
>>
> Yes.
> At least "first context token" doesn't bring association with "initial
> client response".

Right.

>>>  Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
>>>  or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
>>>  GSS-API mechanism for which this SASL mechanism is registered
>>>(*). Servers MAY use
>>>  GSS_C_NO_CREDENTIAL as an acceptor credential handle.  Servers MAY
>>>  use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred
>>>  for the server's principal name(s) (**) and the
>>>  GSS-API mechanism for which this SASL mechanism is registered.
>>>
>>>  (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
>>>  GSS-API mechanism as an input parameter.  The OID set can be created
>>>  by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member.  It can
>>>  be freed by calling the GSS_Release_oid_set.
>>>
>>>  (**) - 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.
>>>
>>>  Upon successful establishment of the security context (i.e.
>>>  GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
>>>  verify that the negotiated GSS-API mechanism is indeed the registered
>>>  one.  This is done by examining the value of the mech_type
>>>  parameter returned from the GSS_Accept_sec_context call.  If the
>>>  value differ SASL authentication MUST be aborted.
>>>
>>>(I've edited the text not to reference Kerberos)
>>>    
>>
>>Thanks, this seems good for GS2, but I wonder about the value of this
>>in GSSAPI.  It seems to make my RFC 2222 conforming implementation
>>violate the first SHOULD.  I'll bring this up separately...
>>
>>In the last paragraph, I changed a SHOULD into MUST, since the last
>>MUST in that paragraph implies that the first SHOULD is followed.
>>  
>>
> Actually the second MUST is conditional on the first SHOULD. So I don't
> see why the SHOULD has to change into a MUST.
> If I remember correctly the SHOULD here is to accommodate
> implementations which only support a single GSS-API mechanism.

Ah, I see.  Makes sense.  I have reverted this.

>>>And the text quoted above is followed by additional text which is not
>>>currently in GS2:
>>>
>>>  Upon successful establishment of the security context and if the
>>>  server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
>>>  credential handle, the server SHOULD also check using the
>>>  GSS_Inquire_context that the target_name used by the client matches:
>>>
>>>  -  the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
>>>     where "service" is the service name specified in the application
>>>     protocol's profile.
>>>
>>>  When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
>>>  examines the context to ensure that it provides a level of protection
>>>  permitted by the server's security policy.
>>>    
>>
>>Thanks, I added this, but changed the SHOULD into MUST, because
>>otherwise it seems we open up to a mitm.
>
> No, the SHOULD is here because the server could have used a specific
> principal during GSS_Import_Name. In such case there would be no need to
> do the check.

The text applies only when GSS_C_NO_NAME and/or GSS_C_NO_CREDENTIAL
was used, and in that case I think the test is necessary.  Or Is there
another reason to not do the test?

>>I didn't include this part:
>>  
>>
>>> In particular, if the
>>>  integ_avail flag is not set in the context, then no security layer
>>>  can be offered or accepted.  If the conf_avail flag is not set in the
>>>  context, then no security layer with confidentiality can be offered
>>>  or accepted.
>>>    
>>>
>>
>>Because I think it interacts badly with the no-integrity cases that
>>GS2 has to support.  This should likely be revisited later on.
>
> I don't understand, can you explain?

Right now, adding the text would be incorrect because when
GSS_Accept_sec_context returns GSS_S_COMPLETE and integ_avail changed,
there is no longer any possibility to "offer" a different security
layer, if the mechanism supported PROT_READY.  The offer of a security
layer was already sent earlier.  This is one change between GSSAPI and
GS2.

I suspect there will be two cases:

1) The mechanism doesn't support integrity/confidentiality: no wrap
token is sent at all, and there is no need to check the flags.

2) The mechanism support integrity and/or confidentiality: if one
security layer was requested but it turns out later that
GSS_Accept_sec_context cannot accommodate that particular security
layer (e.g., because the credentials doesn't permit it), the
authentication fails.  (This may be sub-optimal, but I'm not sure how
to improve it, or if anyone cares.)

This relates to support non-integrity-capable GSSAPI mechanisms, a
change that I haven't incorporated yet.

>>>>4.3.2.  GSS_Wrap input for server responses
>>>>      
>>>>
>>>[...]
>>>    
>>>
>>>>  The "server_qop" field integer indicate the selected quality of
>>>>  protection.
>>>>      
>>>>
>>>I suggest to add:
>>>
>>> It must be one of the values specified by the client in
>>>"client_qops"/"client_cbqops"
>>>
>>>And similar text for "client_qop" in 4.3.4.
>>>    
>>
>>Actually, no.  I think it would be useful to be able to specify a
>>different value, if you can't support any of the proposed values.  It
>>is then up to the other side to reject the selection or not.
>
> I suggest you document this, as this differs from GS1.

Good idea, I have added to section 9:

  <t>The "client_qop" and "server_qop" will contains the chosen
    security layer.</t>

  <t>Note that "client_qop" and "server_qop" MAY indicate a quality of
    protection that was not offered by the server and client,
    respectively.  This SHOULD only be used when the server or client
    (respectively) would otherwise fail the entire authentication
    exchange.  The server/client that receives a "client_qop"/
    "server_qop" MUST verify that it corresponds to an acceptable
    security level.</t>

The updated document is available from:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt

with diff against -02:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--02.diff.html

Thanks,
Simon

Date: Tue, 03 Oct 2006 15:09:11 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

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.

Date: Tue, 03 Oct 2006 14:53:56 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

Simon Josefsson wrote:

>>>4.1.  SASL Tokens
>>>
>>>  All top-level SASL packets for the GS2 mechanism family follow the
>>>  following format:
>>>      
>>>
>>I would suggest avoid using the term SASL packet, as it usually refers to
>>SASL security layer. Something like "SASL authentication exchange packets"
>>would be better here.
>>    
>>
>
>RFC 4422 seems to use the term "messages" here, so I changed this
>into:
>
><section title="SASL Authentication Exchange Message Format">
>
>  <section title="SASL Messages">
>
>    <t>All top-level SASL authentication exchange messages for the GS2
>      mechanism family follow the following format:</t>
>  
>
Looks good to me.
[...]

>>>  The server passes the first client response to GSS_Accept_sec_context
>>>      
>>>
>>I suggest s/first/initial, as "initial client response" is a SASL term.
>>    
>>
>
>GS2 should support a missing "initial client response", so it is
>actually the first context token received by the server which should
>be used.  Does this looks better?
>
>    <t>The server passes the first context token to
>      GSS_Accept_sec_context as input_token, setting
>
Yes.
At least "first context token" doesn't bring association with "initial
client response".

>>>the chan_binding set to NULL, and acceptor_cred_handle
>>>  equal to output_cred_handle from GSS_Acquire_cred called with
>>>  desired_name equal to output_name from GSS_Import_name 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 text about acceptor_cred_handle got replaced with the following in GS1:
>>
>>  and a suitable acceptor_cred_handle (see below).
>>
>>and later:
>>
>>  Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
>>  or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
>>  GSS-API mechanism for which this SASL mechanism is registered
>>(*). Servers MAY use
>>  GSS_C_NO_CREDENTIAL as an acceptor credential handle.  Servers MAY
>>  use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred
>>  for the server's principal name(s) (**) and the
>>  GSS-API mechanism for which this SASL mechanism is registered.
>>
>>  (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
>>  GSS-API mechanism as an input parameter.  The OID set can be created
>>  by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member.  It can
>>  be freed by calling the GSS_Release_oid_set.
>>
>>  (**) - 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.
>>
>>  Upon successful establishment of the security context (i.e.
>>  GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
>>  verify that the negotiated GSS-API mechanism is indeed the registered
>>  one.  This is done by examining the value of the mech_type
>>  parameter returned from the GSS_Accept_sec_context call.  If the
>>  value differ SASL authentication MUST be aborted.
>>
>>(I've edited the text not to reference Kerberos)
>>    
>
>Thanks, this seems good for GS2, but I wonder about the value of this
>in GSSAPI.  It seems to make my RFC 2222 conforming implementation
>violate the first SHOULD.  I'll bring this up separately...
>
>In the last paragraph, I changed a SHOULD into MUST, since the last
>MUST in that paragraph implies that the first SHOULD is followed.
>  
>
Actually the second MUST is conditional on the first SHOULD. So I don't
see why the SHOULD has to change into a MUST.
If I remember correctly the SHOULD here is to accommodate
implementations which only support a single GSS-API mechanism.

>>And the text quoted above is followed by additional text which is not
>>currently in GS2:
>>
>>  Upon successful establishment of the security context and if the
>>  server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
>>  credential handle, the server SHOULD also check using the
>>  GSS_Inquire_context that the target_name used by the client matches:
>>
>>  -  the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
>>     where "service" is the service name specified in the application
>>     protocol's profile.
>>
>>  When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
>>  examines the context to ensure that it provides a level of protection
>>  permitted by the server's security policy.
>>    
>
>Thanks, I added this, but changed the SHOULD into MUST, because
>otherwise it seems we open up to a mitm.

No, the SHOULD is here because the server could have used a specific
principal during GSS_Import_Name. In such case there would be no need to
do the check.

>I didn't include this part:
>  
>
>> In particular, if the
>>  integ_avail flag is not set in the context, then no security layer
>>  can be offered or accepted.  If the conf_avail flag is not set in the
>>  context, then no security layer with confidentiality can be offered
>>  or accepted.
>>    
>>
>
>Because I think it interacts badly with the no-integrity cases that
>GS2 has to support.  This should likely be revisited later on.

I don't understand, can you explain?
[...]

>>>  bitmask and local policy.
>>>      
>>>
>>>  Four input formats to the GSS_Wrap function are defined.
>>>      
>>>
>>This is confusing. Maybe "two pairs of input formats"?  
>>
>
>I changed it to:
>
>    <t>Two pairs of input formats to the GSS_Wrap function are
>      defined.  The first pair is used when the client sends the
>      GSS_Wrap token first and the server responds.  The other pair is
>      used when the server sends the GSS_Wrap token first and the
>      client responds.</t>

Looks good.
[...]

>>>4.3.2.  GSS_Wrap input for server responses
>>>      
>>>
>>[...]
>>    
>>
>>>  The "server_qop" field integer indicate the selected quality of
>>>  protection.
>>>      
>>>
>>I suggest to add:
>>
>> It must be one of the values specified by the client in
>>"client_qops"/"client_cbqops"
>>
>>And similar text for "client_qop" in 4.3.4.
>>    
>
>Actually, no.  I think it would be useful to be able to specify a
>different value, if you can't support any of the proposed values.  It
>is then up to the other side to reject the selection or not.

I suggest you document this, as this differs from GS1.

>The messages is integrity protected, so there is no downgrade attack,
>that I can see.

Alexey

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Obtaining credentials in GSSAPI/GS2 (was: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 03 Oct 2006 11:27:50 +0200
Sender: [email-masked]

Simon Josefsson <[email-masked]> writes:

>>   Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
>>   or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
>>   GSS-API mechanism for which this SASL mechanism is registered
>> (*). Servers MAY use
>>   GSS_C_NO_CREDENTIAL as an acceptor credential handle.  Servers MAY
>>   use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred
>>   for the server's principal name(s) (**) and the
>>   GSS-API mechanism for which this SASL mechanism is registered.
>>
>>   (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
>>   GSS-API mechanism as an input parameter.  The OID set can be created
>>   by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member.  It can
>>   be freed by calling the GSS_Release_oid_set.
>>
>>   (**) - 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.
>>
>>   Upon successful establishment of the security context (i.e.
>>   GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
>>   verify that the negotiated GSS-API mechanism is indeed the registered
>>   one.  This is done by examining the value of the mech_type
>>   parameter returned from the GSS_Accept_sec_context call.  If the
>>   value differ SASL authentication MUST be aborted.
>>
>> (I've edited the text not to reference Kerberos)
>
> Thanks, this seems good for GS2, but I wonder about the value of this
> in GSSAPI.  It seems to make my RFC 2222 conforming implementation
> violate the first SHOULD.  I'll bring this up separately...

After re-reading RFC 2222, it seems that the old document was
under-specified in this area -- it doesn't discuss how servers should
obtain the credentials at all.  However, it may be reasonable to
assume that the RFC 2222 server side should be similar to the RFC 2222
client side, which implies using GSS_Import_name, and thus breaking
the SHOULD above about using GSS_C_NO_NAME.  Both Cyrus SASL and GNU
SASL work that way, and thus break the SHOULD above.

I wonder whether any existing implementations of "GSSAPI" will be
updated to follow the above SHOULD.  Given the deployed working base,
and no incentive to update GSSAPI beyond RFC 2222, I kind of doubt it.

/Simon

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 03 Oct 2006 10:54:30 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Sep 13, 2006 at 05:08:38PM -0400, Sam Hartman wrote:
>> Hmm.  Do you want to actually length count everything in both teh
>> client and server messages so you can have extensibility in the
>> future?
>
> Good point.  I think all that would be required would be to add a length
> of authzid field to the wrap token data, and standard MUST NOT send/MUST
> ignore text.

I agree.

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 03 Oct 2006 10:51:21 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> My review comments are below. Some of them you probably already
> addressed and some of them are nitpicking.

Thanks for your detailed review!  I'm sorry it took so long to
respond.

>>4.1.  SASL Tokens
>>
>>   All top-level SASL packets for the GS2 mechanism family follow the
>>   following format:
>
> I would suggest avoid using the term SASL packet, as it usually refers to
> SASL security layer. Something like "SASL authentication exchange packets"
> would be better here.

RFC 4422 seems to use the term "messages" here, so I changed this
into:

<section title="SASL Authentication Exchange Message Format">

  <section title="SASL Messages">

    <t>All top-level SASL authentication exchange messages for the GS2
      mechanism family follow the following format:</t>

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

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

>>   If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
>>   expect the server to issue a token in a subsequent challenge or as
>>   additional information to the outcome of the authentication.
>
> I suggest adding before this sentence (as in GS1):
>
>   The client then responds with the resulting output_token.
>
> otherwise it is not clear what happens to the generated token.

Good idea, added.

>>   The server passes the first client response to GSS_Accept_sec_context
>
> I suggest s/first/initial, as "initial client response" is a SASL term.

GS2 should support a missing "initial client response", so it is
actually the first context token received by the server which should
be used.  Does this looks better?

    <t>The server passes the first context token to
      GSS_Accept_sec_context as input_token, setting

>>   as input_token, setting input_context_handle to 0 (initially),
>>   mech_type of the GSSAPI mechanism for which this SASL mechanism is
>>   registered,
>
> Delete description of the mech_type parameter, as it is an output parameter
> of GSS_Accept_sec_context.

Oops!  Good catch.  Fixed.

>> the chan_binding set to NULL, and acceptor_cred_handle
>>   equal to output_cred_handle from GSS_Acquire_cred called with
>>   desired_name equal to output_name from GSS_Import_name 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 text about acceptor_cred_handle got replaced with the following in GS1:
>
>   and a suitable acceptor_cred_handle (see below).
>
> and later:
>
>   Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
>   or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
>   GSS-API mechanism for which this SASL mechanism is registered
> (*). Servers MAY use
>   GSS_C_NO_CREDENTIAL as an acceptor credential handle.  Servers MAY
>   use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred
>   for the server's principal name(s) (**) and the
>   GSS-API mechanism for which this SASL mechanism is registered.
>
>   (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
>   GSS-API mechanism as an input parameter.  The OID set can be created
>   by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member.  It can
>   be freed by calling the GSS_Release_oid_set.
>
>   (**) - 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.
>
>   Upon successful establishment of the security context (i.e.
>   GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
>   verify that the negotiated GSS-API mechanism is indeed the registered
>   one.  This is done by examining the value of the mech_type
>   parameter returned from the GSS_Accept_sec_context call.  If the
>   value differ SASL authentication MUST be aborted.
>
> (I've edited the text not to reference Kerberos)

Thanks, this seems good for GS2, but I wonder about the value of this
in GSSAPI.  It seems to make my RFC 2222 conforming implementation
violate the first SHOULD.  I'll bring this up separately...

In the last paragraph, I changed a SHOULD into MUST, since the last
MUST in that paragraph implies that the first SHOULD is followed.

> And the text quoted above is followed by additional text which is not
> currently in GS2:
>
>   Upon successful establishment of the security context and if the
>   server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
>   credential handle, the server SHOULD also check using the
>   GSS_Inquire_context that the target_name used by the client matches:
>
>   -  the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
>      where "service" is the service name specified in the application
>      protocol's profile.
>
>   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
>   examines the context to ensure that it provides a level of protection
>   permitted by the server's security policy.

Thanks, I added this, but changed the SHOULD into MUST, because
otherwise it seems we open up to a mitm.

I didn't include this part:

>  In particular, if the
>   integ_avail flag is not set in the context, then no security layer
>   can be offered or accepted.  If the conf_avail flag is not set in the
>   context, then no security layer with confidentiality can be offered
>   or accepted.

Because I think it interacts badly with the no-integrity cases that
GS2 has to support.  This should likely be revisited later on.

>>4.3.  Wrap Token
>
> [...]
>>   The entity that sends its first Wrap token will have to specify a
>>   bitmap of supported and preferred quality of protection schemes.  The
>>   entity that reply to the Wrap tokens will pick a scheme, based on the
>
> typo: replies

Thanks.

>>   bitmask and local policy.
>
>>   Four input formats to the GSS_Wrap function are defined.
>
> This is confusing. Maybe "two pairs of input formats"?

I changed it to:

    <t>Two pairs of input formats to the GSS_Wrap function are
      defined.  The first pair is used when the client sends the
      GSS_Wrap token first and the server responds.  The other pair is
      used when the server sends the GSS_Wrap token first and the
      client responds.</t>

>>  The first
>>   two input formats are used when the client sends the GSS_Wrap token
>>   first and the server reponds.  The other two input formats are used
>
> typo: responds

Thanks.

>>   when the server sends the GSS_Wrap token first and the client
>>   responds.
>
>>4.3.1.  GSS_Wrap input for client requests
>
> Here and in other 4.3.* sections: using SASL terms, the client sends
> "responses", while the server sends "challenges".
>
> [...]

I tried to use different terms here.  It is somewhat problematic,
because we are talking about requests and responses on a different
level than in SASL terms.

>>   The "client_maxbuf" field indicate the maximum protected buffer size
>
> ... in network byte order
>
>>   the client can receive.

Good catch, added.

>>4.3.2.  GSS_Wrap input for server responses
>
> [...]
>>   The "server_qop" field integer indicate the selected quality of
>>   protection.
>
> I suggest to add:
>
>  It must be one of the values specified by the client in
> "client_qops"/"client_cbqops"
>
> And similar text for "client_qop" in 4.3.4.

Actually, no.  I think it would be useful to be able to specify a
different value, if you can't support any of the proposed values.  It
is then up to the other side to reject the selection or not.

The messages is integrity protected, so there is no downgrade attack,
that I can see.

>>5.  Channel Bindings
>>
>>   The GS2 mechanism provide its own channel binding mechanism, instead
>>   of using the "chan_binding" parameter in the GSS-API context
>>   functions.  The reason for this is that the GS2 mechanism provide an
>>   option to proceed even if the channel bindings does not match.  The
>>   GSS-API framework specifies that authentication cannot proceed if
>>   channel bindings does not match.
>
> typo: do not

Thanks.

>>   Client and servers MUST set the "chan_binding" parameter in the calls
>>   to GSS_Init_sec_context to GSS_Accept_sec_context, respectively, to
>
> missing word "and"?

Yup, I replaced the second "to" to "and".

>>   NULL.
>
>>6.  Protocol Overview
>
> [...]
>
>>   Because GSS-API authentication is initiated by the client, the length
>>   field will be 0 in the initial token from the server to the client
>>   when the protocol profile do not support additional information to be
>
> typo: does not

Thanks.

>>   sent together with the authentication request.
>
>
> You might want to add the following to section 9:
>
>   When decoding any received data with GSS_Unwrap the major_status
>   other than the GSS_S_COMPLETE MUST be treated as a fatal error.

Added.

>>9.1.  Examples
>
> [...]
>
>>   When integrity is negotiated the octet will encode an integer 4 as
>
> I think you meant "confidentiality" here.
>
>>   follows.
>>
>>       0 1 2 3 4 5 6 7
>>      +-+-+-+-+-+-+-+-+
>>      |0|0|0|0|0|0|1|1|
>>      +-+-+-+-+-+-+-+-+
>
> And the example doesn't match the description above, it shows the
> value 3 (no layer + integrity)

Right, the example was wrong, I've changed it.

>>12.  IANA Considerations
>>
>>   The IANA is advised that SASL mechanism names starting with "GS2-"
>>   are reserved for SASL mechanisms which conform to this document.  The
>>   IANA is directed to place a statement to that effect in the sasl-
>>   mechanisms registry.
>>
>>     Subject: Registration of SASL mechanism GS2-*
>>     Family of SASL mechanisms: YES
>
> I think Kurt took out this line from the IANA registration template in
> RFC 4422.

Removed, thanks.

/Simon