Subject: draft-murchison-sasl-login-00.txt

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Aug 2003 10:08:06 -0400

I just submitted the following document:

ftp://ftp.oceana.com/pub/drafts/draft-murchison-sasl-login-00.txt

This is an attempt to document the intended and currently deployed 
functionality of the obsolete LOGIN SASL mechanism.  If anyone is aware 
of additional/different deployed behavior, we'd be interested in hearing 
about it.

We are aware that some servers allow the username to be sent as an 
initial response (for those protocol that support it), but we haven't 
yet decided if we want to document that.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Fri, 29 Aug 2003 10:08:06 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: SASL mailing list <[email-masked]>
Subject: draft-murchison-sasl-login-00.txt
Sender: [email-masked]

I just submitted the following document:

ftp://ftp.oceana.com/pub/drafts/draft-murchison-sasl-login-00.txt

This is an attempt to document the intended and currently deployed 
functionality of the obsolete LOGIN SASL mechanism.  If anyone is aware 
of additional/different deployed behavior, we'd be interested in hearing 
about it.

We are aware that some servers allow the username to be sent as an 
initial response (for those protocol that support it), but we haven't 
yet decided if we want to document that.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 27 Aug 2003 17:37:02 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: GSS-SPNEGO and relative mechanism strengths
Sender: [email-masked]

The SASL GSS-SPNEGO mechanism, on the client side, needs to know the
mechlist that the client got from the server and the SSF values
associated with each GSS-API mechanism available to decide which
mechanisms to negotiate.

(See section 4 of draft-ietf-cat-sasl-gssapi-05.txt.)

How can a SASL GSS-SPNEGO mechanism client-side implementation determine
the SSF values that would be associated with each GSS-API mechanism
without hardcoding mechanism OIDs and SSF values?

A GSS-API extension, GSS_Inquire_mech(), say, that allows applications
to determine the set of features supported by a given mechanism would
help.

The relative strengths of GSS-API mechanisms that support
confidentiality (SSF values > 1) can't really be determined statically,
or even dynamically (it is not even possible to determine what QoPs will
be available with what mech until a context is established), so ideally,
if GSS_Inquire_mech() says anything about mechanism strength at all then
that should be configurable.

(And if GSS_Inquire_mech() has nothing at all to say about mech
 strength, then truly generic SASL GSS-SPNEGO mechanism client-side
 implementation might have to assume SSF values for mechs that provide
 confidentiality, perhaps a single value for all such GSS-API mechs.)

Cheers,

Nico
-- 

Date: Tue, 26 Aug 2003 21:01:18 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: IMAP mailing list <[email-masked]>, SASL mailing list <[email-masked]>
Subject: NTLM authentication documentation
Sender: [email-masked]

Resurrecting a badly beaten horse...

Is there any interest in having NTLM authentication (as a SASL mech and 
possibly as an HTTP mech) documented as an Informational RFC?  I believe 
I have enough existing documentation (Eric Glass' 
http://davenport.sourceforge.net/ntlm.html being the best) and enough 
implementation experience writing the CMU SASL NTLM plugin to write a 
fairly complete document.

I would probably use Eric's documentation of the message formats and 
the algorithms for the password hashes from Paul Leach's CIFS draft.

I'm especially interested in hearing from the Microsoft folks w.r.t. any 
IPR problems.  Since Paul has already made the algorithms available in 
an I-D, I guess the only outstanding issue would be the message formats.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Thu, 21 Aug 2003 23:49:10 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: SRP Mechanism & GSS-API domain-based names (was Re: GSSAPI and domain-based names)
Sender: [email-masked]

The SRP GSS-API mechanism that's been discussed here is one that could
use domain-based names.

As we've seen, though SRP itself provides for mutual authentication, the
proposed mechanism does not deal with acceptor principal naming,
therefore it can't be said to provide mutual authentication with any
acceptor name other than the anonymous name.

This can be addressed by salting the password/verifier with the name of
the acceptor principal, but this would mean generating a verifier
per-{user host} tuple, which does not scale well.

So an SRP mechanism could benefit from domain-based names in
environments where verifiers are generated per-{user service} or {user
domain} tuples, or any such tuple that is less numerous than {user host}
tuples are.  That is, one could get away with fewer verifiers per-user
by using domain-based names.

This possibility complicates the way in which an application decides
which name type to use for an acceptor, but not much.  As I've said, I
think LDAP ought to use domain-based names, but existing implementations
may not, so for interop any implementation that supports domain-based
names will also have to be configurable to use host-based names.  Such a
configuration parameter might be a per-mechanism parameter (and one
might even have a per-domain configuration too).

I hope this and my previous post answers Sam's question about when to
use which name type.

Cheers,

Nico
-- 

Date: Thu, 21 Aug 2003 21:39:06 -0700
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked]
Subject: Re: GSSAPI and domain-based names
Sender: [email-masked]

