Subject: SASL BOF

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 28 Jun 2001 13:49:30 -0700

Greetings again. I just noticed that someone has requested a SASL BOF 
at the London IETF. Could the person who asked for the BOF say what 
the intended agenda is?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 28 Jun 2001 14:26:07 -0700

At 01:49 PM 6/28/2001, Paul Hoffman / IMC wrote:
>Greetings again. I just noticed that someone has requested a SASL BOF at the London IETF. Could the person who asked for the BOF say what the intended agenda is?

Below is a copy of recently approved request.  If the WG
is approved, we'll meet as a WG.  If not, we'll address
whatever formations issues need to be addressed (currently
none) and use remaining time to address technical issues
(list TBD) with the (proposed) work items.

Kurt

>SASL BOF (sasl)
>
>CHAIR(S):
>  Kurt Zeilenga <[email-masked]>
>  Alexey Melnikov <[email-masked]>
>
>Security Area AD: <[email-masked]>
>Applications Area Technical Advisor: <[email-masked]>
>
>DESCRIPTION:
>
>This BOF will discuss the formation a working group to shepherd
>SASL to Draft Standard.  As a WG proposal has been submitted
>and is under IAB/IESG consideration, the status of this proposal
>will be presented and discussed.  The BOF will consider actions
>necessary to further the WG proposal.  The proposed WG is described
>as follows:
>
>  The Simple Authentication and Security Layer [RFC2222] provides
>  key security services to a number of application protocols
>  including BEEP, IMAP, LDAP, POP, and SMTP.  The purpose of
>  this working group is to shepherd SASL, including select SASL
>  mechanisms, though the Internet Standard process.
>
>  This group will deliver a revised SASL Technical Specification
>  suitable for consideration as a Draft Standard.  This work
>  will be based upon RFC 2222 and draft-myers-saslrev-00.txt.
>
>  This group will deliver revised Technical Specifications
>  suitable considerations as Draft Standards for the following
>  SASL mechanisms: CRAM-MD5, DIGEST-MD5, and EXTERNAL.  This work
>  will be based upon RFC 2195, 2222, and 2831.
>
>  This group will deliver a revised Technical Specification
>  suitable for publication as Proposed Standard for the GSSAPI
>  family of SASL mechanisms.  This work will be based upon
>  RFC 2222 and draft-ietf-cat-sasl-gssapi-02.txt.
>
>  This group will deliver a Technical Specification
>  suitable for publication as Proposed Standard describing
>  a family of SASL mechanisms using the Secure Remote
>  Password [RFC2945] protocol.  This work will be based
>  upon draft-burdis-cat-srp-sasl-04.txt.
>
>  The following areas are not within the scope of work of this WG:
>    - new features,
>    - SASL Mechanisms not specifically mentioned above, and
>    - SASL "profiles".
>
>  However, the SASL WG is an acceptable forum for review of
>  SASL-related submissions produced by others as long as such
>  review does not impede progress on the WG objectives listed
>  above.
>
>MAILING LIST:
>  General Discussions: <[email-masked]>
>  To Subscribe: <[email-masked]>
>  In Body: subscribe
>  Archive: http://www.imc.org/ietf-sasl/mail-archive/

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 28 Jun 2001 14:26:07 -0700

Kurt

>  Archive: http://www.imc.org/ietf-sasl/mail-archive/

Date: Thu, 28 Jun 2001 14:26:07 -0700
To: Paul Hoffman / IMC <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASL BOF
Cc: [email-masked]
Sender: [email-masked]

Kurt

>  Archive: http://www.imc.org/ietf-sasl/mail-archive/

Date: Thu, 28 Jun 2001 13:49:30 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: SASL BOF
Sender: [email-masked]

--Paul Hoffman, Director

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: sasl-gssapi questions: base32 and context flags
Date: Mon, 18 Jun 2001 15:41:44 -0700
Organization: Netscape Communications Corporation
Lines: 112
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msB37DCE51FC08CF66C861E545
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Brezak wrote:
> The settings of the integ_req_flag and conf_req_flag are specified for
> the use of the GSSAPI mechanism for the exchange of the security layer.
> However there should be some explaination on the use of the security
> layer that is negotiated and how it is applied to the GSS security
> context that was used during the SASL exchanges.

Isn't this specified adequately in RFC 2743?  Sections 2.3.3 and 2.4.4
clearly state that the GSS security context is used as an input.

> For example, the GSSAPI context needed for performing the SASL exchange
> requires that integ and optionally conf (if the client is requesting
> conf) are set for the purposes of exchanging the security layer. If the
> resulting security layer does not specify conf, then what is to be done
> with the security context that was used for SASL negotiation?

Did you want a statement that the server and client are to call
GSS_Inquire_context, suppressing 2 and 4 of the security layer bit-mask
if integ_avail and conf_avail, respectively, are FALSE?

> If the
> server responds that integ is only accepted, then should the client
> security context that was created with integ+conf be discarded?

