Subject: Re: I-D ACTION:draft-ietf-sasl-gssapi-05.txt
From: "Kurt D. Zeilenga" <[email-masked]>
To: [email-masked]
Date: Wed, 31 May 2006 18:48:47 -0700
List-Id: <ietf-sasl.imc.org>

Please review this revision to ensure issues raised
during the recent WG Last Call are adequately addressed.

It is my intent to soon recommend this revision ("as is"
or with minor changes) to the IESG for consideration
as a Standard Track (Proposed Standard) RFC obsoleting
RFC 2222.

Thanks, Kurt

At 12:50 PM 5/31/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           : The Kerberos V5 ("GSSAPI") SASL mechanism
>        Author(s)       : A. Melnikov
>        Filename        : draft-ietf-sasl-gssapi-05.txt
>        Pages           : 10
>        Date            : 2006-5-31
>        
>The Simple Authentication and Security Layer (SASL, RFC XXXX) is a
>framework for adding authentication support to connection-based
>protocols.  This document describes the method for using the Generic
>Security Service Application Program Interface (GSS-API) KERBEROS V5
>in the Simple Authentication and Security Layer.
>
>This document replaces section 7.2 of RFC 2222, the definition of the
>"GSSAPI" SASL mechanism.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-05.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-gssapi-05.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-gssapi-05.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-gssapi-05.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-05.txt>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-gssapi-05.txt 
Date: Wed, 31 May 2006 15:50:01 -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		: The Kerberos V5 ("GSSAPI") SASL mechanism
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sasl-gssapi-05.txt
	Pages		: 10
	Date		: 2006-5-31
	
The Simple Authentication and Security Layer (SASL, RFC XXXX) is a
framework for adding authentication support to connection-based
protocols.  This document describes the method for using the Generic
Security Service Application Program Interface (GSS-API) KERBEROS V5
in the Simple Authentication and Security Layer.

This document replaces section 7.2 of RFC 2222, the definition of the
"GSSAPI" SASL mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-05.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-gssapi-05.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-gssapi-05.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-gssapi-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 18 May 2006 08:30:18 -0700
To: "Paco Martinez Rodriguez" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Problem testsaslauthd
Cc: <[email-masked]>
Sender: [email-masked]

This list is for discussions regarding the standardization of
SASL and work of the IETF SASL working group.  Questions
(and answers) regarding the use of any particular SASL
implementation should be directed appropriate support forums
for that implementation.  For Cyrus SASL, that forum would be
the <[email-masked]> list (to subscribe, send
"subscribe cyrus-sasl" to <[email-masked]>).

Regards, Kurt (SASL WG co-chair)

At 04:31 AM 5/18/2006, Paco Martinez Rodriguez wrote:

>Hi
>
>My Server has installed postfix+sasl+winbindd+samba with SuSE 10.0
>
>I have problems executing “testsaslauthd –u USER –p PASS –s smtp”. 
>
>Output is  0: NO "authentication failed"
>
>In sasl log files appears 
>
>DEBUG: auth_pam: pam_acct_mgmt failed: Permission denied
>
>May 18 12:57:06 saslauthd[31381]: do_auth         : auth failure: [user=USER] [service=smtp] [realm=] [mech=pam] [reason=PAM acct error]
>
>However in winbind log appears:
>
>Verify  user `USER`
>
>User ‘USER’ granted access
>
>Wbinfo –u, wbinfo –g, wbinfo –t executes ok
>
>File /etc/pam.d/smtp is
>
>auth      sufficient     /lib/security/pam_winbind.so debug
>
>account   sufficient     /lib/security/pam_winbind.so debug
>
>File /etc/sysconfig/saslauthd is
>
>SASLAUTHD_AUTHMECH="pam”
>
>SASLAUTHD_FLAGS="-d -V -n0"
>
>And /etc/samba/smb.conf is
>
>[global]
>
>        workgroup = GROUP 
>
>        winbind separator = _
>
>        idmap uid = 10000-20000
>
>        idmap gid = 10000-20000
>
>        winbind enum users = yes
>
>        winbind enum groups = yes
>
>        password server = 192.168.1.1
>
>        realm = 192.168.1.1
>
>        interfaces = eth1
>
>        auth methods = winbind
>
>        template shell = /bin/false
>
>        winbind use default domain = yes
>
>        encrypt passwords = Yes
>
>        wins server = 192.168.1.1
>
>Thanks !!

Content-class: urn:content-classes:message
Subject: Problem testsaslauthd
Date: Thu, 18 May 2006 13:31:17 +0200
From: "Paco Martinez Rodriguez" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C67A6E.943C2815
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi

My Server has installed postfix+sasl+winbindd+samba with SuSE 10.0

I have problems executing "testsaslauthd -u USER -p PASS -s smtp".=20
Output is  0: NO "authentication failed"

In sasl log files appears=20

DEBUG: auth_pam: pam_acct_mgmt failed: Permission denied
May 18 12:57:06 saslauthd[31381]: do_auth         : auth failure:
[user=3DUSER] [service=3Dsmtp] [realm=3D] [mech=3Dpam] [reason=3DPAM =
acct error]

However in winbind log appears:
Verify  user `USER`
User 'USER' granted access

Wbinfo -u, wbinfo -g, wbinfo -t executes ok

File /etc/pam.d/smtp is

auth      sufficient     /lib/security/pam_winbind.so debug
account   sufficient     /lib/security/pam_winbind.so debug

File /etc/sysconfig/saslauthd is

SASLAUTHD_AUTHMECH=3D"pam"
SASLAUTHD_FLAGS=3D"-d -V -n0"

And /etc/samba/smb.conf is

[global]
        workgroup =3D GROUP=20
        winbind separator =3D _
        idmap uid =3D 10000-20000
        idmap gid =3D 10000-20000
        winbind enum users =3D yes
        winbind enum groups =3D yes
        password server =3D 192.168.1.1
        realm =3D 192.168.1.1
        interfaces =3D eth1
        auth methods =3D winbind
        template shell =3D /bin/false
        winbind use default domain =3D yes
        encrypt passwords =3D Yes
        wins server =3D 192.168.1.1

Thanks !!