On Thu, Aug 21, 2003 at 09:38:43PM -0400, Jeffrey Hutzelman wrote:
> Of course, this only describes the name syntax at the GSSAPI layer.  In the 
> case of the Kerberos mechansm, this would presumably map to principal names 
> with more than one component, like 
> http/fully.qualified.host.name/[email-masked], as Paul Leach 
> described.

Of course, I was only describing the proposed GSS-API name syntax.

> I'd be interested in hearing what sort of GSSAPI name types Microsoft is 
> using that map to these principal names, if any.  And I'd also like to hear 
> whether these are truly three-component principal names, or 
> single-component names with '/' embedded in the instance.

Me too.

> In any case, I'm somewhat concerned as to whether defining a new GSSAPI 
> name type is in scope for this working group.  Actually, I'm more concerned 
> that if this work happens here, we might inadvertently exclude folks who 
> care about this issue but otherwise have no interest in SASL.  As long as 
> we make sure these folks have a chance to participate, I'm all in favor of 
> doing this work here -- it's a real problem and I'd definitely like to see 
> a solution.

No kidding.  I think that given the lack of a CAT WG (or KITTEN, as
you've suggested - no I haven't come up with something that it could be
the acronym for) we can do GSS-API work elsewhere, but we ought to give
other WGs heads ups, and even Last-Call in multiple WGs.  E.g., the
NFSv4 WG I-D on CCM - the Channel Conjunction Mechanism.

Nico
-- 

Date: Thu, 21 Aug 2003 21:38:43 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: [email-masked]
Subject: Re: GSSAPI and domain-based names
Sender: [email-masked]

On Thursday, August 21, 2003 15:25:24 -0700 Nicolas Williams 
<[email-masked]> wrote:

>> Could you please work up an example of this Nico -- say a three system
>> load balanced HTTP cluster?   I'm having a hard time understanding
>> exactly when the name resolution is going to occur and what kerberos
>> principals  will be bound.
>>
>> Sorry for being thick )-:
>
> NP :)
>
> For a load balanced system one would have to use a principal that is
> shared throughout the cluster (that means sharing the rcache too, for
> Kerberos).  So the principal name would be just service@domain or
> service@clustername.
>
> For non-cluster domain-wide services the names might be of the form
> service@domain@host_instance.
>
> I.e., the syntax for domain-based names might be
>
> <service> "@" <domainname> [ "@" <hostname> ]
>
> Where you can share a principal across multiple hosts you'd not use the
> optional hostname instance part.

Of course, this only describes the name syntax at the GSSAPI layer.  In the 
case of the Kerberos mechansm, this would presumably map to principal names 
with more than one component, like 
http/fully.qualified.host.name/[email-masked], as Paul Leach 
described.

I'd be interested in hearing what sort of GSSAPI name types Microsoft is 
using that map to these principal names, if any.  And I'd also like to hear 
whether these are truly three-component principal names, or 
single-component names with '/' embedded in the instance.