No, if the client and server are then willing to communicate with only
integrity protection then the client security context will be needed for
calls to GSS_Wrap and GSS_Unwrap.

> In section 6.1:
> - Why restrict name types to only the HOSTBASED names? You should allow
> any name type available to the GSS mechanisms (same for 6.2).

I emphatically disagree.

We need to completely specify the targ_name/desired_name in order to
permit interoperability.  Servers and clients will not interoperate
unless they use the same name for these two fields.

SASL protocol profiles know nothing about GSS API name types and names
other than the requirement of the SASL base specification that SASL
protocol profiles specify a service name selected from the IANA registry
of "service" elements for the GSSAPI host-based service name form.  The
SASL-GSSAPI specification needs to specify the targ_name/desired_name to
used based on the information that an implementation is likely to have
available.

> - When the client calls GSS_Unwrap, the conf_flag must be returned as
> false, since the server (client) wraps with no confidentiality (same for
> 6.2).

I see no security need to perform this check.  Could you explain what
purpose mandating such a check would serve?
--------------msB37DCE51FC08CF66C861E545
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

--------------msB37DCE51FC08CF66C861E545--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: sasl-gssapi questions: base32 and context flags
Date: Mon, 18 Jun 2001 15:03:28 -0700
Organization: Netscape Communications Corporation
Lines: 89
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms2BADE03548440C4236604261
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Brezak wrote:
> So the base32 is to avoid the need for a registration authority?

The base32-MD5 is to use the existing GSS mechanism registrations.

> It
> still seems that this base32 encoding is over-kill to avoid the use of
> names. Keeping the names at least makes it consistent with the other
> authentication mechanism names. Why not just register the GSSAPI
> mechtype names with IANA (like the other SASL names)?

Then it would not be possible to implement GSS mechanisms under SASL
using only the GSS API.  With the current draft, it is possible to write
generic GSS/SASL mechanism glue code, querying the GSS API for available
mechanism OIDs and algorithmically generating a list of corresponding
SASL mechanisms names from that.  Once such glue code is written, any
GSS mechanism later installed into the GSS API will automatically be
available through SASL.

With a separate SASL GSS mechtype registry, such glue code would have to
have a table mapping OIDs of known GSS mechanisms to SASL mechanism
names.  A newly installed GSS mechanism could not be made available
through SASL until it had its SASL mechanism name installed into the
SASL glue code's table.

> Maybe define a different type like "GSS-OID" and put the full OID after
> the name section.

After the name section?  Which field are you talking about?
--------------ms2BADE03548440C4236604261
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

--------------ms2BADE03548440C4236604261--

Date: Tue, 12 Jun 2001 14:52:40 -0700
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: [email-masked]
Sender: [email-masked]

At 05:02 PM 5/30/2001, John Gardiner Myers wrote:

>I believe the following are the changes necessary for each of the
>proposed solutions to the authorization id problem:

I have added other changes I believe are needed:

>Authorization ids are character strings:

 * Define the character set to be ISO 10646.
 * Recommend that mechanisms use UTF-8 encoding of character
   strings.
 * Recommend that mechanisms provide escaping or other method
   to allow transfer of authorization identities to include
   arbitrary (non-NUL) characters.
 * Recommend that mechanisms against using encoding which
   can only represent a subset of the character set (e.g. UCS-2).

>* Add to SASL section 4.2 a specification that the authorization
>identity is a character string.  NUL characters not permitted.

 * Update profiles which allow NUL characters in authzIds.

>* Make SASL requirement 5.5 optional to the protocol profile.

 * Update mechanisms to implement above recommendations.
   Add restriction to GSSAPI and EXTERNAL
   Add escaping mechanism to most every other mechanism.

>Authorization ids are octet strings:
>
>* Revert additions to SASL-GSSAPI and EXTERNAL, removing the
>specification that the authorization id is in UTF-8.
>
>* Extend DIGEST-MD5, OTP, SECURID, and PLAIN to carry non-UTF-8
>authorization
>ids.  OTP, SECURID, and PLAIN will likely remain incapable of carrying 0
>octets in authorization ids.

A simple escaping mechanism can be used.

>* Add to the POP, IMAP, ACAP, etc. protocol profiles a specification
>that the authorization ID is in UTF-8.

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Use of authorization identity
Date: Thu, 07 Jun 2001 14:40:06 -0700
Organization: Netscape Communications Corporation
Lines: 70
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms413ECEE943C0D8D945E07CC8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> What concerns me most is scope.  We need to be sure we are fixing
> SASL, not codifying limitations of certain mechanisms, profiles,
> and implementations thereof.

Sometimes fixing a standard involves codifying the behavior of the
installed base.

Our scope is to move SASL and some of its mechanisms to Draft Standard,
recycling documents at Proposed only if there is strong reason to do so.
--------------ms413ECEE943C0D8D945E07CC8
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