------_=_NextPart_001_01C67A6E.943C2815
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7638.1">
<TITLE>Problem testsaslauthd</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">Hi</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">My</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"> <FONT FACE=3D"Arial">Server</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"><FONT FACE=3D"Arial"> has installed =
postfix+sasl+winbindd+samba</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial"> with SuSE 10.0</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT FACE=3D"Arial">I have problems =
executing</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN LANG=3D"es"> <FONT =
FACE=3D"Arial">&#8220;</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial">testsaslauthd</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"> <FONT =
FACE=3D"Arial">&#8211;</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial">u</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"> <FONT =
FACE=3D"Arial">USER</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial"></FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"> <FONT =
FACE=3D"Arial">&#8211;</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial">p</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"> <FONT =
FACE=3D"Arial">PASS</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial"></FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"> <FONT =
FACE=3D"Arial">&#8211;</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial">s smtp</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&#8221;</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial">.</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"> </SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT FACE=3D"Arial">Output =
is&nbsp;</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN LANG=3D"es"> <FONT =
FACE=3D"Arial">0: NO &quot;authentication =
failed&quot;</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT FACE=3D"Arial">In sasl log files =
appears</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN LANG=3D"es"> =
</SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT FACE=3D"Arial">DEBUG: auth_pam: =
pam_acct_mgmt failed: Permission denied</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT FACE=3D"Arial">May 18 12:57:06 =
saslauthd[31381]: =
do_auth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : auth failure: =
[user=3D</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">USER</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial">] [service=3Dsmtp] [realm=3D] =
[mech=3Dpam] [reason=3DPAM acct error]</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT FACE=3D"Arial">However in =
winbind log appears</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial">:</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT FACE=3D"Arial">Verify&nbsp; user =
`USER`</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">User</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"> <FONT FACE=3D"Arial">&#8216;</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">USER</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial">&#8217;</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"><FONT FACE=3D"Arial"> granted =
access</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">Wbinfo</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"> <FONT FACE=3D"Arial">&#8211;</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"><FONT FACE=3D"Arial">u, =
wbinfo</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN LANG=3D"es"> <FONT =
FACE=3D"Arial">&#8211;</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial">g, wbinfo</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"> <FONT =
FACE=3D"Arial">&#8211;</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial">t</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"> <FONT =
FACE=3D"Arial">e</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial">x</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">ecutes</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial"> ok</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT FACE=3D"Arial">File =
/etc/pam.d/smtp is</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">auth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sufficient&nbsp;&nbsp;&nbsp;&nbsp; /lib/security/pam_winbind.so =
debug</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">account&nbsp;&nbsp; sufficient&nbsp;&nbsp;&nbsp;&nbsp; =
/lib/security/pam_winbind.so debug</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT FACE=3D"Arial">File =
/etc/sysconfig/saslauthd is</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">SASLAUTHD_AUTHMECH=3D&quot;pam</FONT></SPAN><SPAN =
LANG=3D"es"></SPAN><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&#8221;</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">SASLAUTHD_FLAGS=3D&quot;-d -V =
-n0&quot;</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT FACE=3D"Arial">And =
/etc/samba/smb.conf is</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">[global]</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; workgroup =
=3D</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN LANG=3D"es"> <FONT =
FACE=3D"Arial">GROUP</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"><FONT FACE=3D"Arial"> </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es">&nbsp;<FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; winbind separator =
=3D _</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; idmap uid =3D =
10000-20000</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; idmap gid =3D =
10000-20000</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; winbind enum =
users =3D yes</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; winbind enum =
groups =3D yes</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; password =
server =3D 192.168.1.1</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; realm =3D =
192.168.1.1</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interfaces =3D =
eth1</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auth methods =
=3D winbind</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; template shell =
=3D /bin/false</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; winbind use =
default domain =3D yes</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es">&nbsp;<FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; encrypt passwords =
=3D Yes</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; wins server =
=3D 192.168.1.1</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN =
LANG=3D"es"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"es"><FONT FACE=3D"Arial">Thanks =
!!</FONT></SPAN><SPAN LANG=3D"es"></SPAN><SPAN LANG=3D"es"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C67A6E.943C2815--

Date: Mon, 15 May 2006 16:23:40 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, May 15, 2006 at 05:12:44PM -0400, Jeffrey Hutzelman wrote:
> I'm not talking about GSS mech implementors.  I'm talking about 
> implementors of the sasl-gssapi spec which requires that servers check the 
> target_name against "the fully qualified host names of the server".

D'oh.  Yeah...

In general it should suffice to check the service name.

That this is so difficult to do is another reason to want extended
GSS-API naming APIs...

Nico
-- 