In any case, I'm somewhat concerned as to whether defining a new GSSAPI 
name type is in scope for this working group.  Actually, I'm more concerned 
that if this work happens here, we might inadvertently exclude folks who 
care about this issue but otherwise have no interest in SASL.  As long as 
we make sure these folks have a chance to participate, I'm all in favor of 
doing this work here -- it's a real problem and I'd definitely like to see 
a solution.

-- Jeff

Content-class: urn:content-classes:message
Subject: RE: GSSAPI and domain-based names
Date: Thu, 21 Aug 2003 16:15:17 -0700
From: "Paul Leach" <[email-masked]>
To: "Nicolas Williams" <[email-masked]>, "Steve Hole" <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C367FF.6934DF60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

There is lots of implemented art here at MSFT on principal names for
replicated services. I'll attempt a brief intro.

We use "service-type/service-instance/service-name" as the principal name.

The service type might (and is, for Active Directory) "ldap". The service
instance is the host an instance is running on -- "ad1.microsoft.com" might
the the host for one instance of AD. The service-name might be
"microsoft.com" for the LDAP service for Microsoft. (Microsoft's is actually
a hierarchy of LDAP naming contexts, but this might be a real enough example
for a smaller company.)

The overall service principal name (SPN) for this example would thus be:
"ldap/ad1.microsoft.com/microsoft.com" -- this is what is in the "sname"
field of the service ticket.

In the case that a single host runs multiple instances of a service, the
above is elaborated a little bit. The service-instance is
"service-host:instance-within-host". The instance with a host could be the
port number of the separate instance, or it could be anything the
application protocol chooses. (In fact, the whole "service-instance" is just
a convention of the application protocol -- a UUID would work just fine.)

The way our clients of replicated services work is that they look up SRV
records for "service-name" -- in the above example, they might have looked
up _ldap._tcp.microsoft.com and gotten back "ad1.microsoft.com" and
"ad2.microsoft.com" and picked the first one.

Note that the lookup does not have to be secure -- a DNS spoofing attack
that returned "ad3.microsoft.com" as a SRV record would not be backed up by
an entry in the KDC account database with a key that the attacker knew
unless the KDC administrator had entered it there, thus attesting to the
fact that it was a legitimate LDAP server for the "microsoft.com" domain.

(If no SRV records are found, then A records are looked up, and if found,
the form "service-type/service-host" is used. Again, if multiple instances
on a host are allowed, then "service-type/service-host:instance-within-host"
will enable that.)

We use this convention polymorphically across all our GSSAPI (aka SSPI)
providers that do mutual authentication. Not all of them are full function,
however.  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nicolas Williams
> Sent: Thursday, August 21, 2003 3:25 PM
> To: Steve Hole
> Cc: Sam Hartman; [email-masked]
> Subject: Re: GSSAPI and domain-based names
> 
> 
> On Thu, Aug 21, 2003 at 04:22:42PM -0700, Steve Hole wrote:
> > On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams 
> > <[email-masked]> wrote:
> > 
> > > If we go the route of defining a new GSS-API name type we can 
> > > actually do a very neat trick: we can have the name encode the 
> > > service name, the domain name and, optionally, a hostname 
> name (an 
> > > instance of the domain- based service).  This would avoid 
> the replay caching issue.
> > > 
> > > What's the difference between domain-based service names and 
> > > host-based service names?  With host-based service names, if a 
> > > client has to lookup what servers are associated with a 
> domain-wide 
> > > infrastructure/cluster, the resulting principal names 
> won't reflect 
> > > the domain/cluster association, and if the lookup is not 
> secure, well that's a problem.
> > > With domain-based names the client makes sure that the 
> name of the 
> > > domain/cluster it's interested in is part of the 
> principal name and 
> > > so binds the service principal name, no matter how the 
> servers may 
> > > be found, to that domain name.
> > 
> > 
> > Could you please work up an example of this Nico -- say a 
> three system 
> > load balanced HTTP cluster?   I'm having a hard time 
> understanding exactly
> > when the name resolution is going to occur and what kerberos 
> > principals will be bound.
> > 
> > Sorry for being thick )-:
> 
> NP :)
> 
> For a load balanced system one would have to use a principal 
> that is shared throughout the cluster (that means sharing the 
> rcache too, for Kerberos).  So the principal name would be 
> just service@domain or service@clustername.
> 
> For non-cluster domain-wide services the names might be of 
> the form service@domain@host_instance.
> 
> I.e., the syntax for domain-based names might be
> 
> <service> "@" <domainname> [ "@" <hostname> ]
> 
> Where you can share a principal across multiple hosts you'd 
> not use the optional hostname instance part.
> 
> Cheers,
> 
> Nico
> -- 
> 
> 