--------------ms413ECEE943C0D8D945E07CC8--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Use of authorization identity
Date: Thu, 07 Jun 2001 14:28:16 -0700
Organization: Netscape Communications Corporation
Lines: 70
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms2BCA461695DF910A0733DC6C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Raif S. Naffah" wrote:
> this way at least the community of
> users using the same programming language API can have more flexibility in
> configuring/using different Protocols and Mechanisms.

I don't agree that octet strings have substantive advantages over
character strings for this purpose.  I would, however, like to defer the
debate over which alternative is more appropriate until after we have
agreement on the set of possible alternatives and the set of changes
needed for each alternative.
--------------ms2BCA461695DF910A0733DC6C
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

--------------ms2BCA461695DF910A0733DC6C--

content-class: urn:content-classes:message
Subject: RE: sasl-gssapi questions: base32 and context flags
Date: Thu, 7 Jun 2001 12:52:27 -0700
From: "John Brezak" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Thanx for pointing out the limit.

So the base32 is to avoid the need for a registration authority? It
still seems that this base32 encoding is over-kill to avoid the use of
names. Keeping the names at least makes it consistent with the other
authentication mechanism names. Why not just register the GSSAPI
mechtype names with IANA (like the other SASL names)?

Maybe define a different type like "GSS-OID" and put the full OID after
the name section.

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Monday, June 04, 2001 7:34 PM
> To: John Brezak
> Cc: [email-masked]
> Subject: Re: sasl-gssapi questions: base32 and context flags
> 
> 
> John Brezak wrote:
> 
> > Is the base32 encoding method used for anything other than the 10 
> > bytes used in the suffix for the gssapi mechanism encoding? 
> If so why 
> > go through all of this complexity - why not just use the 
> text version 
> > of the OID for the mechtype?
> 
> IMHO, there are two reasons:
> 
> 1). Allowed characters for mechanism name are uppercase 
> letters, digits, "-" and "_" (thus "." is not allowed) 2). 
> There is a limit of 20 characters for mechanism name. Having 
> prefix "GSS-" this leaves 16 characters.
> 
> __________________________________________
> Alexey Melnikov
> R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
> phone 780.424.4922 x357
> 
> I speak for myself only, not for my employer. 
> __________________________________________
> 
> 
> 

Date: Wed, 06 Jun 2001 19:57:10 +1000
To: [email-masked]
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: John Gardiner Myers <[email-masked]>
Sender: [email-masked]

At 07:46 PM 6/5/01 +1000, Raif S. Naffah wrote:
>At 02:26 PM 6/4/01 -0700, John Gardiner Myers wrote:
>
>
>>"Raif S. Naffah" wrote:
>> > of course.  but this is not the issue.  the issue, is how a protocole
>> > passes the contents of the authorization-id to a mechanism...
>
>the keyword here is passes. not "internally repesent" as you mentioned in 
>your message, or any other situation.
>
>for mechanisms to be inter-operable between different implementations, and 
>inter-changeable between protocols, the authorization id has to be passed 
>from a protocol to a mechanism in a programming language, and an encoding 
>neutral way.

re-reading my own words i realise that the previous statement is not 
(always) valid:

1. it is safe to assume that when a Protocol needs to use a Mechanism it 
needs to pass it more than just the authorization ID; eg. the Java API.

2. in the absence of a unified API, it does not matter if only the 
authorization ID is well defined in terms of its form, since 2 different 
implementations, in the same programming language, are likely to have 
different method names/mechanisms for instantiating the Mechanism, as well 
as a different order of parameters, even if they both use the same 
arguments+types.

3. in the presence of unified APIs (one per programming language), and 
within each of those languages (with that unified API), would mandating 
that the authorization ID be an octet sequence render the above statement 
true, but only for that language binding. ie. A Protocol knows how to 
handle the authorization ID, it passes it to the Mechanism as an octet 
sequence on one side, it gets it back on the other side, and handles it 
there with the right (as defined in its specs) encoding.

4. only with a programming language neutral interface definition; ie. OMG's 
IDL, would the above statement be always true.

although (3) and (4) are not likely to be included in the objectives of 
this WG, it's beneficial to clarify the specs in favour of having the 
authorization ID as an octet sequence.  this way at least the community of 
users using the same programming language API can have more flexibility in 
configuring/using different Protocols and Mechanisms.

thanks for the bandwidth + cheers;
rsn

content-class: urn:content-classes:message
Subject: RE: sasl-gssapi questions: base32 and context flags
Date: Tue, 5 Jun 2001 12:50:52 -0700
From: "John Brezak" <[email-masked]>
To: "John Gardiner Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0047_01C0EDBE.17AD5AE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The settings of the integ_req_flag and conf_req_flag are specified for
the use of the GSSAPI mechanism for the exchange of the security layer.
However there should be some explaination on the use of the security
layer that is negotiated and how it is applied to the GSS security
context that was used during the SASL exchanges.