Date: Mon, 15 May 2006 17:12:44 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Chris Newman <[email-masked]>, [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Originator-Info: login-token=Mulberry:01E6l0pn0R6Rpf9OwnRiekFaobq9Ga3e2AHqILSSk=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, May 15, 2006 04:00:25 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> On Mon, May 15, 2006 at 04:45:56PM -0400, Jeffrey Hutzelman wrote:
>>
>>
>> On Monday, May 15, 2006 09:17:27 AM -0500 Nicolas Williams
>> <[email-masked]> wrote:
>>
>> >> *  The server MUST check using the GSS_Inquire_context that the
>> >> target_name specified by the client matches GSS_C_NT_HOSTBASED_SERVICE
>> >> "service@hostname"
>> >> where "service" is the service name specified in the protocol's
>> >> profile, and "hostname" is one
>> >> of the fully qualified host names of the server.
>> >
>> > You don't want to add this text.
>> >
>> > The reason is that GSS_Display_name(), which you'd have to use to check
>> > this, is lame and can display names in mechanism-specific syntax,
>> > (e.g., krb5 "unparsed" princ name syntax), which means that checking
>> > for "service@hostname" can't quite be done the simple way.
>>
>> Also because some implementor will decide this means one of:
>>
>> - The hostname returned by gethostname()
>> - The hostnames returned by gethostbyaddr() or getnameinfo() on the
>>  IP addresses attached to one or all of the host's interfces.n
>>
>> Neither of which is right if the machine is named mail-fe1.example.org
>> and  the user is trying to connect to a service like [email-masked] or
>> even  [email-masked].
>
> I hope not, at least for the krb5 mech, or any mechanism which
> internally uses a hostname to represent the hostname part of
> GSS_C_NT_HOSTBASED_SERVICE names.  I guess some mechanisms might
> internally use IP addresses or some transformation of hostnames, but
> gosh, why?[0]

I'm not talking about GSS mech implementors.  I'm talking about 
implementors of the sasl-gssapi spec which requires that servers check the 
target_name against "the fully qualified host names of the server".

-- Jeff

Date: Mon, 15 May 2006 16:00:25 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, May 15, 2006 at 04:45:56PM -0400, Jeffrey Hutzelman wrote:
> 
> 
> On Monday, May 15, 2006 09:17:27 AM -0500 Nicolas Williams 
> <[email-masked]> wrote:
> 
> >>*  The server MUST check using the GSS_Inquire_context that the
> >>target_name specified by the client matches GSS_C_NT_HOSTBASED_SERVICE
> >>"service@hostname"
> >> where "service" is the service name specified in the protocol's
> >>profile, and "hostname" is one
> >> of the fully qualified host names of the server.
> >
> >You don't want to add this text.
> >
> >The reason is that GSS_Display_name(), which you'd have to use to check
> >this, is lame and can display names in mechanism-specific syntax, (e.g.,
> >krb5 "unparsed" princ name syntax), which means that checking for
> >"service@hostname" can't quite be done the simple way.
> 
> Also because some implementor will decide this means one of:
> 
> - The hostname returned by gethostname()
> - The hostnames returned by gethostbyaddr() or getnameinfo() on the
>  IP addresses attached to one or all of the host's interfces.n
> 
> Neither of which is right if the machine is named mail-fe1.example.org and 
> the user is trying to connect to a service like [email-masked] or even 
> [email-masked].

I hope not, at least for the krb5 mech, or any mechanism which
internally uses a hostname to represent the hostname part of
GSS_C_NT_HOSTBASED_SERVICE names.  I guess some mechanisms might
internally use IP addresses or some transformation of hostnames, but
gosh, why?[0]

Let's just say that when we specify the replacement for
GSS_Display_name() we would require that if the requested name type is
GSS_C_NT_HOSTBASED_SERVICE and the given MN[1] can be displayed in the
generic syntax of GSS_C_NT_HOSTBASED_SERVICE, then the hostname must be
taken from the MN as is where possible.

[0] That's rhetorical, I think I can imagine something legit here, I
    just don't want to delve into that in this thread.  So, point taken.

[1] MN == mechanism name, but is not type-wise distinguishable from a
    normal GSS-API NAME object (gss_name_t) -- it is the output of
    GSS_Canonicalize_name(), GSS_Accept_sec_context(),
    GSS_Inquire_context(), and, when importing an exported name,
    GSS_Import_name().

    See RFC2743.

Nico
-- 

Date: Mon, 15 May 2006 16:45:56 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: Chris Newman <[email-masked]>, [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Originator-Info: login-token=Mulberry:011H3ymD7lZwwgyGoZB/siB2vvKcNbsWtB8iD9Cv0=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, May 15, 2006 09:17:27 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> *  The server MUST check using the GSS_Inquire_context that the
>> target_name specified by the client matches GSS_C_NT_HOSTBASED_SERVICE
>> "service@hostname"
>>  where "service" is the service name specified in the protocol's
>> profile, and "hostname" is one
>>  of the fully qualified host names of the server.
>
> You don't want to add this text.
>
> The reason is that GSS_Display_name(), which you'd have to use to check
> this, is lame and can display names in mechanism-specific syntax, (e.g.,
> krb5 "unparsed" princ name syntax), which means that checking for
> "service@hostname" can't quite be done the simple way.

Also because some implementor will decide this means one of:

- The hostname returned by gethostname()
- The hostnames returned by gethostbyaddr() or getnameinfo() on the
  IP addresses attached to one or all of the host's interfces.n

Neither of which is right if the machine is named mail-fe1.example.org and 
the user is trying to connect to a service like [email-masked] or even 
[email-masked].

-- Jeff

Date: Mon, 15 May 2006 09:37:08 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, May 15, 2006 at 09:17:27AM -0500, Nicolas Williams wrote:
> > As per Nico's comment it is possible to use gss_inquire_context to 
> > determine the target acceptor name as used by the client.
> > I will add some text regarding this, something like the following:*
> > 
> > *  The server MUST check using the GSS_Inquire_context that the target_name
> >  specified by the client matches GSS_C_NT_HOSTBASED_SERVICE 
> > "service@hostname"
> >  where "service" is the service name specified in the protocol's 
> > profile, and "hostname" is one
> >  of the fully qualified host names of the server.
> 
> You don't want to add this text.

OTOH, since this is a single mechanism use of the GSS-API it should be
fine to say something like this (based on your text:

   The server SHOULD check using the GSS_Inquire_context that the
   target_name used by the client matches either:
   
    - the GSS_C_NT_HOSTBASED_SERVICE "<service>@<hostname>" name syntax,
      with <service> being the service specified in the application
      protocol's profile,

   or that the 

    - the GSS_KRB5_NT_PRINCIPAL_NAME [RFC1964] name syntax for a
      two-component principal where the first component matches the
      service specified in the application protocol's profile.

Nico
-- 

Date: Mon, 15 May 2006 09:17:27 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sun, May 14, 2006 at 06:38:20PM +0100, Alexey Melnikov wrote:
> Chris Newman wrote:
> >Many modern servers have multiple fully qualified host names.  In a 
> >high availability (HA) environment, there may be a direct host name 
> >and a shared host name (to distinguish the two nodes in the HA 
> >cluster).  And a multi-homed server may listen on multiple TCP/IP 
> >interfaces, each of which may have one or more host names.
> 
> I've included text as proposed by Nico after applying some minor 
> editorial changes:
> 
>  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 Kerberos V5 GSS-API mechanism [KRB5GSS] (*).
>  Servers MAY use GSS_C_NO_CREDENTIAL as an acceptor credential handle,
>  and SHOULD check that the mech_type of the security context, upon full 
> establishment,
>  is that of the Kerberos V5 GSS-API mechanism [KRB5GSS].
> *
> *Question to Nico: the paragraph preceding to this one says that the 
> client SHOULD check that the resulting mech_type is Kerberos V5.
> Is it worth repeating this here?

Nah.  I don't like extra redundancy.

>  Servers MAY use a credential obtained by calling GSS_Acquire_cred or 
> GSS_Add_cred for the server's
>  principal name and the Kerberos V5 GSS-API mechanism [KRB5GSS].
> 
> Question to Nico: "server's principal name" sounds very vague compared 
> to the original service@hostname text.
> 
>  (*) - 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.
> 
> >Is there a way to dig the hostname out of the client's initial response?
> 
> As per Nico's comment it is possible to use gss_inquire_context to 
> determine the target acceptor name as used by the client.
> I will add some text regarding this, something like the following:*
> 
> *  The server MUST check using the GSS_Inquire_context that the target_name
>  specified by the client matches GSS_C_NT_HOSTBASED_SERVICE 
> "service@hostname"
>  where "service" is the service name specified in the protocol's 
> profile, and "hostname" is one
>  of the fully qualified host names of the server.

You don't want to add this text.

The reason is that GSS_Display_name(), which you'd have to use to check
this, is lame and can display names in mechanism-specific syntax, (e.g.,
krb5 "unparsed" princ name syntax), which means that checking for
"service@hostname" can't quite be done the simple way.

This is a problem with the GSS-APIv2u1, and we do intend to fix this in
v3 by adding a new version of GSS_Display_name() that takes a name type
OID as input that tells the mechanism to display the name as a generic
name if possible.

I'm not sure what to suggest.  It is important to make sure that the
acceptor only has acceptor credentials for the service principals that
it should be accepting security contexts for.  But the GSS-APIv2u1 is
rather restrictive here and all the API-wise ways to do this are
painful!

Nico
-- 

Date: Sun, 14 May 2006 18:42:58 +0100
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>, Nicolas Williams <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Sender: [email-masked]

Chris Newman wrote:

> Nicolas Williams wrote on 5/1/06 17:32 -0500:
>
>> Having said that, I think the I-D should say that servers MUST NOT offer
>> "GSSAPI" unless they have acceptor credentials for the Kerberos V
>> GSS-API Mechanism,
>
I've added:

A server MUST NOT advertise support for the "GSSAPI" SASL mechanism 
described in
this document unless it has acceptor credential for the Kerberos V
GSS-API Mechanism [KRB5GSS].

>> while clients MUST reference use the OID of the
>> Kerberos V GSS-API Mechanism as the value for the 'mech' input of
>> GSS_Init_sec_context().
>
This is done as well.

> I concur.

Nicolas Williams wrote:

>On Mon, May 01, 2006 at 11:49:10AM -0700, Chris Newman wrote:
>  
>
>>Section 3 / GSSAPI in Kerberos 5 mode?
>>
>>I apologize that my understanding of GSSAPI is primitive, but I believe 
>>GSSAPI must be configured with a default mechanism.  As this protocol is 
>>for Kerberos v5 only, I presume the GSSAPI that's used on the client must 
>>be configured with Kerberos 5 as the default mechanism and not something 
>>else (e.g. SPNEGO). Shouldn't the specification make that explicit 
>>somewhere?  Does the server need a similar configuration, or can it figure 
>>it out based on the client's initial response?
>>    
>>
>First off, I think the I-D has to be very clear about "GSS-API" vs.
>"GSSAPI" -- the former being the short form of "Generic Security Service
>Application Program Interface" and the latter being a misnomer for the
>"Kerberos V GSS-API Mechanism."
>  
>
Fixed.

Date: Sun, 14 May 2006 18:38:20 +0100
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>, Nicolas Williams <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Sender: [email-masked]

Thanks for the comments Chris.

Chris Newman wrote:

> Minor: All the whitespace with the short sections is distracting.  
> Could you please add this to the XML source:
>  <?rfc compact="yes"?>
>  <?rfc subcompact="no"?>

Added.

> Abstract Nit: RFC editor rules forbid use of [] references; please 
> remove them. 

Fixed.

> Section 3 / GSSAPI in Kerberos 5 mode?
>
> I apologize that my understanding of GSSAPI is primitive, but I 
> believe GSSAPI must be configured with a default mechanism.  As this 
> protocol is for Kerberos v5 only, I presume the GSSAPI that's used on 
> the client must be configured with Kerberos 5 as the default mechanism 
> and not something else (e.g. SPNEGO). Shouldn't the specification make 
> that explicit somewhere?  Does the server need a similar 
> configuration, or can it figure it out based on the client's initial 
> response?

Fixed (see my other reply).

> Section 3.2 / initial response:
>
> As the SASL initial response is defined to be optional (and in the 
> case of IMAP it's not in the base specification), what does the server 
> do when it receives no initial response?  I presume the server sends 
> an empty challenge, but it'd be nice to explicitly say this is a 
> "client goes first" mechanism (regardless of use of the initial 
> response).

I've added:
   The GSSAPI SASL mechanism is a "client goes first" SASL mechanism, 
i.e. it
   starts with the client sending a "response" created as described in 
the following section.

> Section 3.2 / host name:
>
>>   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.
>
> Many modern servers have multiple fully qualified host names.  In a 
> high availability (HA) environment, there may be a direct host name 
> and a shared host name (to distinguish the two nodes in the HA 
> cluster).  And a multi-homed server may listen on multiple TCP/IP 
> interfaces, each of which may have one or more host names.

I've included text as proposed by Nico after applying some minor 
editorial changes:

  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 Kerberos V5 GSS-API mechanism [KRB5GSS] (*).
  Servers MAY use GSS_C_NO_CREDENTIAL as an acceptor credential handle,
  and SHOULD check that the mech_type of the security context, upon full 
establishment,
  is that of the Kerberos V5 GSS-API mechanism [KRB5GSS].
*
*Question to Nico: the paragraph preceding to this one says that the 
client SHOULD check that the resulting mech_type is Kerberos V5.
Is it worth repeating this here?

  Servers MAY use a credential obtained by calling GSS_Acquire_cred or 
GSS_Add_cred for the server's
  principal name and the Kerberos V5 GSS-API mechanism [KRB5GSS].

Question to Nico: "server's principal name" sounds very vague compared 
to the original service@hostname text.

  (*) - 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.

> Is there a way to dig the hostname out of the client's initial response?

As per Nico's comment it is possible to use gss_inquire_context to 
determine the target acceptor name as used by the client.
I will add some text regarding this, something like the following:*

*  The server MUST check using the GSS_Inquire_context that the target_name
  specified by the client matches GSS_C_NT_HOSTBASED_SERVICE 
"service@hostname"
  where "service" is the service name specified in the protocol's 
profile, and "hostname" is one
  of the fully qualified host names of the server.

Comments?

Date: Sun, 14 May 2006 18:18:56 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Sender: [email-masked]

Nicolas Williams wrote:

>On Tue, May 02, 2006 at 04:39:01PM -0700, Chris Newman wrote:
>  
>
>>Alexey, can you document this in the spec?
>>The GSS_C_NO_CREDENTIAL approach sounds a bit simpler, but the 
>>inquire_sec_context approach sounds better for servers using a private 
>>keytab.
>>    
>>
>BTW, if you want GSS_C_NO_CREDENTIAL semantics while forcibly limiting
>what mechanisms you will accept security contexts for you can acquire a
>credential handle for GSS_C_NO_NAME as the desired_name.
>
>That said, I think it's OK for servers to use GSS_C_NO_CREDENTIAL and
>then inspect the actual_mech output from GSS_Accept_sec_context() and
>reject the context if that turns out to be anything other than the krb5
>mech.
>  
>
After checking the GSS-API document I discovered that the GSS-API 
mechanism OID is an output parameter. So I've added text with a 
requirement for the server to check the output mechanism:

  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 Kerberos V5 [KRB5GSS].
  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 used SHOULD above as a particular GSS-API implementation may be 
known to only supports the Kerberos V5 GSS-API mechanism.

Date: Mon, 08 May 2006 19:22:42 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Sender: [email-masked]

Jeffrey Hutzelman wrote:

>> As the SASL initial response is defined to be optional (and in the case
>> of IMAP it's not in the base specification), what does the server do 
>> when
>> it receives no initial response?  I presume the server sends an empty
>> challenge, but it'd be nice to explicitly say this is a "client goes
>> first" mechanism (regardless of use of the initial response).
>
> I believe it is indeed necessary for a SASL mechanism to specify the 
> required behavior in this situation.  The empty-challenge behavior you 
> describe seems reasonable, but should be explicitly spelled out.

I've added in section 3:

The GSSAPI SASL mechanism is a "client goes first" SASL mechanism, i.e. it
starts with the client sending a "response" created as described in the 
following section.

Date: Wed, 03 May 2006 17:50:21 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Originator-Info: login-token=Mulberry:01WOFJfcJJvvGkLMH+i1957O9TgKjfFcLFVnfijmE=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, May 03, 2006 02:19:20 PM -0700 Chris Newman 
<[email-masked]> wrote:

>
> Jeffrey Hutzelman wrote on 5/3/06 11:58 -0400:
>> On Tue, 2 May 2006, Chris Newman wrote:
>>
>>> Jeffrey Hutzelman wrote on 5/1/06 18:07 -0400:
>>> >  At the GSS-API C-bindings level, this is accomplished by
>>> > calling gss_accept_sec_context with acceptor_cred_handle set to
>>> > GSS_C_NO_CREDENTIAL.  Note that this uses the system-default keytab;
>>> > overriding this behavior requires the use of a mechanism-specific,
>>> > implementation-specific API extension.
>>>
>>> Thanks, Jeff!
>>>
>>> Alexey, can you document this in the spec?
>>
>> That really doesn't seem to me to be something that belongs in this spec.
>> Implementors of this mechanism are going to need to read RFC2743 and
>> RFC2744, where the above information came from, and the question of
>> whether to use specific server credentials or the default ones is an
>> implementation matter.
>
> The spec problem is this statement:
>
>    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.
>
> Specifically, the phrase "the fully qualified host name of the server" is
> nonsensical in the general case and makes this impossible to implement.
> That text needs to be replaced.  Can you suggest replacement text that
> will interoperate?

OK; now I see the issue.  The existing text is telling servers to call 
GSS_Accept_sec_context with credentials that are tied to a particular 
service name, and while "fully qualified host name of the server" isn't 
actually nonsensical, it's also not actually the right thing.  I think 
Nico's proposed replacement text solves the problem nicely.

-- Jeff

Date: Wed, 3 May 2006 16:23:19 -0500
From: Nicolas Williams <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Mail-Followup-To: Chris Newman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, May 03, 2006 at 02:19:20PM -0700, Chris Newman wrote:
> The spec problem is this statement:
> 
>   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.
> 
> Specifically, the phrase "the fully qualified host name of the server" is 
> nonsensical in the general case and makes this impossible to implement.  
> That text needs to be replaced.  Can you suggest replacement text that will 
> interoperate?

Yeah, that text needs wordsmithing.

I'd replace it with:

   The server passes the initial client response to
   GSS_Accept_sec_context as input_token, setting input_context_handle
   to 0 (initially), mech_type of the GSSAPI mechanism for which this
   SASL mechanism is registered, chan_binding of NULL, and a suitable
   acceptor_cred_handle (see below).  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.

   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 Kerberos V
   GSS-API mechanism [RFC4121].  Servers MAY use GSS_C_NO_CREDENTIAL as
   an acceptor credential handle, and SHOULD check that the actual_mech
   of a security context, upon full establishment, is that of the
   Kerberos V GSS-API mechanism [RFC4121].  Servers MAY use a credential
   obtained by calling GSS_Acquire_cred or GSS_Add_cred the server's
   principal name and the Kerberos V GSS-API mechanism [RFC4121].

Date: Wed, 03 May 2006 14:19:20 -0700
From: Chris Newman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
To: Jeffrey Hutzelman <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

Jeffrey Hutzelman wrote on 5/3/06 11:58 -0400:
> On Tue, 2 May 2006, Chris Newman wrote:
>
>> Jeffrey Hutzelman wrote on 5/1/06 18:07 -0400:
>> >  At the GSS-API C-bindings level, this is accomplished by
>> > calling gss_accept_sec_context with acceptor_cred_handle set to
>> > GSS_C_NO_CREDENTIAL.  Note that this uses the system-default keytab;
>> > overriding this behavior requires the use of a mechanism-specific,
>> > implementation-specific API extension.
>>
>> Thanks, Jeff!
>>
>> Alexey, can you document this in the spec?
>
> That really doesn't seem to me to be something that belongs in this spec.
> Implementors of this mechanism are going to need to read RFC2743 and
> RFC2744, where the above information came from, and the question of
> whether to use specific server credentials or the default ones is an
> implementation matter.

The spec problem is this statement:

   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.

Specifically, the phrase "the fully qualified host name of the server" is 
nonsensical in the general case and makes this impossible to implement.  That 
text needs to be replaced.  Can you suggest replacement text that will 
interoperate?

                - Chris

Date: Wed, 3 May 2006 11:58:58 -0400 (EDT)
From: Jeffrey Hutzelman <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Sender: [email-masked]

On Tue, 2 May 2006, Chris Newman wrote:

> Jeffrey Hutzelman wrote on 5/1/06 18:07 -0400:
> >  At the GSS-API C-bindings level, this is accomplished by
> > calling gss_accept_sec_context with acceptor_cred_handle set to
> > GSS_C_NO_CREDENTIAL.  Note that this uses the system-default keytab;
> > overriding this behavior requires the use of a mechanism-specific,
> > implementation-specific API extension.
>
> Thanks, Jeff!
>
> Alexey, can you document this in the spec?

That really doesn't seem to me to be something that belongs in this spec.
Implementors of this mechanism are going to need to read RFC2743 and
RFC2744, where the above information came from, and the question of
whether to use specific server credentials or the default ones is an
implementation matter.

> >> Many modern servers have multiple fully qualified host names.  In a high
> >> availability (HA) environment, there may be a direct host name and a shared
> >> host name (to distinguish the two nodes in the HA cluster).  And a
> >> multi-homed server may listen on multiple TCP/IP interfaces, each of which
> >> may have one or more host names.  Is there a way to dig the hostname out of
> >> the client's initial response?
> >
> > Yes, there is: GSS_Init_sec_context() callers must provide a target name
> > and GSS_inquire_sec_context() outputs that name.
>
> Thanks, Nico!
>
> Alexey, can you document this in the spec?
> The GSS_C_NO_CREDENTIAL approach sounds a bit simpler, but the
> inquire_sec_context approach sounds better for servers using a private keytab.

No, you're confused.

As an application, you don't know anything about keytabs, and you don't
get to mediate the Kerberos exchange that happens to establish a security
context, except that you're responsible for transporting the tokens across
the network.

You must provide some credential to GSS_Accept_sec_context.  This can be
something you got from GSS_Acquire_creds, or it can be a "null" credential
to get the default behavior, which may be mechanism and/or implementation
specific.  If you are programming in C, you get this behavior by using the
special value GSS_C_NO_CREDENTIAL; in other languages it may be different.
For the Kerberos mechanism, the default credential lets you accept
contexts targeted at any service for which you have a key.

If the mechanism you are using is Kerberos, current implementations use
the system keytab (at least, for Kerberos implementations which use
keytabs; neither the Kerberos API nor the storage of service keys is the
subject of any standard).  In order to select some other keytab, you must
use a non-standard extension which is specific to the Kerberos mechanism
and to your particular implementation.  It happens that a few common
implementations with C-langauge API's share an interface for this, but
that is not the subject of standards work.

Once you have established a GSS-API security context, and not before, you
can call GSS_Inquire_sec_context to find out things about the context.
One of the things you can find out is the GSS-API service name that was
used by the client to establish the connection.  There are several things
for which this could be useful to applications, but it is _not_ a
principal name and it cannot be used to select a service key with which to
complete context establishment, since (a) you don't get to call this API
until after the context is established and (b) you are not responsible for
selecting a service key.

Implementors of this mechanism MUST read and understand RFC2743, which
specifies the GSS-API.  Implementors programming in C will also need to
read and understand RFC2744, which defines the C-language bindings for the
GSS-API.  It is necessary and appropriate for the present spec to tell you
what API calls you have to make to implement the mechanism correctly, but
the question of what credentials you use and how you acquire them is
outside its scope.

-- Jeff

Date: Tue, 2 May 2006 21:43:51 -0500
From: Nicolas Williams <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Mail-Followup-To: Chris Newman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, May 02, 2006 at 04:39:01PM -0700, Chris Newman wrote:
> Alexey, can you document this in the spec?
> The GSS_C_NO_CREDENTIAL approach sounds a bit simpler, but the 
> inquire_sec_context approach sounds better for servers using a private 
> keytab.

BTW, if you want GSS_C_NO_CREDENTIAL semantics while forcibly limiting
what mechanisms you will accept security contexts for you can acquire a
credential handle for GSS_C_NO_NAME as the desired_name.

That said, I think it's OK for servers to use GSS_C_NO_CREDENTIAL and
then inspect the actual_mech output from GSS_Accept_sec_context() and
reject the context if that turns out to be anything other than the krb5
mech.

What's NOT OK is for servers to advertise "GSSAPI" without knowing that
they have krb5 acceptor credentials -- whether that knowledge comes from
configuration or from actually trying GSS_Acquire/Add_cred() I don't
really care (though I prefer the latter).

Nico
-- 

Date: Tue, 02 May 2006 16:39:01 -0700
From: Chris Newman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
To: Jeffrey Hutzelman <[email-masked]>, Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Jeffrey Hutzelman wrote on 5/1/06 18:07 -0400:
>  At the GSS-API C-bindings level, this is accomplished by
> calling gss_accept_sec_context with acceptor_cred_handle set to
> GSS_C_NO_CREDENTIAL.  Note that this uses the system-default keytab;
> overriding this behavior requires the use of a mechanism-specific,
> implementation-specific API extension.

Thanks, Jeff!

Alexey, can you document this in the spec?

Nicolas Williams wrote on 5/1/06 17:32 -0500:
> Having said that, I think the I-D should say that servers MUST NOT offer
> "GSSAPI" unless they have acceptor credentials for the Kerberos V
> GSS-API Mechanism, while clients MUST reference use the OID of the
> Kerberos V GSS-API Mechanism as the value for the 'mech' input of
> GSS_Init_sec_context().

I concur.

>> Many modern servers have multiple fully qualified host names.  In a high
>> availability (HA) environment, there may be a direct host name and a shared
>> host name (to distinguish the two nodes in the HA cluster).  And a
>> multi-homed server may listen on multiple TCP/IP interfaces, each of which
>> may have one or more host names.  Is there a way to dig the hostname out of
>> the client's initial response?
>
> Yes, there is: GSS_Init_sec_context() callers must provide a target name
> and GSS_inquire_sec_context() outputs that name.

Thanks, Nico!

Alexey, can you document this in the spec?
The GSS_C_NO_CREDENTIAL approach sounds a bit simpler, but the 
inquire_sec_context approach sounds better for servers using a private keytab.

                - Chris

Date: Mon, 1 May 2006 17:32:49 -0500
From: Nicolas Williams <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Mail-Followup-To: Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, May 01, 2006 at 11:49:10AM -0700, Chris Newman wrote:
> Section 3 / GSSAPI in Kerberos 5 mode?
> 
> I apologize that my understanding of GSSAPI is primitive, but I believe 
> GSSAPI must be configured with a default mechanism.  As this protocol is 
> for Kerberos v5 only, I presume the GSSAPI that's used on the client must 
> be configured with Kerberos 5 as the default mechanism and not something 
> else (e.g. SPNEGO). Shouldn't the specification make that explicit 
> somewhere?  Does the server need a similar configuration, or can it figure 
> it out based on the client's initial response?

First off, I think the I-D has to be very clear about "GSS-API" vs.
"GSSAPI" -- the former being the short form of "Generic Security Service
Application Program Interface" and the latter being a misnomer for the
"Kerberos V GSS-API Mechanism."

Having said that, I think the I-D should say that servers MUST NOT offer
"GSSAPI" unless they have acceptor credentials for the Kerberos V
GSS-API Mechanism, while clients MUST reference use the OID of the
Kerberos V GSS-API Mechanism as the value for the 'mech' input of
GSS_Init_sec_context().

> Section 3.2 / host name:
> 
> >  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.
> 
> Many modern servers have multiple fully qualified host names.  In a high 
> availability (HA) environment, there may be a direct host name and a shared 
> host name (to distinguish the two nodes in the HA cluster).  And a 
> multi-homed server may listen on multiple TCP/IP interfaces, each of which 
> may have one or more host names.  Is there a way to dig the hostname out of 
> the client's initial response?

Yes, there is: GSS_Init_sec_context() callers must provide a target name
and GSS_inquire_sec_context() outputs that name.

> As I'm not familiar with how GSSAPI/Kerberos deals with multiple server 
> host names, I can't suggest text.  But I do find this sentence ambiguous: I 
> wouldn't know how to implement it.

The GSS-API handles this, and for SASL this is an API issue.

Of course, whether it is possible depends on the mechanism transporting
that name, which, IIRC, GSS-API mechanisms MUST do when using MUTUAL
authentication.

Nico
-- 

Date: Mon, 01 May 2006 18:07:56 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Originator-Info: login-token=Mulberry:019OwuPF5Uo7BAN6a9J2peq4teZWd7IKdhYVyhKmw=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, May 01, 2006 02:41:07 PM -0700 Chris Newman 
<[email-masked]> wrote:

> The the spec needs to state that the client should pass the Kerbero 5 OID
> to GSS_Init_sec_context.

Well, it sort of does.  Section 3.1 specifies what parameters must be 
passed to GSS_Init_sec_context, including...

"... mech_type of the GSSAPI mechanism for which this SASL mechanism is 
registered, ..."

That wording was more meaningful when this was a document defining a family 
of mechanisms, since there was a one-to-one mapping between GSSAPI 
mechanism OID's and SASL mechansism names which was defined elsewhere in 
the document.  Now it's a single-mechanism document which always uses the 
Kerberos GSS-API mechanism, as noted in section 2.  Instead of "of the 
GSSAPI mechanism for which this SASL mechanism is registered", the text 
could say "of the Kerberos GSS-API mechanism".

FWIW, while the dash is often omitted in common usage, the formal 
abbreviation for "Generic Security Service Application Program Interface" 
is "GSS-API".  This document really should be consistently correct about 
this, except for the SASL mechanism name itself, which must be "GSSAPI" (no 
dash) to be consistent with the deployed implementations whose behavior we 
are trying to document.

> Does it also need to state that for the server?

Not exactly.  RFC2743 defines the mech_type parameter to 
GSS_Accept_sec_context as an _output_ parameter, indicating what mechanism 
was actually used.  For standards-track mechanisms, there is common framing 
for the initial context token which makes it possible for the accepting 
GSS-API to tell what mechanism is in use.  However, an acceptor which has 
negotiated use of a particular mechanism at a higher layer (as SASL does) 
must check that the returned mech_type is the one expected.

> I'm sorry I didn't state the question clearly so you're answering the
> wrong question.  Let me try again:

> Presumably, a server with multiple host names will have a fixed set of
> host names which it accepts for Kerberos authentication.  Can the server
> determine which host name the client used in its initial response, and
> use that host name if it's one of the ones on the fixed list?

> In SSL/TLS, the typical answer is that mail.domain1.com and
> mail.domain2.com must have different IP addresses so the server knows
> which certificate to offer based on the result from getsockname().  I'm
> wondering if there is a better answer for Kerberos or if it's equally
> broken.

Kerberos does not have that particular flaw, for two reasons.

First, in TLS, the server proves its identity by presenting a certificate 
which asserts a particular identity; if it chooses the wrong cert, it 
doesn't work.  As you pointed out, TLS has the flaw that there is no way 
for the client to indicate to the server what identity it's interested in, 
so a server with more than one identity has to guess.  In Kerberos, the 
server proves its identity by its ability to decrypt a message protected by 
a key known only to the service the client wants to talk to.  Since the 
server doesn't have to claim a particular identity, there's no opportunity 
for it to pick the wrong one.

Second, Kerberos tickets include information about the service principal 
the ticket is for, so the server knows which key to use to decrypt the 
ticket.  At the Kerberos API layer, an application need only pass a NULL 
service principal name to krb5_rd_req to automatically determine the 
correct service principal to use.  At the GSS-API C-bindings level, this is 
accomplished by calling gss_accept_sec_context with acceptor_cred_handle 
set to GSS_C_NO_CREDENTIAL.  Note that this uses the system-default keytab; 
overriding this behavior requires the use of a mechanism-specific, 
implementation-specific API extension.

-- Jeff

Date: Mon, 01 May 2006 14:41:07 -0700
From: Chris Newman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
To: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Jeffrey Hutzelman wrote on 5/1/06 17:01 -0400:
> On Monday, May 01, 2006 11:49:10 AM -0700 Chris Newman <[email-masked]>
> wrote:
>
>> Section 3 / GSSAPI in Kerberos 5 mode?
>>
>> I apologize that my understanding of GSSAPI is primitive, but I believe
>> GSSAPI must be configured with a default mechanism.  As this protocol is
>> for Kerberos v5 only, I presume the GSSAPI that's used on the client must
>> be configured with Kerberos 5 as the default mechanism and not something
>> else (e.g. SPNEGO). Shouldn't the specification make that explicit
>> somewhere?  Does the server need a similar configuration, or can it
>> figure it out based on the client's initial response?
>
> A user of the GSS-API selects a mechanism by passing in a mechanism OID as
> one of the parameters to GSS_Init_sec_context.  While it is possible for an
> application to pass in a "NULL" mechanism OID parameter to select a "default"
> mechanism, it would be incorrect for an implementation of the present
> specification to do so, since the use of a particular mechanism is mandated.
>
> Although it's not relevant to the current specification, selection of a
> "default" mechanism is an implementation matter.  In most implementations
> that existed at the time RFC2743 was written, and in most that are widely
> deployed today, the GSS-API implementation supports only a single mechanism,
> and no configuration is required.  Manual selection of a default mechanism is
> required only for multi-mechanism GSS-API implementations, which are only now
> becoming common.  In any case, this issue is only relevant for deployment of
> applications which request the "default" mechansim, and neither the present
> 'GSSAPI' mechanism nor the upcoming 'GSS2-*' family of mechanisms will permit
> this; each of these SASL mechanisms require the use of a specific GSS-API
> mechanism.

The the spec needs to state that the client should pass the Kerbero 5 OID to 
GSS_Init_sec_context.  Does it also need to state that for the server?

>> Section 3.2 / host name:
>>
>>>   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.
>>
>> Many modern servers have multiple fully qualified host names.  In a high
>> availability (HA) environment, there may be a direct host name and a
>> shared host name (to distinguish the two nodes in the HA cluster).  And a
>> multi-homed server may listen on multiple TCP/IP interfaces, each of
>> which may have one or more host names.  Is there a way to dig the
>> hostname out of the client's initial response?
>
> As this is an authentication name, it is unsafe to use a name obtained from
> insecure DNS, as by a SRV lookup, or one reported by the server itself. The
> correct behavior today, for any application using GSS-API host-based service
> names, is to use the configured fully-qualified name of the service, and
> _not_ the hostname obtained from the SRV record of a host which happens to be
> _providing_ the service.

I'm sorry I didn't state the question clearly so you're answering the wrong 
question.  Let me try again:

Presumably, a server with multiple host names will have a fixed set of host 
names which it accepts for Kerberos authentication.  Can the server determine 
which host name the client used in its initial response, and use that host name 
if it's one of the ones on the fixed list?  If not, is there another way for 
the server to figure out which hostname the client is expecting it to use?

I'm trying to figure out how to implement the server-side of this.  The client 
side is straightforward and I know to use the pre-DNS name for Kerberos, just 
as it's used for SSL/TLS.

>> As I'm not familiar with how GSSAPI/Kerberos deals with multiple server
>> host names, I can't suggest text.  But I do find this sentence ambiguous:
>> I wouldn't know how to implement it.
>
> You use the configured name, and _never_ a name you got from reverse
> resolution or a SRV record.  Today, there are legacy GSS-API implementations
> which will do reverse-resolution for you, but at least in the Kerberos case,
> RFC4120 and RFC4121 prohibit this behavior, and we expect that eventually
> implementations will comply, though the transition issues are somewhat
> complex (unfortunately, just changing breaks things for a lot of people who
> depend on the insecure behavior today).

I know not to do a SRV lookup and that wouldn't solve the problem anyway.  Let 
me state a simplified case: suppose there is one server with two host names, 
say "mail.domain1.com" and "mail.domain2.com".  The server legitimately serves 
mail for both domains.  When a client connects, the client will be configured 
to use one of those two domains.  How does the server know which one the client 
intended to use?  How does the server know whether to pass "mail.domain1.com" 
or "mail.domain2.com" to GSS_Import_name to form the desired_name for 
GSS_Acquire_cred?

In SSL/TLS, the typical answer is that mail.domain1.com and mail.domain2.com 
must have different IP addresses so the server knows which certificate to offer 
based on the result from getsockname().  I'm wondering if there is a better 
answer for Kerberos or if it's equally broken.

                - Chris

Date: Mon, 01 May 2006 17:01:34 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Originator-Info: login-token=Mulberry:01xOm3Ii5RLJYQNC+j92fnkVtb7k1LHTAxXuWH+mk=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, May 01, 2006 11:49:10 AM -0700 Chris Newman 
<[email-masked]> wrote:

> Section 3 / GSSAPI in Kerberos 5 mode?
>
> I apologize that my understanding of GSSAPI is primitive, but I believe
> GSSAPI must be configured with a default mechanism.  As this protocol is
> for Kerberos v5 only, I presume the GSSAPI that's used on the client must
> be configured with Kerberos 5 as the default mechanism and not something
> else (e.g. SPNEGO). Shouldn't the specification make that explicit
> somewhere?  Does the server need a similar configuration, or can it
> figure it out based on the client's initial response?

A user of the GSS-API selects a mechanism by passing in a mechanism OID as 
one of the parameters to GSS_Init_sec_context.  While it is possible for an 
application to pass in a "NULL" mechanism OID parameter to select a 
"default" mechanism, it would be incorrect for an implementation of the 
present specification to do so, since the use of a particular mechanism is 
mandated.

Although it's not relevant to the current specification, selection of a 
"default" mechanism is an implementation matter.  In most implementations 
that existed at the time RFC2743 was written, and in most that are widely 
deployed today, the GSS-API implementation supports only a single 
mechanism, and no configuration is required.  Manual selection of a default 
mechanism is required only for multi-mechanism GSS-API implementations, 
which are only now becoming common.  In any case, this issue is only 
relevant for deployment of applications which request the "default" 
mechansim, and neither the present 'GSSAPI' mechanism nor the upcoming 
'GSS2-*' family of mechanisms will permit this; each of these SASL 
mechanisms require the use of a specific GSS-API mechanism.

> As the SASL initial response is defined to be optional (and in the case
> of IMAP it's not in the base specification), what does the server do when
> it receives no initial response?  I presume the server sends an empty
> challenge, but it'd be nice to explicitly say this is a "client goes
> first" mechanism (regardless of use of the initial response).

I believe it is indeed necessary for a SASL mechanism to specify the 
required behavior in this situation.  The empty-challenge behavior you 
describe seems reasonable, but should be explicitly spelled out.

> Section 3.2 / host name:
>
>>   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.
>
> Many modern servers have multiple fully qualified host names.  In a high
> availability (HA) environment, there may be a direct host name and a
> shared host name (to distinguish the two nodes in the HA cluster).  And a
> multi-homed server may listen on multiple TCP/IP interfaces, each of
> which may have one or more host names.  Is there a way to dig the
> hostname out of the client's initial response?

As this is an authentication name, it is unsafe to use a name obtained from 
insecure DNS, as by a SRV lookup, or one reported by the server itself. 
The correct behavior today, for any application using GSS-API host-based 
service names, is to use the configured fully-qualified name of the 
service, and _not_ the hostname obtained from the SRV record of a host 
which happens to be _providing_ the service.

This means that if multiple hosts are providing service under the same 
name, then they must all be able to accept GSS-API contexts under that name 
(with Kerberos, this means they need to share a service key).  And, if a 
host provides service under multiple names, it must be able to accept 
GSS-API contexts under any of those names (with Kerberos, that typically 
means the host has one service key for each name).

There is work currently going on in the KITTEN working group to define a 
"domain-based" service name form, in which the service name is derived from 
both the DNS name of the _service_ and the DNS name of the _host_ providing 
that service, in such a way that the latter may be obtained from an 
insecure source such as reverse DNS resolution, provided the former is 
still obtained in a secure fashion.  When complete, this will allow 
deployments in which multiple hosts which provide service under the same 
name need not share any credentials.

> As I'm not familiar with how GSSAPI/Kerberos deals with multiple server
> host names, I can't suggest text.  But I do find this sentence ambiguous:
> I wouldn't know how to implement it.

You use the configured name, and _never_ a name you got from reverse 
resolution or a SRV record.  Today, there are legacy GSS-API 
implementations which will do reverse-resolution for you, but at least in 
the Kerberos case, RFC4120 and RFC4121 prohibit this behavior, and we 
expect that eventually implementations will comply, though the transition 
issues are somewhat complex (unfortunately, just changing breaks things for 
a lot of people who depend on the insecure behavior today).

-- Jeff

Date: Mon, 01 May 2006 13:28:15 -0600
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms020109080607000000000208
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Chris Newman wrote:

> Section 3.2 / host name:
> 
>>   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.
> 
> Many modern servers have multiple fully qualified host names.  In a high
> availability (HA) environment, there may be a direct host name and a
> shared host name (to distinguish the two nodes in the HA cluster).  And
> a multi-homed server may listen on multiple TCP/IP interfaces, each of
> which may have one or more host names.  Is there a way to dig the
> hostname out of the client's initial response?
> 
> As I'm not familiar with how GSSAPI/Kerberos deals with multiple server
> host names, I can't suggest text.  But I do find this sentence
> ambiguous: I wouldn't know how to implement it.

We've had some confusion about this in the XMPP world (cf. RFC 3920).
Specifically, in some deployments, an XMPP server may have associated
with it multiple connection managers. How does a client determine the
service principal name of the connection manager to which it has
connected if connection managers are assigned dynamically? There is some
discussion here:

http://mail.jabber.org/pipermail/xmppwg/2006-April/002380.html

I freely grant that this may be more of an XMPP issue than a GSSAPI
issue, but I wonder what we should be recommending to implementors
regarding the process of selecting service principal names for services
(such as XMPP servers) that are discovered via SRV...

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

--------------ms020109080607000000000208
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020109080607000000000208--

Date: Mon, 01 May 2006 11:49:10 -0700
From: Chris Newman <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-gssapi-04.txt
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Minor: All the whitespace with the short sections is distracting.  Could you 
please add this to the XML source:
  <?rfc compact="yes"?>
  <?rfc subcompact="no"?>

Abstract Nit: RFC editor rules forbid use of [] references; please remove them.

Section 3 / GSSAPI in Kerberos 5 mode?

I apologize that my understanding of GSSAPI is primitive, but I believe GSSAPI 
must be configured with a default mechanism.  As this protocol is for Kerberos 
v5 only, I presume the GSSAPI that's used on the client must be configured with 
Kerberos 5 as the default mechanism and not something else (e.g. SPNEGO). 
Shouldn't the specification make that explicit somewhere?  Does the server need 
a similar configuration, or can it figure it out based on the client's initial 
response?

Section 3.2 / initial response:

As the SASL initial response is defined to be optional (and in the case of IMAP 
it's not in the base specification), what does the server do when it receives 
no initial response?  I presume the server sends an empty challenge, but it'd 
be nice to explicitly say this is a "client goes first" mechanism (regardless 
of use of the initial response).

Section 3.2 / host name:

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

Many modern servers have multiple fully qualified host names.  In a high 
availability (HA) environment, there may be a direct host name and a shared 
host name (to distinguish the two nodes in the HA cluster).  And a multi-homed 
server may listen on multiple TCP/IP interfaces, each of which may have one or 
more host names.  Is there a way to dig the hostname out of the client's 
initial response?

As I'm not familiar with how GSSAPI/Kerberos deals with multiple server host 
names, I can't suggest text.  But I do find this sentence ambiguous: I wouldn't 
know how to implement it.

Otherwise, I've reviewed this specification, from a SASL/Applications 
perspective and find it acceptable.  I have minimal GSSAPI expertise so I'm not 
competent to review the specification on the technical aspects related to 
GSSAPI usage.

                - Chris

Kurt D. Zeilenga wrote on 4/29/06 7:31 -0700:

>
> This WG Last Call is hereby extended to 8 May 2006 to allow
> other WG members to contribute to review of this document.
>
> I do not feel the I-D has received adequate WG review
> necessary to support a WG recommendation for publication
> on the Standards Track.  So, again, please read and
> comment.
>
> Kurt
>
> At 08:46 AM 4/12/2006, Kurt D. Zeilenga wrote:
>
>> This message initiates a SASL Working Group Last Call on the
>> document:
>>
>>  Title:     The Kerberos V5 ("GSSAPI") SASL mechanism
>>  Editor:    A. Melnikov
>>  Filename:  draft-ietf-sasl-gssapi-04.txt
>>
>> The purpose of this WG Last Call is to ensure that the Working
>> Group has achieved consensus that the document is suitable for
>> publication on the Standards Track.
>>
>> Please review the document for both technical and editorial
>> problems.  Technical issues should be discussed on this list.
>> Editorial issues may be sent to the document editor.  In
>> the case that a reviewer finds no technical issues, the
>> reviewer should send a note to the WG chairs indicating
>> so.
>>
>> The Last Call period will close on Friday, 28 April 2006.
>>
>> Upon completion of the WG Last Call, the WG chair(s) will take
>> action based upon the consensus of the WG.  Possible actions
>> include:
>>
>>  1) recommending to the IETF Security Area Directors
>>     that the document, after possible editorial or
>>     other minor changes, be considered by the IESG
>>     for publication as a Standard Track RFC; or
>>
>>  2) requiring that outstanding issues be adequately
>>     addressed prior to further action (including,
>>     possibly, another WG Last Call).
>>
>> Remember that it is our responsibility as Working Group members
>> to ensure the quality of our documents.  So, please read and
>> comment!
>>
>> Kurt Zeilenga, SASL WG co-chair
>
>