------=_NextPart_000_0008_01C367FF.6934DF60
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0008_01C367FF.6934DF60--

Date: Thu, 21 Aug 2003 15:25:24 -0700
From: Nicolas Williams <[email-masked]>
To: Steve Hole <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: GSSAPI and domain-based names
Sender: [email-masked]

On Thu, Aug 21, 2003 at 04:22:42PM -0700, Steve Hole wrote:
> On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams 
> <[email-masked]> wrote:
> 
> > If we go the route of defining a new GSS-API name type we can actually
> > do a very neat trick: we can have the name encode the service name, the
> > domain name and, optionally, a hostname name (an instance of the domain-
> > based service).  This would avoid the replay caching issue.
> > 
> > What's the difference between domain-based service names and host-based
> > service names?  With host-based service names, if a client has to lookup
> > what servers are associated with a domain-wide infrastructure/cluster,
> > the resulting principal names won't reflect the domain/cluster
> > association, and if the lookup is not secure, well that's a problem.
> > With domain-based names the client makes sure that the name of the
> > domain/cluster it's interested in is part of the principal name and so
> > binds the service principal name, no matter how the servers may be
> > found, to that domain name.
> 
> 
> Could you please work up an example of this Nico -- say a three system 
> load balanced HTTP cluster?   I'm having a hard time understanding exactly
> when the name resolution is going to occur and what kerberos principals 
> will be bound.
> 
> Sorry for being thick )-:

NP :)

For a load balanced system one would have to use a principal that is
shared throughout the cluster (that means sharing the rcache too, for
Kerberos).  So the principal name would be just service@domain or
service@clustername.

For non-cluster domain-wide services the names might be of the form
service@domain@host_instance.

I.e., the syntax for domain-based names might be

<service> "@" <domainname> [ "@" <hostname> ]

Where you can share a principal across multiple hosts you'd not use the
optional hostname instance part.

Cheers,

Nico
-- 

From: Steve Hole <[email-masked]>
Date: Thu, 21 Aug 2003 16:22:42 -0700
To: Nicolas Williams <[email-masked]>
Subject: Re: GSSAPI and domain-based names
Cc: Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams 
<[email-masked]> wrote:

> If we go the route of defining a new GSS-API name type we can actually
> do a very neat trick: we can have the name encode the service name, the
> domain name and, optionally, a hostname name (an instance of the domain-
> based service).  This would avoid the replay caching issue.
> 
> What's the difference between domain-based service names and host-based
> service names?  With host-based service names, if a client has to lookup
> what servers are associated with a domain-wide infrastructure/cluster,
> the resulting principal names won't reflect the domain/cluster
> association, and if the lookup is not secure, well that's a problem.
> With domain-based names the client makes sure that the name of the
> domain/cluster it's interested in is part of the principal name and so
> binds the service principal name, no matter how the servers may be
> found, to that domain name.

Could you please work up an example of this Nico -- say a three system 
load balanced HTTP cluster?   I'm having a hard time understanding exactly
when the name resolution is going to occur and what kerberos principals 
will be bound.

Sorry for being thick )-:

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