For example, the GSSAPI context needed for performing the SASL exchange
requires that integ and optionally conf (if the client is requesting
conf) are set for the purposes of exchanging the security layer. If the
resulting security layer does not specify conf, then what is to be done
with the security context that was used for SASL negotiation? If the
server responds that integ is only accepted, then should the client
security context that was created with integ+conf be discarded?

In section 6.1:
- Why restrict name types to only the HOSTBASED names? You should allow
any name type available to the GSS mechanisms (same for 6.2).
- When the client calls GSS_Unwrap, the conf_flag must be returned as
false, since the server (client) wraps with no confidentiality (same for
6.2).

> -----Original Message-----
> From: John Gardiner Myers [mailto:[email-masked]] 
> Sent: Tuesday, June 05, 2001 11:34 AM
> To: [email-masked]
> Subject: Re: sasl-gssapi questions: base32 and context flags
> 
> 
> 
> 
> John Brezak wrote:
> > There should also be some details about the mapping of the SASL 
> > protection profile mapping to the GSSAPI context 
> establishment flags 
> > (GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG).
> 
> I see no mention of either "GSS_C_CONF_FLAG" or 
> "GSS_C_INTEG_FLAG" in RFC 2743.  The appropriate use of 
> conf_req_flag, integ_req_flag, sequence_req_flag, and 
> mutual_req_flag is specified in draft-ietf-cat-sasl-gssapi-05?
> 
> > This should also be extended to
> > cover the use of the context flags in NegTokenInit of 
> SPNEGO and the 
> > GSSAPI Context flags specified in the optimistic protocol.
> 
> Why is such extension necessary?  Does not the SPNEGO draft 
> already specify this?
> 
> Please be more specific as to what is underspecified.  
> Proposed wording would be particularly helpful.
> 

------=_NextPart_000_0047_01C0EDBE.17AD5AE0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0047_01C0EDBE.17AD5AE0--

Date: Tue, 05 Jun 2001 11:35:47 -0700
From: John Gardiner Myers <[email-masked]>
Subject: Re: sasl-gssapi questions: base32 and context flags
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msA95EB37E5B22F7F38F060458
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Brezak wrote:
> Is the base32 encoding method used for anything other than the 10 bytes
> used in the suffix for the gssapi mechanism encoding?

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

lxuWcAUoerIg
--------------msA95EB37E5B22F7F38F060458--

Date: Tue, 05 Jun 2001 11:33:37 -0700
From: John Gardiner Myers <[email-masked]>
Subject: Re: sasl-gssapi questions: base32 and context flags
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms64B1DECBFB315D8F3AE84740
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Brezak wrote:
> There should also be some details about the mapping of the SASL
> protection profile mapping to the GSSAPI context establishment flags
> (GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG).

I see no mention of either "GSS_C_CONF_FLAG" or "GSS_C_INTEG_FLAG" in
RFC 2743.  The appropriate use of conf_req_flag, integ_req_flag,
sequence_req_flag, and mutual_req_flag is specified in
draft-ietf-cat-sasl-gssapi-05?

> This should also be extended to
> cover the use of the context flags in NegTokenInit of SPNEGO and the
> GSSAPI Context flags specified in the optimistic protocol.

Why is such extension necessary?  Does not the SPNEGO draft already
specify this?

Please be more specific as to what is underspecified.  Proposed wording
would be particularly helpful.
--------------ms64B1DECBFB315D8F3AE84740
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

--------------ms64B1DECBFB315D8F3AE84740--

Date: Tue, 05 Jun 2001 11:10:53 -0700
From: John Gardiner Myers <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-ietf-cat-sasl-gssapi-05.txt]
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms7461933FEF768432B9D970A3
Content-Type: multipart/mixed;
 boundary="------------590D9E1E9D1A421A4F835900"

This is a multi-part message in MIME format.
--------------590D9E1E9D1A421A4F835900
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This I-D announcement didn't get copied to this list.
--------------590D9E1E9D1A421A4F835900
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Path: pixie.netscape.com!gateway
From: [email-masked]
Newsgroups: mcom.list.cat-ietf
Subject: I-D ACTION:draft-ietf-cat-sasl-gssapi-05.txt
Date: 1 Jun 2001 10:47:10 GMT
Organization: Netscape Communications Corporation
Sender: [email-masked]
Approved: [email-masked]
Message-ID: <[email-masked]>
Reply-To: [email-masked]
NNTP-Posting-Host: 205.217.237.94
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"

--NextPart

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

	Title		: SASL GSSAPI mechanisms
	Author(s)	: J. Myers
	Filename	: draft-ietf-cat-sasl-gssapi-05.txt
	Pages		: 14
	Date		: 31-May-01
	