To: Nicolas Williams <[email-masked]>
Cc: [email-masked]
Subject: Re: GSSAPI and domain-based names
From: Sam Hartman <[email-masked]>
Date: Thu, 21 Aug 2003 16:50:34 -0400
Sender: [email-masked]

One thing I think I can do with my chair hat on is suggest what you'd
need to do if you want to make a change to the SASL GSSAPI spec.
Obviously you'd need to get consensus.

But it seems that you would need to specify how the SASL GSSAPI spec
should choose the GSSAPI name it uses, and how it works with GSSAPI
mechanisms that do not support any new name types you introduce.  Then
you would need to fully describe interoperability considerations,
looking at applications written to the old SASL GSSAPI mechanisms as
well as old implementations of the SASL GSSAPI mechanisms.  Then you
need to convince people that your proposed changes are acceptable.

Date: Thu, 21 Aug 2003 13:05:21 -0700
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: GSSAPI and domain-based names
Sender: [email-masked]

On Thu, Aug 21, 2003 at 03:35:58PM -0400, Sam Hartman wrote:
> 
> 
> A few months ago, there was a discussion on the [email-masked] mailing
> list about names for GSSAPI principals. 
> 
> One conclusion from that list is that we may have an incomplete
> handling of the issue in SASL.  I'm going to present the issue and
> step back and let Nico actually argue about solutions.

:)

> The problem is what GSSAPI name do you use for replicated GSSAPI
> services?  For some services, particularly those running on a cluster
> of tightly connected machines, especially with aload balancer
> involved, you want to use the same GSSAPI name.

So, the Kerberos TGS names are what I'd call domain-based service names
- like host-based service names, but with a domain (realm) name instead
of a hostname.

I think the concept of domain/cluster-based service names needs to be
generalized beyond the particular case of the Kerberos TGS.

One way to do this would be to define a new GSS-API name type.  Another
would be to establish the convention of using domain names with the
existing GSS-API host-based service name where domain-based services are
needed.

If we go the route of defining a new GSS-API name type we can actually
do a very neat trick: we can have the name encode the service name, the
domain name and, optionally, a hostname name (an instance of the domain-
based service).  This would avoid the replay caching issue.

What's the difference between domain-based service names and host-based
service names?  With host-based service names, if a client has to lookup
what servers are associated with a domain-wide infrastructure/cluster,
the resulting principal names won't reflect the domain/cluster
association, and if the lookup is not secure, well that's a problem.
With domain-based names the client makes sure that the name of the
domain/cluster it's interested in is part of the principal name and so
binds the service principal name, no matter how the servers may be
found, to that domain name.

> But for other services, especially when an SRV record is used to find
> the specific machine, it seems like you want to avoid requiring the
> instances of the service to use the same GSSAPI name.  This is
> particularly true for some GSSAPI mechanisms such as Kerberos that
> need to share a replay cache.

Replay cache sharing is a related issue, but it's an implementation
detail, a security consideration.  Of course, shared replay caching is
reasonably feasible for some cases, but it may not always be feasible
though.

I think that, for example, LDAP services ought to use domain-based
service names, no matter how the servers are located.  This means that
the LDAP servers for any given domain have to share a replay cache OR
that we really need a domain-based name type with host instances.

> Note that this issue is not unique to GSSAPI.  Other mechanisms such
> as the digest-md5 mechanism specify mildly complicated naming rules,
> where the name the user typed in is combined with the the name from
> the DNS or other location service.
> 
> Two questions:
> 
> 1) Do we want to provide some better handling for this situation in
>    the GSSAPI case?  IT's clear we cannot get away with just using
>    service@name_from_dns.  We can either use
>    service@name_typed_by_user, requiring any replicated service to
>    just deal internally or we could use some new name type.

In the case of LDAP the service name may often not be derived from any
information typed in by the user (e.g., where LDAP is used by a name
service switch).  The domain name could come from local configuration or
from user context (e.g., from a domain-qualified username).  If we're
using a domain-based name type with host instances the hostname can
safely come from an SRV record.

See above.

> 2) Do we want to say anything about this in the base spec?  We aren't
>    designing an API, but we may want to give general guidelines about
>    what bits of information SASL mechanisms can assume they can get
>    from an application, to prevent people designing mechanisms in the
>    future that make unreasonable requirements of multi-mechanisms
>    implementations.

IMO it would be nice to specify a domain based name type for the GSS-API
and the various existing GSS-API mechanisms.  Then amend SASL to require
support for domain-based naming where applications request it and where
the SASL mechanisms support it.

Cheers,

Nico
-- 

To: [email-masked]
Cc: [email-masked]
Subject: GSSAPI and domain-based names
Date: Thu, 21 Aug 2003 15:35:58 -0400 (EDT)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

A few months ago, there was a discussion on the [email-masked] mailing
list about names for GSSAPI principals. 

One conclusion from that list is that we may have an incomplete
handling of the issue in SASL.  I'm going to present the issue and
step back and let Nico actually argue about solutions.

The problem is what GSSAPI name do you use for replicated GSSAPI
services?  For some services, particularly those running on a cluster
of tightly connected machines, especially with aload balancer
involved, you want to use the same GSSAPI name.

But for other services, especially when an SRV record is used to find
the specific machine, it seems like you want to avoid requiring the
instances of the service to use the same GSSAPI name.  This is
particularly true for some GSSAPI mechanisms such as Kerberos that
need to share a replay cache.

Note that this issue is not unique to GSSAPI.  Other mechanisms such
as the digest-md5 mechanism specify mildly complicated naming rules,
where the name the user typed in is combined with the the name from
the DNS or other location service.

Two questions:

1) Do we want to provide some better handling for this situation in
   the GSSAPI case?  IT's clear we cannot get away with just using
   service@name_from_dns.  We can either use
   service@name_typed_by_user, requiring any replicated service to
   just deal internally or we could use some new name type.

2) Do we want to say anything about this in the base spec?  We aren't
   designing an API, but we may want to give general guidelines about
   what bits of information SASL mechanisms can assume they can get
   from an application, to prevent people designing mechanisms in the
   future that make unreasonable requirements of multi-mechanisms
   implementations.

--Sam

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-02.txt
Date: Tue, 19 Aug 2003 15:35: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		: Simple Authentication and Security Layer (SASL)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sasl-rfc2222bis-02.txt
	Pages		: 18
	Date		: 2003-8-19
	
SASL provides a method for adding authentication support with an
optional security layer to connection-based protocols.  It also
describes a structure for authentication mechanisms.  The result is
an abstraction layer between protocols and authentication mechanisms
such that any SASL-compatible authentication mechanism can be used
with any SASL-compatible protocol.
This document describes how a SASL authentication mechanism is
structured, how a protocol adds support for SASL, defines the
protocol for carrying a security layer over a connection, and defines
the EXTERNAL SASL authentication mechanism.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rfc2222bis-02.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-rfc2222bis-02.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-rfc2222bis-02.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 05 Aug 2003 21:11:18 +0100
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: Draft minutes
Sender: [email-masked]

Very good notes indeed.

Sam Hartman wrote:

> Please send in comments or corrections by next Tuesday.  I will send
> in for proceedings shortly after that point.
>
> IETF SASL WG meeting Minutes
> ==========================
>
> Tuesday 15 July 2003
> 3:45pm
> chairs:    Sam Hartman <[email-masked]> Kurt Zeilenga 
> <[email-masked]>
> scribe: Luke Howard <[email-masked]>
>
> 2222bis
> =======
>
> - Alexei noted that he has published a subsequent revision of
>   2222bis; minor editorial issues remain
> - Clarification of empty authorization identities
> - Alexei will do a final revision of the document in the first
>   week of August after which it can go to last call
>
As I haven't received any comments I haven't done any work ;-).

Alexey