The Simple Authentication and Security Layer [SASL] is a method for
adding authentication support to connection-based protocols.  This
document describes the method for using the Generic Security Service
Application Program Interface [GSSAPI] in the Simple Authentication
and Security Layer [SASL].
This document amends section 7.2 of RFC 2222 [SASL], the definition
of the 'GSSAPI' SASL mechanism.

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

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-cat-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-cat-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-cat-sasl-gssapi-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-cat-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--

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

--------------590D9E1E9D1A421A4F835900--

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

--------------ms7461933FEF768432B9D970A3--

Date: Tue, 05 Jun 2001 19:46:26 +1000
To: John Gardiner Myers <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: [email-masked]
Sender: [email-masked]

At 02:26 PM 6/4/01 -0700, John Gardiner Myers wrote:

>"Raif S. Naffah" wrote:
> > of course.  but this is not the issue.  the issue, is how a protocole
> > passes the contents of the authorization-id to a mechanism...

the keyword here is passes. not "internally repesent" as you mentioned in 
your message, or any other situation.

for mechanisms to be inter-operable between different implementations, and 
inter-changeable between protocols, the authorization id has to be passed 
from a protocol to a mechanism in a programming language, and an encoding 
neutral way.

octet sequences are such an alternative; strings are not.

(i'll pass on the discussion about Java-CORBA-C).

cheers;
rsn

Date: Mon, 04 Jun 2001 20:33:46 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: John Brezak <[email-masked]>
CC: [email-masked]
Subject: Re: sasl-gssapi questions: base32 and context flags
Sender: [email-masked]

John Brezak wrote:

> Is the base32 encoding method used for anything other than the 10 bytes
> used in the suffix for the gssapi mechanism encoding? If so why go
> through all of this complexity - why not just use the text version of
> the OID for the mechtype?

IMHO, there are two reasons:

1). Allowed characters for mechanism name are uppercase letters, digits,
"-" and "_" (thus "." is not allowed)
2). There is a limit of 20 characters for mechanism name. Having prefix
"GSS-" this leaves 16 characters.

__________________________________________
Alexey Melnikov
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

Date: Mon, 04 Jun 2001 18:43:24 -0700
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: [email-masked]
Sender: [email-masked]

At 06:15 PM 6/4/2001, John Gardiner Myers wrote:
>Please review my message of last Wednesday listing the changes necessary
>for each alternative.  I've also listed additional changes for each
>alternative in my previous message.  I would like to at least get
>consensus on the following points:
>
>* The need to make a decision
>
>* The two alternatives
>
>* The set of changes needed to implement each alternative
>
>Once we have that, we can then evaluate each alternative and hopefully
>come to a decision by the end of the London IETF.

This seems like a reasonable approach.  I note that a
SASL BOF has been approved (we'll met as a WG if we get
that approval prior to IETF#51).  Once we get a scheduled,
I'll post more info.

What concerns me most is scope.  We need to be sure we are fixing
SASL, not codifying limitations of certain mechanisms, profiles,
and implementations thereof.

I will again review you past post and respond more with what
changes I believe are needed for each approach to the problem
(as opposed to entering into a debate over which approach is
more appropriate).

Kurt

Kurt

content-class: urn:content-classes:message
Subject: sasl-gssapi questions: base32 and context flags
Date: Mon, 4 Jun 2001 18:21:07 -0700
From: "John Brezak" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Is the base32 encoding method used for anything other than the 10 bytes
used in the suffix for the gssapi mechanism encoding? If so why go
through all of this complexity - why not just use the text version of
the OID for the mechtype?

There should also be some details about the mapping of the SASL
protection profile mapping to the GSSAPI context establishment flags
(GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG). This should also be extended to
cover the use of the context flags in NegTokenInit of SPNEGO and the
GSSAPI Context flags specified in the optimistic protocol.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Brezak                       * mailto:[email-masked]
Microsoft Corporation        * 425-936-2602
One Microsoft Way
Redmond, WA 98052

Date: Mon, 04 Jun 2001 18:15:41 -0700
From: John Gardiner Myers <[email-masked]>
Subject: Re: Use of authorization identity
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msDE2E33CE0C9FCC3A28BBC2ED
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> Just for clarity, I believe the base specification should
> say that the form of an authorization identity is profile
> specific and mechanisms should be prepared to transfer
> an sequence of octets representing the authorization identity.

This is equivalent to saying that the authorization identity is an octet
string.

Please review my message of last Wednesday listing the changes necessary
for each alternative.  I've also listed additional changes for each
alternative in my previous message.  I would like to at least get
consensus on the following points:

* The need to make a decision

* The two alternatives

* The set of changes needed to implement each alternative

Once we have that, we can then evaluate each alternative and hopefully
come to a decision by the end of the London IETF.
--------------msDE2E33CE0C9FCC3A28BBC2ED
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

--------------msDE2E33CE0C9FCC3A28BBC2ED--

Date: Mon, 04 Jun 2001 17:53:52 -0700
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: [email-masked]
Sender: [email-masked]

Just for clarity, I believe the base specification should
say that the form of an authorization identity is profile
specific and mechanisms should be prepared to transfer
an sequence of octets representing the authorization identity.

Kurt

Date: Mon, 04 Jun 2001 17:30:58 -0700
From: John Gardiner Myers <[email-masked]>
Subject: Re: Use of authorization identity
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms3FA43037FCE870209BEAF83D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> >The framework itself needs to provide enough of a definition of
> >"authorization identity" to provide interoperability.
> 
> Interoperability at what level?

Implementations and protocol profiles need to know what kind of values
can be transmitted by mechanisms.  If a protocol profile expects to be
able to transmit an octet string, implementations of that protocol
profile will not work when used with mechanisms that expect to transmit
character strings.

> At the protocol level, it
> really needed same much as it is the mechanism which defines
> how to encode the authzid.

I cannot parse this sentence.

> Mechanisms can place all kinds
> of restrictions upon their values (such as length limits).

This perhaps argues that such limits (or minimum maximums) be specified
in the base spec.

> >> I agree that it would be nice if more mechanisms were less
> >> restrictive.  Unfornately, most mechanisms are quite
> >> restrictive.  In fact, most mechanisms cannot handle UTF-8
> >> strings without significant restrictions.
> >
> >Could you list the mechanisms you are talking about?  CRAM-MD5, LOGIN,
> >and ANONYMOUS cannot handle any non-empty authorization id, they don't
> >count.
> 
> SecureID [RFC2808] and OTP [RFC2444] restricts authorization
> identity to "printable" UTF-8 and has a length limit of 255 octets.
> PLAIN is similar, but only discourages "non-visible" characters.

This can hardly be considered "quite restrictive".  Printability and
normalization constraints probably belong in the base specification. 
The base specification should probably also recommend a minumum maximum
length.

> >This is precisely what we are trying to fix.
> 
> Guidance is fine, it's a defining a SASL-wide authorization
> identity encoding I have problem with.

We have to define it as something.  Right now, the choices are octet
strings or character strings.

> >"Arbitrary form" does not work.
> 
> It works just fine.

It does not work, as shown in the following text.
 
> >Octet strings and character strings are
> >like apples and oranges.
> 
> Yes, so?  An octet string can be encoded as a character string.
> A character string can be encoded as an octet string.

One can be encoded in the other, but to do so one has to specify the
encoding.  In either direction, there are many possible encodings to
use.

If some protocol or interface has a field that takes an octet string,
you cannot put a character string in that field without specifying the
method of encoding the character string as an octet string.  Similarly,
if some protocol or interface has a field that takes a character string,
you cannot put an octet string in that field without specifying the
method of encoding the octet string as a character string.

If a protocol or interface has a field that you want to put a character
string into, you need to know whether that field is a character string,
octet string, or something else so that you know what kind of encoding,
if any, you need to specify and apply.  Protocols cannot have fields of
arbitrary form--there must be some common understanding of base type for
communication to be possible.

> What is important is that each mechanism be able to transfer a profile
> specific authorization identity.

To do that, mechanisms and protocols need to have a common understanding
of what the bounds are on the set of possible authorization identities. 
If a protocol profile expects to supply octet strings, but a mechanism
expects to transfer character strings, things will not work.  Neither
will be responsible for doing the necessary encoding.

> >> > Authorization ids are character strings
> >>
> >> I assume by character strings you mean UTF-8 encoded
> >> ISO 10646 character strings.
> >
> >No.  I mean ordered sequences of characters.  The characters do come
> >from the ISO 10646 character set, but the base specification has no need
> >of the integer mapping of the ISO 10646 coded character set.  The UTF-8
> >character encoding scheme is not relevant to the base SASL
> >specification.
> 
> Likewise, the base specification could say the authorization
> identity is an octet string as it quite irrelevant to the base SASL
> specification as to what the octets represent.

The text you were replying to was listing the changes needed if we
decide that authorization ids are character strings.  In that context,
"authorization ids are character strings" is a postulate.

The section of that message that takes the postulate "authorization ids
are octet strings" is later in that message, under the heading
"Authorization ids are octet strings:".

So for necessary changes, for either choice, we probably need the base
specification to address length restrictions that mechanisms impose on
the authorization id.  We also need to address nonprintable characters
and normalization--for the "character string" case this needs to be done
in the base spec, for the "octet string" case this needs to be done in
each protocol profile that encodes characters into the authorization id.
--------------ms3FA43037FCE870209BEAF83D
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

--------------ms3FA43037FCE870209BEAF83D--

Date: Mon, 04 Jun 2001 16:15:50 -0700
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: [email-masked]
Sender: [email-masked]

At 03:07 PM 6/4/2001, John Gardiner Myers wrote:
>"Kurt D. Zeilenga" wrote:
>> In my opinion, SASL should just provide a framework for
>> authentication and security services.  The framework itself
>> shouldn't define the encoding of an authorization identity
>> or otherwise restrict authorization identity forms.
>
>The framework itself needs to provide enough of a definition of
>"authorization identity" to provide interoperability.

Interoperability at what level?  At the protocol level, it
really needed same much as it is the mechanism which defines
how to encode the authzid.  Mechanisms can place all kinds
of restrictions upon their values (such as length limits).

>> I agree that it would be nice if more mechanisms were less
>> restrictive.  Unfornately, most mechanisms are quite
>> restrictive.  In fact, most mechanisms cannot handle UTF-8
>> strings without significant restrictions.
>
>Could you list the mechanisms you are talking about?  CRAM-MD5, LOGIN,
>and ANONYMOUS cannot handle any non-empty authorization id, they don't
>count. 

SecureID [RFC2808] and OTP [RFC2444] restricts authorization
identity to "printable" UTF-8 and has a length limit of 255 octets.
PLAIN is similar, but only discourages "non-visible" characters.

DIGEST-MD5 (RFC2831) supports arbitrary UTF-8 characters (including NUL).

EXTERNAL and GSSAPI, of course, support arbitrary octet strings.

> 
>> The problem, as I see it, is that RFC 2222 should have provided
>> more guidance.
>
>This is precisely what we are trying to fix.

Guidance is fine, it's a defining a SASL-wide authorization
identity encoding I have problem with.

>> I believe it should say "Mechanisms SHOULD
>> be capable of transferring authorization identities of arbitrary
>> form.
>
>"Arbitrary form" does not work.

It works just fine.

>Octet strings and character strings are
>like apples and oranges.

Yes, so?  An octet string can be encoded as a character string.
A character string can be encoded as an octet string.  

>We need to pick one, the other, or some as yet
>unproposed other option.

What is important is that each mechanism be able to transfer a profile
specific authorization identity.

>> Escaping mechanisms SHOULD be provided to encode otherwise
>> non-transferable octets into a transferable form.  That is,
>> DIGEST-MD5 (and other limiting mechanisms) should provide an
>> escaping mechanism.
>
>Adding an escaping mechanism to DIGEST-MD5 is not sufficient.  Each of
>the changes I listed previously is necessary in order to make
>authorization ids be octet strings.  If authorization ids are octet
>strings, then mechanisms cannot specify a charset for the authorization
>id and any such specifications need to be removed.

>> > Authorization ids are character strings
>> 
>> I assume by character strings you mean UTF-8 encoded
>> ISO 10646 character strings.
>
>No.  I mean ordered sequences of characters.  The characters do come
>from the ISO 10646 character set, but the base specification has no need
>of the integer mapping of the ISO 10646 coded character set.  The UTF-8
>character encoding scheme is not relevant to the base SASL
>specification.

Likewise, the base specification could say the authorization
identity is an octet string as it quite irrelevant to the base SASL
specification as to what the octets represent.

Kurt

Date: Mon, 04 Jun 2001 15:11:16 -0700
From: John Gardiner Myers <[email-masked]>
Subject: Re: Use of authorization identity
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms1C6AC1489B8EE2C793F5A102
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> BTW, do we actually have two independently developed
> interoperable implementations of SASL proxy authorization
> features?

I recall being informed that we do.  I believe Lawrence Greenfield
volunteered to put together the implementation report.
--------------ms1C6AC1489B8EE2C793F5A102
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

--------------ms1C6AC1489B8EE2C793F5A102--

Date: Mon, 04 Jun 2001 15:07:39 -0700
From: John Gardiner Myers <[email-masked]>
Subject: Re: Use of authorization identity
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms59815060D05EE4A43A41AC16
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> In my opinion, SASL should just provide a framework for
> authentication and security services.  The framework itself
> shouldn't define the encoding of an authorization identity
> or otherwise restrict authorization identity forms.

The framework itself needs to provide enough of a definition of
"authorization identity" to provide interoperability.

> I agree that it would be nice if more mechanisms were less
> restrictive.  Unfornately, most mechanisms are quite
> restrictive.  In fact, most mechanisms cannot handle UTF-8
> strings without significant restrictions.

Could you list the mechanisms you are talking about?  CRAM-MD5, LOGIN,
and ANONYMOUS cannot handle any non-empty authorization id, they don't
count. 
 
> The problem, as I see it, is that RFC 2222 should have provided
> more guidance.

This is precisely what we are trying to fix.

> I believe it should say "Mechanisms SHOULD
> be capable of transferring authorization identities of arbitrary
> form.

"Arbitrary form" does not work.  Octet strings and character strings are
like apples and oranges.  We need to pick one, the other, or some as yet
unproposed other option.

> Escaping mechanisms SHOULD be provided to encode otherwise
> non-transferable octets into a transferable form.  That is,
> DIGEST-MD5 (and other limiting mechanisms) should provide an
> escaping mechanism.

Adding an escaping mechanism to DIGEST-MD5 is not sufficient.  Each of
the changes I listed previously is necessary in order to make
authorization ids be octet strings.  If authorization ids are octet
strings, then mechanisms cannot specify a charset for the authorization
id and any such specifications need to be removed.

> > Authorization ids are character strings
> 
> I assume by character strings you mean UTF-8 encoded
> ISO 10646 character strings.

No.  I mean ordered sequences of characters.  The characters do come
from the ISO 10646 character set, but the base specification has no need
of the integer mapping of the ISO 10646 coded character set.  The UTF-8
character encoding scheme is not relevant to the base SASL
specification.

> I note that many existing
> mechanisms cannot transfer arbitrary non-NUL UTF-8 strings.
> So, either further restrictions or escaping mechanisms will be
> needed here.  As soon as you provide an escaping mechanism,
> you might as well support arbitrary octet strings as any
> decent escaping mechanism will support such.

It does not make sense talking about including octets in character
strings.  Octets are not characters.
--------------ms59815060D05EE4A43A41AC16
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

--------------ms59815060D05EE4A43A41AC16--

Date: Mon, 04 Jun 2001 14:26:49 -0700
From: John Gardiner Myers <[email-masked]>
Subject: Re: Use of authorization identity
To: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msD74EC5E4CA39405DA71609D5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Raif S. Naffah" wrote:
> of course.  but this is not the issue.  the issue, is how a protocole
> passes the contents of the authorization-id to a mechanism.
> 
> to wit, consider the case of Protocole P1 that uses mechanism M, and
> another Protocole P2 that uses the same mechanism; ie. M.

In a direct-mail exchange, you clarified that P1, P2, and M are
implementations, not protocol profiles.

> furthermore, P1
> mandates the use of UTF-8 as the encoding of its authorization-id, while
> P2, mandates ASCII.

It is not the place of implementations to make such across-the-board
mandates.  While P1 and P2 may be designed to use particular encodings
internally, whenever they communicate with some external code they need
to use the encoding that is specified by the interface through wich they
communicate.

> since mechanisms have to provide, on one side of a
> communication channel an authorization-id, they should accept such a value
> from the other side at some time during their life-time; probably at their
> instantiation/start of a session.
> 
> now how does the API for such a mechanism look like?
> 
> should it be UTF-8, ASCII, both?

This is something that is defined by the SASL API those implementations
choose.

> remember, we cannot just say it's a
> "string" since a C string does not mean the same thing as a Java string for
> example.

It doesn't make sense to talk about a Java application directly calling
a C implementation.  Similarly, it doesn't make sense to talk about a
Sparc binary directly calling an X86 binary.  String encodings are the
least of your worries here.

> which also means that P1 cannot use inter-changeably a C
> implementation of M with a Java one (eg. through CORBA/IDL).

For a Java implementation to call C code, it must go through some sort
of inter-language mapping layer.  Such a layer has to deal with a number
of language mapping issues, including differing string representations
and ownership models.

> it's for this reason that i am arguing for a clear text in the
> specifications that state that Mechanisms should handle authorization-ids
> as possibly null octet sequences.

This does not follow.  Even if we were to break with longstanding IETF
design principles and mandate that all implementations internally
represent certain strings in a certain way, there is no argument offered
that such strings need to be defined as octet sequences.
--------------msD74EC5E4CA39405DA71609D5
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

--------------msD74EC5E4CA39405DA71609D5--

Date: Sun, 03 Jun 2001 15:17:39 -0700
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: [email-masked]
Sender: [email-masked]

BTW, do we actually have two independently developed
interoperable implementations of SASL proxy authorization
features?

Kurt

Date: Sun, 03 Jun 2001 15:07:44 -0700
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of authorization identity
Cc: [email-masked]
Sender: [email-masked]

In my opinion, SASL should just provide a framework for
authentication and security services.  The framework itself
shouldn't define the encoding of an authorization identity
or otherwise restrict authorization identity forms.

I agree that it would be nice if more mechanisms were less
restrictive.  Unfornately, most mechanisms are quite
restrictive.  In fact, most mechanisms cannot handle UTF-8
strings without significant restrictions.

The problem, as I see it, is that RFC 2222 should have provided
more guidance.  I believe it should say "Mechanisms SHOULD
be capable of transferring authorization identities of arbitrary
form.  Escaping mechanisms SHOULD be provided to encode otherwise
non-transferable octets into a transferable form.  That is,
DIGEST-MD5 (and other limiting mechanisms) should provide an
escaping mechanism. 

> Authorization ids are character strings

I assume by character strings you mean UTF-8 encoded
ISO 10646 character strings.  I note that many existing
mechanisms cannot transfer arbitrary non-NUL UTF-8 strings.
So, either further restrictions or escaping mechanisms will be
needed here.  As soon as you provide an escaping mechanism,
you might as well support arbitrary octet strings as any
decent escaping mechanism will support such.  And if you are
going to allow arbitrary octet strings via escaping, you
might as well allow mechanisms which don't need such escaping
to carry the octets without any escaping.

Kurt