Subject: Re: IETF 53 SASL bar BoF minutes

From: Laurence Lundblade <[email-masked]>
Date: Thu, 28 Mar 2002 10:11:38 -0800

At 11:54 PM 3/24/2002 -0800, RL 'Bob' Morgan wrote:

>There was discussion of the buffer size issue.  Some application
>protocols limit how much data can be sent in an application PDU, eg
>NNTP and SMTP.  This is a problem if a security mechanism needs to
>send more data than this in its message.  One approach is to say that
>app profiles need to specify methods to send unlimited amounts of
>data, but this opens up implementations to DoS attacks.  So a
>"minimax" number needs to be picked: application profiles need to be
>able to send at least N bytes, and mechanisms need to be able to work
>while sending at most N bytes (or potentially fail with some compliant
>app implementations).  A number of 4K was proposed, but this could
>easily be too low if a security mechanism sends certificates, as some
>do.  The group settled on 64K as being reasonable for this.  This
>means 64K of decoded data, hence potentially more on the wire if, say,
>base64 encoding is used.  In any case wording should be added to warn
>implementors about potential DoS attacks.

I'm a bit out of date on SASL at the moment, but I do want to make a 
general comment. Over the last few years I've worked on HTTP, POP, and SMTP 
for PalmOS and for lower end CDMA handsets. In particular I've got these 
protocols running with SSL. These environments don't have much heap RAM, in 
particular the old PalmOS devices and the low end CDMA devices. Usually the 
RAM is less than 70Kb.

Most of these protocols can be implemented with very little RAM. Our SMTP 
client for example uses on the order of 3Kb. The major exception is SSL 
which requires a 16Kb buffer so a record can be accumulated and it's 
integrity hash checked. There's not really any way around this. You just 
have to have a 16Kb buffer.

So, if the length we're dealing with here in SASL is for a record over 
which a signature or hash is computed then I'd object to 64Kb on the 
grounds that it will be difficult to implement on small low end devices. It 
will cause problems that almost no other internet protocol causes for these 
handsets. 16Kb is big, but manageable and already a requirement for SSL.

To be completely specific, I'm worried about handset that have Qualcomm's 
Brew API in them. Most of Brew is based on open Internet standards (no 
WAP). We've got lots of applications and protocols running on devices that 
have on the order of 70Kb of RAM available. Brew is targeted to run on low 
end (less than $100) handsets, these have less RAM because costs is reduced 
by having smaller memory parts. I expect there's similar issues for GSM and 
wireless phone application environments.

LL

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 28 Mar 2002 14:17:26 -0500

Date: Thu, 28 Mar 2002 10:11:38 -0800
   From: Laurence Lundblade <[email-masked]>
[...]
   So, if the length we're dealing with here in SASL is for a record over 
   which a signature or hash is computed then I'd object to 64Kb on the 
   grounds that it will be difficult to implement on small low end devices. It 
   will cause problems that almost no other internet protocol causes for these 
   handsets. 16Kb is big, but manageable and already a requirement for SSL.

There's no need for a particular implementation to support 64Kb if the
underlying SASL mechanisms that implementation supports never need to
send/receive 64Kb.  The 64Kb requirement is a requirement on the
protocol profile, not a requirement on implementations.

If the implementation wants to have a fully-pluggable SASL module,
then it might need to support 64Kb so that any future SASL mechanism
will work.  If you're implementing to 3 specific SASL mechanisms, you
can implement to their individual requirements.

Larry

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 28 Mar 2002 12:11:52 -0800

>can implement to their individual requirements.

Maybe you've been over all this stuff (point me to an archive and accept my 
apologies for beating the horse)

If all the good/useful/interesting mechanisms require 64Kb records, then 
the small devices are excluded and forced to go off and do special WAP-SASL 
mechanisms. On the other hand if mechanism with 64Kb records are just for 
very specific apps, then we're fine. I'm not really sure where reality lies.

Is the gain (presumably efficiency) from 64Kb worth the potential exclusion 
of small devices and risk of some one proposing WAP-SASL?

I suppose one approach is to recommend 16Kb or smaller, but allow 64Kb if 
you really think you need it.

LL

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 28 Mar 2002 16:23:39 -0500

Date: Thu, 28 Mar 2002 12:11:52 -0800
   From: Laurence Lundblade <[email-masked]>
[...]
   Maybe you've been over all this stuff (point me to an archive and accept my 
   apologies for beating the horse)

The reality is that most of the SASL mechanisms in widespread
deployment require very short exchanges (~500 bytes?).  Some, like
GSSAPI (Kerberos 5) can potentially have longer exchanges depending on
what sort of ticket the KDC gives a client, but I haven't seen any
long exchanges in practice.

We need to specify 64 Kb because that's what GSS requires.  Any
mechanism that wants to be used on small devices should definitely
keep the exchange size in consideration.

Larry

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 28 Mar 2002 14:11:30 -0800

>long exchanges in practice.

I suspected that was the case. Glad to hear it's true.

>keep the exchange size in consideration.

Thanks for the clarification. Sounds like there's no problem here.

LL

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 28 Mar 2002 15:14:43 -0800 (PST)

On Thu, 28 Mar 2002, Lawrence Greenfield wrote:

> We need to specify 64 Kb because that's what GSS requires.

Uh, GSS requires 64KB?  As I recall the discussion, 64KB seemed like a 
good number to handle even the largest cert chains that we could imagine 
people doing, in a X.509-based mechanism like SPKM for example.  Obviously 
in practice a cert chain could grow to any length, in any mechanism that 
uses cert chains, unless that mechanism specifically limits it.  I'm not 
aware that any existing mechanisms say anything about maximum (or 
must-support-at-least) sizes, but maybe some do.

 - RL "Bob"

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 28 Mar 2002 15:56:44 -0800

>must-support-at-least) sizes, but maybe some do.

Seems like you could put 10 or 20 certs in a 16Kb buffer. Are you expecting 
chains longer than that? Seems that would be approaching meaningless in 
terms of any real-world trust.

Also, if the certs are ordered leaf to root and the whole record containing 
is not signed, you can process them with a smaller buffer. The only thing 
about SSL that requires the large buffer is that you have to verify the 
MAC/hash before passing the data along to the next layer.

LL

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 29 Mar 2002 10:56:52 -0800 (PST)

> terms of any real-world trust.

Depends on how big a cert is.  X.509 certs today are pretty minimal, but 
if you look in draft-ietf-pkix-new-part1-12.txt you'll see a whole pile of 
extensions that exist presumably so authorities can start using them, and 
other pkix docs specify yet more extensions.  There will presumably be 
struggle between PKI deployers wanting to jam lotsa stuff into their certs 
(some of which, like name constraints, are arguably essential to the 
overall security of the scheme) and small-device folks saying hey these 
things won't fit.  How big a typical cert will be 5 years from now is 
pretty hard to say, seems to me.

> Also, if the certs are ordered leaf to root and the whole record
> containing is not signed, you can process them with a smaller buffer.
> The only thing about SSL that requires the large buffer is that you have
> to verify the MAC/hash before passing the data along to the next layer.

Umm, I think you're talking about buffer management inside your 
implementation.  The issue at hand is, I think, the size of objects that 
SASL-profiled application protocols have to be able to handle to support 
an acceptable set of security mechanisms.

 - RL "Bob"

---

From: John Gardiner Myers <[email-masked]>
Date: Fri, 29 Mar 2002 12:20:42 -0800

>protocol profile, not a requirement on implementations.
I agree with the former, but the latter is not true.  The protocol 
profile needs to pass the requirement onto implementations.

>deployment require very short exchanges (~500 bytes?).
>
DIGEST-MD5, while typically requiring only short exchanges, has no 
specified limit on token size.  It is possible to construct legal 64Kb 
DIGEST-MD5 tokens (except for the response-auth token) by padding any 
place the # operator occurs in the BNF with extra spaces.  So unless 
DIGEST-MD5 is changed to adopt a smaller maximum size, any 
implementation that implements it will fall under the general SASL-level 
length requirement.

Sometime after the bar BOF (where we arbitrarily chose 64Kb), someone 
claimed that GSSAPI had a limit of 64k on its tokens.  I cannot find 
such a limit in RFC 2744.  I have asked some GSSAPI experts to clarify.

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 29 Mar 2002 12:52:14 -0800

>pretty hard to say, seems to me.

Doing the math, we'd have certs of 3Kb for a chain of length 5, which I'd 
expect is about the long cert chain that would ever be useful. Actually I'd 
agree with you that this is probably too small for a hard limit for all of 
time and space.

>an acceptable set of security mechanisms.

Well, yes I'm talking about buffer management inside an app, and the 
implications for that imposed by the protocol. In my implementation 
experience with large parts POP, MIME, 2822, SMTP, HTML, HTTP and SSL, the 
largest buffer absolutely required is 16Kb. That requirement comes from 
having to process *signed* SSL records. The rest of all of it you can be 
clever about and process in small chunks.

If SSL had chosen to allow 64Kb records of *signed* data, we would have 
been dead trying to implement it on small devices. Those of us that want to 
do native protocols on small devices would have been forced to an alternate 
protocol like WSSL.

So are the certs lists signed as a whole?

If they're not signed then there's no issue and the horse is dead :-)

LL

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 28 Mar 2002 14:17:26 -0500

Larry

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 28 Mar 2002 12:11:52 -0800

LL

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 28 Mar 2002 16:23:39 -0500

Larry

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 28 Mar 2002 14:11:30 -0800

LL

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 28 Mar 2002 15:14:43 -0800 (PST)

- RL "Bob"

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 28 Mar 2002 15:56:44 -0800

LL

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 29 Mar 2002 10:56:52 -0800 (PST)

- RL "Bob"

---

From: John Gardiner Myers <[email-masked]>
Date: Fri, 29 Mar 2002 12:20:42 -0800

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 29 Mar 2002 12:52:14 -0800

LL

Date: Fri, 29 Mar 2002 12:52:14 -0800
To: "RL 'Bob' Morgan" <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Cc: SASL list <[email-masked]>
Sender: [email-masked]

LL

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: maximum token size
Date: Fri, 29 Mar 2002 12:20:42 -0800
Organization: Netscape Communications Corporation
Lines: 27
NNTP-Posting-Host: 10.169.26.59
Sender: [email-masked]

Date: Fri, 29 Mar 2002 10:56:52 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Laurence Lundblade <[email-masked]>
cc: SASL list <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

 - RL "Bob"

Date: Thu, 28 Mar 2002 15:56:44 -0800
To: "RL 'Bob' Morgan" <[email-masked]>, Lawrence Greenfield <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Cc: SASL list <[email-masked]>
Sender: [email-masked]

LL

Date: Thu, 28 Mar 2002 15:14:43 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: SASL list <[email-masked]>, Laurence Lundblade <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

 - RL "Bob"

Date: Thu, 28 Mar 2002 14:11:30 -0800
To: Lawrence Greenfield <[email-masked]>, SASL list <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

LL

Date: Thu, 28 Mar 2002 16:23:39 -0500
From: Lawrence Greenfield <[email-masked]>
To: SASL list <[email-masked]>, Laurence Lundblade <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

Larry

Date: Thu, 28 Mar 2002 12:11:52 -0800
To: Lawrence Greenfield <[email-masked]>, SASL list <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

LL

Date: Thu, 28 Mar 2002 14:17:26 -0500
From: Lawrence Greenfield <[email-masked]>
To: SASL list <[email-masked]>, Laurence Lundblade <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

Larry

Date: Thu, 28 Mar 2002 10:11:38 -0800
To: SASL list <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

LL

Date: Thu, 28 Mar 2002 10:06:30 -0800
To: SASL list <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: PLAIN/ANONYMOUS (was: IETF 53 SASL bar BoF minutes)
Sender: [email-masked]

At 11:54 PM 2002-03-24, RL 'Bob' Morgan wrote:
>ANONYMOUS and PLAIN mechanisms:  Kurt will do them both in one
>document.  PLAIN will specify "must only use with appropriate data
>protection", eg TLS.  EXTERNAL will stay in the base SASL document.
>Note that the LDAP authmeth document shouldn't deprecate the use of
>PLAIN.

I'm having second thoughts about combining ANONYMOUS and PLAIN.
I found that the security considerations for each get easily
confused when combined into one document.  So, I'm currently
editing them as separate I-Ds and should be ready to submit
them soon.

Kurt

Date: Thu, 28 Mar 2002 09:55:40 -0800
To: Tony Hansen <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Subject: SASL/GSSAPI proposed change of base32 alphabet
Cc: [email-masked]
Sender: [email-masked]

At 09:35 AM 2002-03-28, Tony Hansen wrote:
>Are we certain that all sasl developers are actively watching this list?

I am certain that not all SASL developers are actively
watching this list.  But, then, I don't think that's
necessary.  I believe we have sufficient participation
to further this work.

>It seems silly for someone to develop a sasl solution and NOT be
>watching this list, but should we worry about that?

No.  We shouldn't worry about silly people.

I note the process provides amble opportunity for comment.
For these I-Ds, that process will likely include a 4 week
IETF Last Call period.

Kurt

Date: Thu, 28 Mar 2002 12:35:30 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Subject: SASL/GSSAPI proposed change of base32 alphabet
Sender: [email-masked]

I stand corrected.

Are we certain that all sasl developers are actively watching this list?
It seems silly for someone to develop a sasl solution and NOT be
watching this list, but should we worry about that?

	Tony Hansen
	[email-masked]

John Myers wrote:
> 
> Tony Hansen wrote:
> 
> >"Douglas E. Engert" <[email-masked]> just posted a note, saying:
> >
> >       The Globus Project(tm) has the GSI which is a GSSAPI over SSL
> >       and we do have it working with SASL and OpenLDAP. I don't think
> >       the renaming would be a problem, but am cc'ing others in Globus
> >       who might know.
> >
> >I'd say that's sufficient to go the other route.
> >
> A GSSAPI over SSL implementation would not use the encoding defined in
> the GSSAPI over SASL document.  They would instead use the EXTERNAL SASL
> mechanism.

Date: Thu, 28 Mar 2002 09:40:31 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Marshall Rose <[email-masked]>
CC: [email-masked]
Subject: Re: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

Marshall Rose wrote:

> > > There was discussion of sequence of START-TLS vs SASL AUTH.  Different
> > > protocols do this differently (LDAP permits whatever, BEEP says TLS
> > > comes first
> >
> > Actually BEEP says that you can't have both.
>
> no, beep says that if you're running TLS and if you decide to do sasl you may not negotiate a security layer...

That is what I meant (i.e. "you can't have both [security layers present simultaneously]").

> it also says that if you're going to do TLS, you have to do it before you do anything with SASL.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

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

Date: Thu, 28 Mar 2002 06:18:02 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Raif S. Naffah" <[email-masked]>
CC: Tony Hansen <[email-masked]>, SASL list <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

"Raif S. Naffah" wrote:

> does this mean we don't need to work on SASL-SRP or others; eg. SM2?

No, it doesn't.
I don't think DIGEST-MD5 will be ready before the next meeting. I think we
just carry on with what we are doing and let WG form simultaneously.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

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

Date: Thu, 28 Mar 2002 06:03:44 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Tony Hansen <[email-masked]>
CC: SASL list <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

Tony Hansen wrote:

> RL 'Bob' Morgan wrote:
> > SASL bar BoF at IETF 53, 2002-03-18
> >
> > Some SASL-interested folks met, yes, in the entirely too smoky back of
> > the bar at the Minneapolis Hilton.  Attendees included at least:
> > Alexei Melnikov, Kurt Zeilenga, John Myers, Larry Greenfield, Chris
> > Newman, Marshall Rose (who graciously paid for the drinks), RL "Bob"
> > Morgan, Walter Wong, and several others whose names I didn't get.
> > Here are some notes.  I apologize for any issue-mangling.
>
> Pete Resnick, myself

Magnus Nystrom.

> > Still need a Working Group?  Doesn't seem like it.  Need a T-shirt:
> > "SASL: WG free since 1997".  API doc should be Informational when it's
> > done.  It seems reasonable to complete the above core docs in the next
> > few weeks, have a "BoF last call" (or mailing-list last call), then
> > send to IESG.  (But, at SAAG, Jeff Schiller said the WG will be
> > started after all ...)
>
> If we finish the mailing list last call and get the docs sent to the
> IESG before the next meeting, there won't be any need to start the WG.

WG might end up taking on other SASL related stuff.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

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

From: "Raif S. Naffah" <[email-masked]>
To: "Tony Hansen" <[email-masked]>, "SASL list" <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Date: Thu, 28 Mar 2002 20:48:44 +1100
Sender: [email-masked]

does this mean we don't need to work on SASL-SRP or others; eg. SM2?

cheers;
rsn

----- Original Message ----- 
From: "Tony Hansen" <[email-masked]>
To: "SASL list" <[email-masked]>
Sent: Thursday, March 28, 2002 3:18 PM
Subject: Re: IETF 53 SASL bar BoF minutes

> 
> RL 'Bob' Morgan wrote:
> > SASL bar BoF at IETF 53, 2002-03-18
> > ...
> > Still need a Working Group?  Doesn't seem like it.  Need a T-shirt:
> > "SASL: WG free since 1997".  API doc should be Informational when it's
> > done.  It seems reasonable to complete the above core docs in the next
> > few weeks, have a "BoF last call" (or mailing-list last call), then
> > send to IESG.  (But, at SAAG, Jeff Schiller said the WG will be
> > started after all ...)
> 
> If we finish the mailing list last call and get the docs sent to the
> IESG before the next meeting, there won't be any need to start the WG.
> 
> Tony Hansen
> [email-masked]
> 

Date: Wed, 27 Mar 2002 22:09:30 -0800
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: Subject: SASL/GSSAPI proposed change of base32 alphabet
Sender: [email-masked]

Tony Hansen wrote:

>"Douglas E. Engert" <[email-masked]> just posted a note, saying:
>
>	The Globus Project(tm) has the GSI which is a GSSAPI over SSL 
>	and we do have it working with SASL and OpenLDAP. I don't think
>	the renaming would be a problem, but am cc'ing others in Globus
>	who might know. 
>
>I'd say that's sufficient to go the other route.
>
A GSSAPI over SSL implementation would not use the encoding defined in 
the GSSAPI over SASL document.  They would instead use the EXTERNAL SASL 
mechanism.

Date: Wed, 27 Mar 2002 23:22:06 -0500
From: Tony Hansen <[email-masked]>
To: John Myers <[email-masked]>
CC: [email-masked]
Subject: Re: Subject: SASL/GSSAPI proposed change of base32 alphabet
Sender: [email-masked]

"Douglas E. Engert" <[email-masked]> just posted a note, saying:

	The Globus Project(tm) has the GSI which is a GSSAPI over SSL 
	and we do have it working with SASL and OpenLDAP. I don't think
	the renaming would be a problem, but am cc'ing others in Globus
	who might know. 

I'd say that's sufficient to go the other route.

	Tony

John Myers wrote:
> 
> Tony Hansen wrote:
> 
> >Changing the definition of base32 at this point would not be backwards
> >compatible.
> >
> With what implementation or implementations would it not be backwards
> compatible?

Date: Wed, 27 Mar 2002 23:18:57 -0500
From: Tony Hansen <[email-masked]>
To: SASL list <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

RL 'Bob' Morgan wrote:
> SASL bar BoF at IETF 53, 2002-03-18
> 
> Some SASL-interested folks met, yes, in the entirely too smoky back of
> the bar at the Minneapolis Hilton.  Attendees included at least:
> Alexei Melnikov, Kurt Zeilenga, John Myers, Larry Greenfield, Chris
> Newman, Marshall Rose (who graciously paid for the drinks), RL "Bob"
> Morgan, Walter Wong, and several others whose names I didn't get.
> Here are some notes.  I apologize for any issue-mangling.

Pete Resnick, myself

> Still need a Working Group?  Doesn't seem like it.  Need a T-shirt:
> "SASL: WG free since 1997".  API doc should be Informational when it's
> done.  It seems reasonable to complete the above core docs in the next
> few weeks, have a "BoF last call" (or mailing-list last call), then
> send to IESG.  (But, at SAAG, Jeff Schiller said the WG will be
> started after all ...)

If we finish the mailing list last call and get the docs sent to the
IESG before the next meeting, there won't be any need to start the WG.

	Tony Hansen
	[email-masked]

Date: Wed, 27 Mar 2002 09:01:43 -0800
From: Marshall Rose <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: IETF 53 SASL bar BoF minutes
Organization: Dover Beach Consulting, Inc.
Sender: [email-masked]

> > There was discussion of sequence of START-TLS vs SASL AUTH.  Different
> > protocols do this differently (LDAP permits whatever, BEEP says TLS
> > comes first
> 
> Actually BEEP says that you can't have both.

no, beep says that if you're running TLS and if you decide to do sasl you may not negotiate a security layer... it also says that if you're going to do TLS, you have to do it before you do anything with SASL.

/mtr

Date: Wed, 27 Mar 2002 07:48:59 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "RL 'Bob' Morgan" <[email-masked]>
CC: SASL list <[email-masked]>
Subject: Re: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

RL 'Bob' Morgan wrote:

> Respectfully submitted,
>
>  - RL "Bob"
>
> ---
>
> SASL bar BoF at IETF 53, 2002-03-18
>
> Some SASL-interested folks met, yes, in the entirely too smoky back of
> the bar at the Minneapolis Hilton.  Attendees included at least:
> Alexei Melnikov, Kurt Zeilenga, John Myers, Larry Greenfield, Chris
> Newman, Marshall Rose (who graciously paid for the drinks), RL "Bob"
> Morgan, Walter Wong, and several others whose names I didn't get.

> Here are some notes.  I apologize for any issue-mangling.
>
> John will send the latest in-process draft revision of
> draft-myers-saslrev to the list, in glorious nroff (done).  This will
> update saslrev-01 when it's ready.
>
> The other main issues are about the authorization identifier.  The
> saslrev doc specifies default handling of the authzid, so an
> application profile only has to say something about it if it wants to
> modify this default (but it can do this if needed).  It also specifies
> the use of ISO 10646 and Unicode normalization form KC for authzids.
> Question:  can an app profile (eg SACRED) mandate a null authzid?
> Sure, though perhaps short-sighted.  Question:  can an app profile
> say that authzid is, or can be, ignored?  No, not a good idea, if
> authzid is present it has to be used for authorization, or the
> authentication is rejected.
>
> draft-josefsson-base-encoding-03 specifies a BASE32 that is different
> from the BASE32 used in the GSSAPI draft for encoding mechanism OIDs,
> so it will be proposed to change the SASL-GSSAPI doc to use the
> josefsson-specified version.  May be a compatibility issue if anyone
> has implemented to that draft.  Also the josefsson doc is too liberal
> in accepting non-alphabet chars in input string; should say "reject
> unless app profile specifically permits".
>
> The Digest-MD5 SASL mechanism doc:  Chris Newman will either finish it
> soon or hand it off to someone else who will.

Most likely to me.

> ANONYMOUS and PLAIN mechanisms:  Kurt will do them both in one
> document.  PLAIN will specify "must only use with appropriate data
> protection", eg TLS.  EXTERNAL will stay in the base SASL document.
> Note that the LDAP authmeth document shouldn't deprecate the use of
> PLAIN.
>
> There was discussion of sequence of START-TLS vs SASL AUTH.  Different
> protocols do this differently (LDAP permits whatever, BEEP says TLS
> comes first

Actually BEEP says that you can't have both.

> ), so probably nothing to say in base doc.  Of course
> specs also don't say much about TLS transitions in mid-stream.
>
> Still need a Working Group?  Doesn't seem like it.  Need a T-shirt:
> "SASL: WG free since 1997".  API doc should be Informational when it's
> done.  It seems reasonable to complete the above core docs in the next
> few weeks, have a "BoF last call" (or mailing-list last call), then
> send to IESG.  (But, at SAAG, Jeff Schiller said the WG will be
> started after all ...)

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

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

Date: Sun, 24 Mar 2002 23:54:50 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: SASL list <[email-masked]>
Subject: IETF 53 SASL bar BoF minutes
Sender: [email-masked]

Respectfully submitted,

 - RL "Bob"

---

SASL bar BoF at IETF 53, 2002-03-18

Some SASL-interested folks met, yes, in the entirely too smoky back of
the bar at the Minneapolis Hilton.  Attendees included at least:
Alexei Melnikov, Kurt Zeilenga, John Myers, Larry Greenfield, Chris
Newman, Marshall Rose (who graciously paid for the drinks), RL "Bob"
Morgan, Walter Wong, and several others whose names I didn't get.
Here are some notes.  I apologize for any issue-mangling.

John will send the latest in-process draft revision of
draft-myers-saslrev to the list, in glorious nroff (done).  This will
update saslrev-01 when it's ready.

The other main issues are about the authorization identifier.  The
saslrev doc specifies default handling of the authzid, so an
application profile only has to say something about it if it wants to
modify this default (but it can do this if needed).  It also specifies
the use of ISO 10646 and Unicode normalization form KC for authzids.
Question:  can an app profile (eg SACRED) mandate a null authzid?
Sure, though perhaps short-sighted.  Question:  can an app profile
say that authzid is, or can be, ignored?  No, not a good idea, if
authzid is present it has to be used for authorization, or the
authentication is rejected.

draft-josefsson-base-encoding-03 specifies a BASE32 that is different
from the BASE32 used in the GSSAPI draft for encoding mechanism OIDs,
so it will be proposed to change the SASL-GSSAPI doc to use the
josefsson-specified version.  May be a compatibility issue if anyone
has implemented to that draft.  Also the josefsson doc is too liberal
in accepting non-alphabet chars in input string; should say "reject
unless app profile specifically permits".

The Digest-MD5 SASL mechanism doc:  Chris Newman will either finish it
soon or hand it off to someone else who will.

ANONYMOUS and PLAIN mechanisms:  Kurt will do them both in one
document.  PLAIN will specify "must only use with appropriate data
protection", eg TLS.  EXTERNAL will stay in the base SASL document.
Note that the LDAP authmeth document shouldn't deprecate the use of
PLAIN.

There was discussion of sequence of START-TLS vs SASL AUTH.  Different
protocols do this differently (LDAP permits whatever, BEEP says TLS
comes first), so probably nothing to say in base doc.  Of course
specs also don't say much about TLS transitions in mid-stream.

Still need a Working Group?  Doesn't seem like it.  Need a T-shirt:
"SASL: WG free since 1997".  API doc should be Informational when it's
done.  It seems reasonable to complete the above core docs in the next
few weeks, have a "BoF last call" (or mailing-list last call), then
send to IESG.  (But, at SAAG, Jeff Schiller said the WG will be
started after all ...)

Date: Sat, 23 Mar 2002 21:33:08 -0800
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: Subject: SASL/GSSAPI proposed change of base32 alphabet
Sender: [email-masked]

Tony Hansen wrote:

>Changing the definition of base32 at this point would not be backwards
>compatible.
>
With what implementation or implementations would it not be backwards 
compatible?

Date: Sat, 23 Mar 2002 18:18:44 -0500
From: Tony Hansen <[email-masked]>
To: ietf-sasl <[email-masked]>
CC: John Myers <[email-masked]>, Simon Joseffson <[email-masked]>
Subject: Re: Subject: SASL/GSSAPI proposed change of base32 alphabet
Sender: [email-masked]

Changing the definition of base32 at this point would not be backwards
compatible.

Simon already includes two versions of base32 (Canonical and Extended
Hex) in his document. I think it would be better if Josefsson were to
add a description of THIS version of base32, in addition to any others
it has. It could be called the "Visually Safe" base 32 alphabet, because
it does not use any digits that could be mistaken for visually close
letters.

If that were done, then the SASL GSSAPI doc could say it uses that
encoding.

	Tony Hansen
	[email-masked]

"Douglas E. Engert" wrote:
> 
> The Globus Project(tm) has the GSI which is a GSSAPI over SSL and we do have
> it working with SASL and OpenLDAP. I don't think the renaming would be a problem, but am
> cc'ing others in Globus who might know.
> 
> "Booker C. Bense" wrote:
> >
> > Date: Thu, 21 Mar 2002 09:42:48 -0800
> > From: [email-masked] (John Myers)
> > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311
> > X-Accept-Language: en-us, en
> > MIME-Version: 1.0
> > To: [email-masked], ietf-sasl <[email-masked]>
> > Content-Type: text/plain; charset=us-ascii; format=flowed
> > Content-Transfer-Encoding: 7bit
> >
> > I have been requested to replace the base32 specification in the
> > (expired) SASL GSSAPI internet draft with a reference section 3 of
> > draft-josefsson-base-encoding-03.txt.  This would mean a change in the
> > encoding alphabet, breaking any implementations of the existing draft
> > which use mechanisms other than Kerberos or SPNEGO.
> >
> > I would like to know if there exist any deployed implementations that
> > would be so broken.  If there are, I think we would instead want to keep
> > the encoding currently in the SASL GSSAPI draft, calling it by a name
> > other than "base32".
> >
> > -++**==--++**==--++**==--++**==--++**==--++**==--++**==
> > 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]
> 
> --
> 
>  Douglas E. Engert  <[email-masked]>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444

Date: Fri, 22 Mar 2002 11:03:58 -0600
From: "Douglas E. Engert" <[email-masked]>
To: "Booker C. Bense" <[email-masked]>
CC: [email-masked], [email-masked], ietf-sasl <[email-masked]>
Subject: Re: Subject: SASL/GSSAPI proposed change of base32 alphabet
Sender: [email-masked]

The Globus Project(tm) has the GSI which is a GSSAPI over SSL and we do have
it working with SASL and OpenLDAP. I don't think the renaming would be a problem, but am
cc'ing others in Globus who might know. 

"Booker C. Bense" wrote:
> 
> Date: Thu, 21 Mar 2002 09:42:48 -0800
> From: [email-masked] (John Myers)
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311
> X-Accept-Language: en-us, en
> MIME-Version: 1.0
> To: [email-masked], ietf-sasl <[email-masked]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> I have been requested to replace the base32 specification in the
> (expired) SASL GSSAPI internet draft with a reference section 3 of
> draft-josefsson-base-encoding-03.txt.  This would mean a change in the
> encoding alphabet, breaking any implementations of the existing draft
> which use mechanisms other than Kerberos or SPNEGO.
> 
> I would like to know if there exist any deployed implementations that
> would be so broken.  If there are, I think we would instead want to keep
> the encoding currently in the SASL GSSAPI draft, calling it by a name
> other than "base32".
> 
> -++**==--++**==--++**==--++**==--++**==--++**==--++**==
> 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]

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

Date: Thu, 21 Mar 2002 09:42:48 -0800
From: [email-masked] (John Myers)
To: [email-masked], ietf-sasl <[email-masked]>
Subject: SASL/GSSAPI proposed change of base32 alphabet
Sender: [email-masked]

I have been requested to replace the base32 specification in the 
(expired) SASL GSSAPI internet draft with a reference section 3 of 
draft-josefsson-base-encoding-03.txt.  This would mean a change in the 
encoding alphabet, breaking any implementations of the existing draft 
which use mechanisms other than Kerberos or SPNEGO.

I would like to know if there exist any deployed implementations that 
would be so broken.  If there are, I think we would instead want to keep 
the encoding currently in the SASL GSSAPI draft, calling it by a name 
other than "base32".

Date: Thu, 21 Mar 2002 10:30:41 -0500
From: Lawrence Greenfield <[email-masked]>
To: John Gardiner Myers <[email-masked]>
Cc: [email-masked]
Subject: Kc normalization enough or not?
Sender: [email-masked]

If you take a look at the latest kerberos attempt at i18n, you'll see
that they've defined a profile of stringprep with more than just Kc
normalization.

Should we follow their lead?  Some of what they're doing (changing all
spaces to the US-ASCII SP character) I think is harmful but maybe
other things are useful.

The krb draft is draft-ietf-krb-wg-utf8-profile-00.

Larry

Date: Mon, 18 Mar 2002 13:40:56 -0800
From: [email-masked] (John Myers)
To: [email-masked]
Subject: working draft of base spec
Sender: [email-masked]

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

--------------070202070602070205000603
Content-Type: text/plain;
 name="auth.ms"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="auth.ms"

=2E\" -*- Mode: nroff -*-
=2Ede XS
=2Eif !\\n(1T .BG
=2Eds XL \\n(PN
=2Eif \\n(.$ .ds XL \\$1
=2Enr SJ \\n(.j
=2Enr PF \\n(.f
=2Enr PX \\n(.s
=2Enr SL \\n(.l
=2Els 1
=2Ebr
=2Eda XT
=2Eif \\n(.$-1 \{\
=2E	nr XI 1
=2E	in \\$2n
=2E\}
=2Eft 1
=2Eps \\n(PS
=2Ell \\n(LLu-8n
=2Ena
=2Enh
=2E.
=2Ede XE
=2Eif !=07\\*(XL=07no=07 \\a\\t\\*(XL
=2Ebr
=2Eda
=2Els
=2Ead \\n(SJ
=2Eft \\n(PF
=2Eps \\n(PX
=2Ell \\n(SLu
=2Eif \\n(XI \{\
=2E	nr XI 0
=2E	in 0
=2E\}
=2Enh
=2E.
=2Ede PX
=2Eif \\n(VS>=3D40 .vs \\n(VSu
=2Eif \\n(VS<=3D39 .vs \\n(VSp
=2Ell \\n(LLu
=2Elt \\n(LTu
=2Eta \\n(LLu-5n \\n(LLuR
=2Ein 0
=2Enf
=2Ers
=2Eif !=07\\$1=07no=07 \{\
=2E	sp .5i
=2E	tl ''\s+2Table of Contents\s-2''
=2E	sp .5i
=2E\}
=2EXT
=2Enh
=2E.
=2Ede xx
=2Ene 4
=2Ein 0
\\$1
=2EXS
\\$1
=2EXE
=2Enh
=2Ein 3
=2Esp
=2E.
=2Eaf PN i
=2Epl 10.0i
=2Epo 0
=2Ell 7.2i
=2Elt 7.2i
=2Enr LL 7.2i
=2Enr LT 7.2i
=2Eds LF J. Myers
=2Eds RF FORMFEED[Page \\n(PN]
=2Eds CF
=2Eds LH Internet DRAFT
=2Eds CH SASL
=2Eds RH \*(DY
=2Ehy 0
=2Ead l
Network Working Group                                           J. Myers
Internet Draft                                                April 2001
Document: draft-myers-saslrev-01.txt=20
=2Esp  2
=2Ece
Simple Authentication and Security Layer (SASL)

=2Eti 0
=2Exx "Status of this Memo"
=2Ein 3
=2Efi
This document is an Internet Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

Internet Drafts are working documents of the Internet Engineering Task
Force (IETF), its Areas, and its Working Groups.  Note that other
groups may also distribute working documents as Internet
Drafts. Internet Drafts are draft documents valid for a maximum of six
months.  Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time.  It is not appropriate to use Internet
Drafts as reference material or to cite them other than as ``work in
progress''.

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.

A revised version of this draft document will be submitted to the RFC
editor as a Draft Standard for the Internet Community.  Discussion
and suggestions for improvement are requested.  Distribution of this draf=
t is
unlimited.
=2Ede PT
=2Elt \\n(LTu
=2Epc %
=2Enr PN \\n%
=2Enr PT \\n%
=2Eif !\\n(EH .if !\\n(OH .tl =07\\*(LH=07\\*(CH=07\\*(RH=07
=2Eif \\n(OH .if o .tl \\*(O1
=2Eif \\n(EH .if e .tl \\*(E2
=2Elt \\n(.lu
=2E.
=2Ebp
=2Eaf PN 1
=2Exx "1.    Abstract"
=2Ein 3
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.
=2Esp
=2Exx "2.    Organization of this document"
=2Exx "2.1.  How to read this document"
This document is written to serve two different audiences, protocol
designers using this specification to support authentication in their
protocol, and implementors of clients or servers for those protocols
using this specification.

The sections "Overview", "Authentication Mechanisms",=20
"Protocol Profile Requirements", "Specific Issues",
and "Security Considerations" cover issues that protocol designers
need to understand and address in profiling this specification for use
in a specific protocol.

Implementors of a protocol using this specification need the
protocol-specific profiling information in addition to the information
in this document.
=2Esp
=2Exx "2.2.  Conventions used in this document"
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in "Key words for
use in RFCs to Indicate Requirement Levels" [KEYWORDS].
=2Esp
=2Exx "3.    Overview"
The Simple Authentication and Security Layer (SASL) is a method for
adding authentication support to
connection-based protocols.

The SASL specification has three layers, as indicated in the diagram
below.  At the top, a protocol definition using SASL specifies a
profile, including a command for identifying and authenticating a user
to a server and for optionally negotiating a security layer for
subsequent protocol interactions.  At the bottom, a SASL mechanism
definition specifies an authentication mechanism.  The SASL framework,
specified by this document, constrains the behavior of protocol
profiles and mechanisms, separating protocol from mechanism and
defining how they interact.
=2Enf

             SMTP Protocol     LDAP Protocol          Etc
                Profile           Profile            . . .
                       \\-----        |       -----/
                             \\       |      /
                              SASL framework
                             /       |      \\
                       /-----        |       -----\\
                EXTERNAL         DIGEST-MD5           Etc
             SASL mechanism    SASL mechanism        . . .
=2Efi
=2Esp
This separation between the definition of protocols and the definition
of authentication mechanisms is crucial.  It permits an authentication
mechanism to be defined once, making it usable by any SASL protocol
profiles.  In many implementations, the same SASL mechanism code is
used for multiple protocols.
=2Esp
=2Exx "4.    Authentication mechanisms"
SASL mechanisms are named by strings, from
1 to 20 characters in length, consisting of upper-case letters,
digits, hyphens, and/or underscores.  SASL mechanism
names must be registered with the IANA.  IETF Standards Track
documents may override this registration requirement by reserving a
portion of the SASL mechanism namespace for their own use; the GSSAPI
mechanism specification [SASL-GSSAPI] does this.
Procedures for registering
new SASL mechanisms are given in the section
"Registration procedures".

The "sasl-mech" rule below defines the syntax of a SASL mechanism name.
This uses the augmented Backus-Naur
Form (BNF) notation as specified in [ABNF] and the ABNF core
rules as specified in Appendix A of the ABNF specification [ABNF].

=2Enf
sasl-mech             =3D 1*20mech-char
mech-char             =3D %x41-5A / DIGIT / "-" / "_"
               ; mech names restricted to uppercase letters,
               ; digits, "-" and "_"

=2Efi
=2Esp
=2Exx "4.1.  Authentication protocol exchange"
A SASL mechanism is responsible for conducting
an authentication protocol exchange.  This consists of a
series of server challenges and client responses, the contents of
which are specific to and defined by
the mechanism.  To the protocol, the challenges and responses
are opaque binary tokens of
arbitrary length.  The protocol's profile then specifies how these
binary tokens are then encoded for transfer over the connection.

After receiving an authentication command or any client response, a
server mechanism may issue a challenge, indicate failure, or indicate
completion.  The server mechanism MAY return additional data with a
completion indication.  The protocol's profile specifies how each of
these is then represented over the connection.

After receiving a challenge, a client mechanism may issue a response or a=
bort
the exchange.  The protocol's profile specifies how each of these is
then represented over the connection.

During the authentication protocol exchange, the=20
mechanism performs authentication, transmits an authorization identity
(frequently known as a userid) from the client to server, and
negotiates the use of a mechanism-specific security layer.  If the use
of a security layer is agreed upon, then the mechanism must also define
or negotiate the maximum security layer buffer size that each side is
able to receive.
=2Esp
=2Exx "4.2.  Authorization identities and proxy authentication"
An authorization identity is a string of zero or more ISO 10646
[ISO-10646] coded characters.  The NULL (U+0000) character is not
permitted in authorization identities.  The authorization identity is
used by the server as the primary identity for making access policy
decisions.

The character encoding scheme used for transmitting an authorization
identity over protocol is specified in each authentication mechanism
(with the authentication mechanism's blob being further encoded by the
protocol profile).  Per IETF character set policy [CHARSET-POLICY],
authentication mechanisms SHOULD encode these and
other strings in UTF-8 [UTF-8].  While some legacy mechanisms are
incapable of transmitting an authoriation identity other than the
empty string, newly defined mechanisms are expected to be capable of
carrying the entire repertoire of Unicode Normalization form KC
[UNICODE-NORMALIZATION] (with the exception of the NULL character).

The identity derived from the client's
authentication credentials is known as the "authentication identity".
With any mechanism, transmitting an
authorization identity of the empty string directs the server to derive
an authorization identity from the client's authentication
identity.

If the authorization identity transmitted during the authentication
protocol exchange is not the empty string, this is typically referred
to as "proxy authentication".  This feature permits agents such as
proxy servers to authenticate using their own credentials, yet request
the access privileges of the identity for which they are proxying.

The server makes an implementation defined policy decision as to
whether the authentication identity is permitted to have the access
privileges of the authorization identity and whether the authorization
identity is permitted to receive service.  If it is not, the server
indicates failure of the authentication protocol exchange.

As a client might not have the same information as the server,
clients SHOULD NOT themselves try to derive authorization identities
from authentication identities when clients could instead transmit an
authorization identity of the empty string.
=2Esp
=2Exx "4.3.  Security layers"
If use of a security layer is negotiated by the authentication
protocol exchange, the security layer is applied to all subsequent
data sent over the connection.  The security layer takes effect
immediately following the last response of the authentication exchange
for data sent by the client and the completion indication for data
sent by the server.

Once the security layer is in effect, the
protocol stream is processed by the security layer into buffers of
security encoded data.  Each buffer of security encoded data is
transferred over the connection as a stream of octets prepended with a
four octet field in network byte order that represents the length of
the following buffer.  The length of the security encoded data buffer
must be no larger than the maximum size that was either defined in the
mechanism specification or negotiated by
the other side during the authentication protocol exchange.
=2Exx "4.4.  Character string issues"
Per IETF character set policy [CHARSET-POLICY], authentication
mechanisms SHOULD encode character strings in UTF-8 [UTF-8].  In order
to avoid noninteroperability due to differing normalizations,
when a mechanism specifies that a string password used as input to a
cryptographic function it SHOULD specify that the string first be put
in Unicode Normalization Form KC [UNICODE-NORMALIZATION].
=2Esp
=2Exx "5.    Protocol profile requirements"
In order to use this specification, a protocol definition MUST supply
the following information:
=2Esp
=2EIP 1. 3
A service name, to be selected from the IANA registry of "service"
elements for the GSSAPI host-based service name form. [GSSAPI]  This
service name is made available to the authentication mechanism.

The registry is available at the URL
\%"http://www.isi.edu/in-notes/iana/assignments/gssapi-service-names"
=2EIP 2. 3
A definition of the command to initiate the authentication protocol
exchange.  This command must have as a parameter the=20
name of the mechanism being selected by the client.

The command SHOULD have an optional parameter giving an initial
response.  This optional parameter allows the client to avoid a round
trip when using a mechanism which is defined to have the client send
data first.  When this initial response is sent by the client and the
selected mechanism is defined to have the server start with an initial
challenge, the command fails.  See section 6.1 of this document for
further information.
=2EIP 3. 3
A definition of the method by which the authentication protocol
exchange is carried out, including how the challenges and responses
are encoded, how the server indicates completion or failure of the
exchange, how the client aborts an exchange, and how the exchange method
interacts with any line length limits in the protocol.

The command SHOULD have a method for the server to include an
optional challenge with a success notification.  This allows the
server to avoid a round trip when using a mechanism which is defined
to have the server send additional data along with the indication of
successful completion.  See section 6.2 of this document for further
information.
=2EIP 4. 3
Identification of the octet where any negotiated security layer starts
to take effect, in both directions.
=2Esp
In addition, a protocol profile SHOULD specify a mechanism through
which a client may obtain the names of the SASL mechanisms available
to it.  This is typically done through the protocol's extensions or
capabilities mechanism.
=2Esp
A protocol profile MAY further refine the definition of an
authorization identity by adding additional syntactic restrictions and
protocol-specific semantics.
=2Esp
A protocol profile SHOULD NOT attempt to amend the definition of
mechanisms or make mechanism-specific encodings.  This breaks the
separation between protocol and mechanism that is fundamental to the
design of SASL.
=2Exx "6.    Specific issues"
=2Exx "6.1.  Client sends data first"
Some mechanisms specify that the first data sent in the
authentication protocol exchange is from the client to the server.

If a protocol's profile permits the command which initiates an
authentication protocol exchange to contain an initial client
response, this parameter SHOULD be used with such mechanisms.

If the initial client response parameter is not given, or if a
protocol's profile does not permit the command which initiates an
authentication protocol exchange to contain an initial client
response, then the server issues a challenge with no data.  The
client's response to this challenge is then used as the initial client
response.  (The server then proceeds to send the next challenge,
indicates completion, or indicates failure.)
=2Esp
=2Exx "6.2.  Server returns success with additional data"
Some mechanisms may specify that additional data be sent to the
client along with an indication of successful completion of the
exchange.  This data would, for example, authenticate the server to
the client.

If a protocol's profile does not permit this additional data to be
returned with a success indication, then the server issues the data as
a server challenge, without an indication of successful completion.
The client then responds with no data.  After receiving this empty
response, the server then indicates successful completion (with no
additional data).
=2Esp
=2Exx "6.3.  Multiple authentications"
Unless otherwise stated by the protocol's profile, only one successful
SASL negotiation may occur in a protocol session.  In this case, once an
authentication protocol exchange has successfully completed, further
attempts to initiate an authentication protocol exchange fail.

In the case that a profile explicitly permits multiple successful SASL
negotiations to occur, then in no case may multiple security layers be
simultaneously in effect.  If a security layer is in effect and a
subsequent SASL negotiation selects no security layer, the original
security layer remains in effect.  If a security layer is in effect
and a subsequent SASL negotiation selects a second security layer,
then the second security layer replaces the first.

=2Exx "7.    Registration procedures"
Registration of a SASL mechanism is done by filling in the template in
section 7.4 and sending it in to [email-masked].  IANA has the right to
reject obviously bogus registrations, but will perform no review of
claims made in the registration form.

There is no naming convention for SASL mechanisms; any name that
conforms to the syntax of a SASL mechanism name can be registered.
An IETF Standards Track document may reserve a portion of the SASL
mechanism namespace for its own use, amending the registration rules
for that portion of the namespace.

While the registration procedures do not require it, authors of SASL
mechanisms are encouraged to seek community review and comment
whenever that is feasible.  Authors may seek community review by
posting a specification of their proposed mechanism as an
internet-draft.  SASL mechanisms intended for widespread use should be
standardized through the normal IETF process, when appropriate.
=2Esp
=2Exx "7.1.  Comments on SASL mechanism registrations"
Comments on registered SASL mechanisms should first be sent to the
"owner" of the mechanism.  Submitters of
comments may, after a reasonable attempt to contact the owner, request
IANA to attach their comment to the
SASL mechanism registration itself.  If IANA approves of this
the comment will be made accessible in conjunction with the
SASL mechanism registration itself.
=2Esp
=2Exx "7.2.  Location of registered SASL mechanism list"
SASL mechanism registrations are available at the URL
\%"http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms"
The SASL mechanism description and other supporting
material may also be published as an Informational RFC by
sending it to=20
\%"[email-masked]"
(please follow the
instructions to RFC authors [RFC-INSTRUCTIONS]).
=2Esp
=2Exx "7.3.  Change control"
Once a SASL mechanism registration has been published by IANA, the
author may request a change to its definition.  The change request
follows the same procedure as the registration request.

The owner of a SASL mechanism may pass responsibility for the
SASL mechanism to another person or agency by informing IANA;
this can be done without discussion or
review.

The IESG may reassign responsibility for a SASL mechanism. The
most common case of this will be to enable changes to be made
to mechanisms where the author of the registration has died, moved
out of contact or is otherwise unable to make changes that are
important to the community.

SASL mechanism registrations may not be deleted; mechanisms which are
no longer believed appropriate for use can be declared OBSOLETE by a
change to their "intended use" field; such SASL mechanisms will be
clearly marked in the lists published by IANA.

The IESG is considered to be the owner of all SASL mechanisms which
are on the IETF standards track.
=2Esp
=2Exx "7.4.  Registration template"

  To: [email-masked]
  Subject: Registration of SASL mechanism X

  SASL mechanism name:

  Security considerations:

  Published specification (optional, recommended):

  Person & email address to contact for further information:

  Intended usage:

  (One of COMMON, LIMITED USE or OBSOLETE)

  Owner/Change controller:

  (Any other information that the author deems interesting may be
  added below this line.)
=2Esp
=2Exx "8.    The external mechanism"
The mechanism name associated with external authentication is
"EXTERNAL".

The client sends an initial response with the UTF-8 encoding of the
authorization identity.

The server uses information, external to SASL, to determine whether
the client is authorized to authenticate as the authorization
identity.  If the client is so authorized, the server indicates
successful completion of the authentication exchange; otherwise the
server indicates failure.

The system providing this external information may be, for example,
IPsec or TLS.

If the client sends the empty string as the authorization identity
(thus requesting the authorization identity be derived from the
client's authentication credentials), the authorization identity is to
be derived from authentication credentials which exist in the
system which is providing the external authentication.
=2Esp
=2Exx "8.1   Formal syntax"
The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in [ABNF].  This uses the ABNF core
rules as specified in Appendix A of the ABNF specification [ABNF].

The "initial-response" rule below defines the initial response sent
from client to server.
=2Esp
=2Enf
initial-response =3D *UTF8
UTF8           =3D %x01-7F / UTF8-2 / UTF8-3 / UTF8-4
UTF8-loworder  =3D %x80-BF
UTF8-2         =3D %xC1-DF UTF8-loworder
               ; Disallow overlong sequences beginning with 0xC0.
UTF8-3         =3D (%xE0 %xA0-BF UTF8-loworder) /
                 (%xE1-EC 2UTF8-loworder) /
                 (%xED %x80-9F UTF8-loworder) /
                 (%xEE 2UTF8-loworder) /
                 (%xEF %x80-BE UTF8-loworder) /
                 (%xEF %xBF %x80-BD)
               ; Disallow overlong sequences beginning with 0xE0,
               ; disallow encoded surrogate characters, and
               ; disallow U+FFFE, U+FFFF.
UTF8-4         =3D (%xF0 %x90-BF 2UTF8-loworder) /
                 (%xF1-F7 3UTF8-loworder)
               ; Disallow overlong sequences beginning with 0xF0.
=2Efi
=2Esp
=2Exx "8.2   Example"
The following is an example of an EXTERNAL authentication in the SMTP
protocol [SMTP-AUTH].  In this example, the client is proxy
authenticating, sending the authorization id "fred".  The server has
determined the client's identity through IPsec and has a security
policy that permits that identity to proxy authenticate as any other
identity.

To the protocol profile, the four octet sequence "fred" is an opaque
binary blob.
The SASL protocol
profile for SMTP specifies that server challenges and client responses
are encoded in BASE64; the BASE64 encoding of "fred" is "ZnJlZA=3D=3D".
=2Esp
=2Ein 6
=2Exm 9
S: 220 smtp.example.com ESMTP server ready
=2Ebr
C: EHLO jgm.example.com
=2Ebr
S: 250-smtp.example.com
=2Ebr
S: 250 AUTH DIGEST-MD5 EXTERNAL
=2Ebr
C: AUTH EXTERNAL ZnJlZA=3D=3D
=2Ebr
S: 235 Authentication successful.
=2Esp
=2Exx "9.    References"
=2Ein 3
[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, November 1997

[CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and
Languages", RFC 2277, January 1998

[GSSAPI] Linn, "Generic Security Service Application Program
Interface, Version 2, Update 1", RFC 2743, January 2000

[ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993.

[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997

[RFC-INSTRUCTIONS] Postel, Reynolds, "Instructions to RFC
Authors", RFC 2223, October 1997

[SASL-GSSAPI] Myers, "SASL GSSAPI mechanisms",
draft-ietf-cat-sasl-gssapi-XX.txt, September 2000

[SASL-OTP] Newman, "The One-Time-Password SASL Mechanism", RFC
2444, October 1998

[SMTP-AUTH] Myers, "SMTP Service Extension for Authentication", RFC
2554, March 1999

[UNICODE-NORMALIZATION] Davis, Durst, "Unicode Standard Annex #15:
Unicode Normalization Forms", March 2001,
http://www.unicode.org/unicode/reports/tr15/

[UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646",
RFC 2279, Janyary 1998
=2Esp
=2Exx "10.   Security considerations"
Security issues are discussed throughout this memo.

The mechanisms that support integrity protection are
designed such that the negotiation of the security layer and
authorization identity is integrity protected.  When the client
selects a security layer with at least integrity protection, this
protects against an active attacker hijacking the connection and
modifying the authentication exchange to negotiate a plaintext
connection.

When a server or client supports multiple authentication mechanisms,
each of which has a different security strength, it is possible for an
active attacker to cause a party to use the least
secure mechanism supported.  To protect against
this sort of attack, a client or server which supports
mechanisms of different strengths should have
a configurable minimum strength that it will use.
It is not sufficient for this
minimum strength check to only be on the server,
since an active attacker can change which mechanisms the client sees as
being supported, causing
the client to send authentication
credentials for its weakest supported mechanism.=20

The client's selection of a SASL mechanism is done in the
clear and may be modified by an active attacker.  It is important for
any new SASL mechanisms to be designed such that an active attacker
cannot obtain an authentication with weaker security properties by
modifying the SASL mechanism name and/or the challenges and responses.

Any protocol interactions prior to authentication are performed in the
clear and may be modified by an active attacker.  In the case where a
client selects integrity protection, it is important that any
security-sensitive protocol negotiations be performed after
authentication is complete.  Protocols should be designed such that
negotiations performed prior to authentication should be either
ignored or revalidated once authentication is complete.

The EXTERNAL mechanism provides no security protection; it is
vulnerable to spoofing by either client or server, active attack, and
eavesdropping.  It should only be used when external security
mechanisms are present and have sufficient strength.
=2Esp
=2Exx "11.   Author's address"
=2Enf
John G. Myers
Netscape Communications
501 E. Middlefield Road
Mail Stop SCA 15:201
Mountain View, CA 94043-4042

Email: [email-masked]
=2Efi
=2Esp
=2Exx "Appendix A. Relation of SASL to transport security"
Questions have been raised about the relationship between SASL and
various services (such as IPsec and TLS) which provide a secured
connection.

Two of the key features of SASL are:
=2Esp
=2Ein 6
=2EIP 1. 3
The separation of the
authorization identity from the identity in the client's credentials.
This permits
agents such as proxy servers to authenticate using their own
credentials, yet request the access privileges of the identity for
which they are proxying.
=2EIP 2. 3
Upon successful completion of an authentication exchange, the server
knows the authorization identity the client wishes to use.  This
allows servers to move to a "user is authenticated" state in the
protocol.
=2Esp
=2Ein 3
These features are extremely important to some application protocols,
yet Transport Security services do not always provide them.  To define
SASL mechanisms based on these services would be a very messy task, as
the framing of these services would be redundant with the framing of
SASL and some method of providing these important SASL features would
have to be devised.

Sometimes it is desired to enable
within an existing connection the use of a security service which
does not fit the SASL model.  (TLS is an example of such a service.)
This can be done by adding a command, for example "STARTTLS", to the
protocol.  Such a command is outside the scope of SASL, and should be
different from the command which starts a SASL authentication
protocol exchange.

In certain situations, it is reasonable to use SASL underneath one of
these Transport Security services.  The transport service would secure
the connection, either service would authenticate the client, and SASL
would negotiate the authorization identity.  The SASL negotiation
would be what moves the protocol from "unauthenticated" to
"authenticated" state.  The "EXTERNAL" SASL mechanism is explicitly
intended to handle the case where the transport service secures the
connection and authenticates the client and SASL negotiates the
authorization identity.

When using SASL underneath a sufficiently strong Transport Security
service, a SASL security layer would most likely be redundant.  The
client and server would thus probably want to negotiate off the use of
a SASL security layer.
=2Esp
=2Exx "Appendix B. IANA considerations"
The IANA is directed to modify the SASL mechanisms registry as follows:
=2Esp
=2Ein 6
=2EIP 1. 3
Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
registrations to OBSOLETE.
=2EIP 2. 3
Change the "Published specification" of the EXTERNAL mechanism to this
document.
=2Esp
=2Exx "Appendix C. Changes since RFC 2222"
The GSSAPI mechanism was removed.  It is now specified in a separate
document [SASL-GSSAPI].
=2Esp
The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and
has been removed.
=2Esp
The "SKEY" mechanism described in RFC 2222 is obsolete and has been
removed.  It has been replaced by the OTP mechanism [SASL-OTP].
=2Esp
The overview has been substantially reorganized and clarified.
=2Esp
Clarified the definition and semantics of the authorization identity.
=2Esp
Prohibited the NULL character in authorization identities.
=2Esp
Added a section on character string issues.
=2Esp
The word "must" in the first paragraph of the "Protocol profile
requirements" section was changed to "MUST".
=2Esp
Specified that protocol profiles SHOULD provide a way for clients to
discover available SASL mechanisms.
=2Esp
Made the requirement that protocol profiles specify the semantics of
the authorization identity optional to the protocol profile.  Clarified
that such a specification is a refinement of the definition in the
base SASL spec.
=2Esp
Added a requirement discouraging protocol profiles from breaking the
separation between protocol and mechanism.
=2Esp
Mentioned that standards track documents may carve out their own
portions of the SASL mechanism namespace.
=2Esp
Specified that the authorization identity in the EXTERNAL mechanism is
encoded in UTF-8.
=2Esp
Added a statement that a protocol profile SHOULD
allow challenge data to be sent with a success indication.
=2Esp
Added a security consideration for the EXTERNAL mechansim.
=2Esp
Clarified sections concerning success with addtional data.
=2Ebp 2
=2Eaf PN i
=2EPX

--------------070202070602070205000603--

Date: Sun, 17 Mar 2002 16:06:42 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
Subject: Re: SASL bar BOF in Minneapolis?
Sender: [email-masked]

RL 'Bob' Morgan wrote:

> On Sun, 10 Mar 2002, Alexey Melnikov wrote:
>
> > I think interested parties should gather in Minneapolis to discuss
> > progress (or lack of thereof) of the base set of documents. Yes/no?
> > When, if yes?
>
> Yes, let's.  Kurt suggested Monday evening.  I suspect I'm not the only
> SASL-interested person also interested in ssh which is meeting that
> evening.  I'd rather do it Monday 15:30-17:30 (or even dinner I suppose).
> Or, ssh probably won't take all its slot, so perhaps after it adjourns.

Ok, let's meet 15.30 near the message board.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

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

Date: Sun, 17 Mar 2002 00:15:44 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: SASL bar BOF in Minneapolis?
Sender: [email-masked]

On Sun, 10 Mar 2002, Alexey Melnikov wrote:

> I think interested parties should gather in Minneapolis to discuss
> progress (or lack of thereof) of the base set of documents. Yes/no?
> When, if yes?

Yes, let's.  Kurt suggested Monday evening.  I suspect I'm not the only 
SASL-interested person also interested in ssh which is meeting that 
evening.  I'd rather do it Monday 15:30-17:30 (or even dinner I suppose).
Or, ssh probably won't take all its slot, so perhaps after it adjourns.

 - RL "Bob"

Date: Sat, 16 Mar 2002 12:51:39 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASL bar BOF in Minneapolis?
Cc: [email-masked]
Sender: [email-masked]

At 11:21 AM 2002-03-10, Alexey Melnikov wrote:
>I think interested parties should gather in Minneapolis to discuss
>progress (or lack of thereof) of the base set of documents. Yes/no?
>When, if yes?

I think that's a good idea.  How about Monday evening?

Kurt

From: "Boniforti Flavio" <[email-masked]>
To: <[email-masked]>
Subject: Postfix + SASL: problem with authentication...
Date: Thu, 14 Mar 2002 13:41:35 +0100
Importance: Normal
Sender: [email-masked]

Hello ALL!

I'm new here...

I've set up Postfix to use SASL (and it works OK).
The main purpose of all this is because I have to relay my LAN clients' mail
towards my ISPs SMTP server.

And here comes the hard part: I've set up postfix to relay, I've set up all
the stuff it needs (I hope I haven't forgotten anything!), but now there's a
problem which has been pointed out by someone on the postfix mailing-list:
the SMTP server I have to relay to is "Lotus Domino Release 5.0.8" and it
answers with "250-AUTH=LOGIN". I've been told that the error is the '='
sign, which shouldn't be there at all!

How may I still be able to login to that server with SASL?

Thanx!

Boniforti Flavio
Informa Srl
Via 42 Martiri, 165
28924 Verbania (VB)
Tel +39 0323 586216
Fax +39 0323 586672
http://www.co-ver.it/informa

Date: Sun, 10 Mar 2002 19:21:02 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: SASL bar BOF in Minneapolis?
Sender: [email-masked]

I think interested parties should gather in Minneapolis to discuss
progress (or lack of thereof) of the base set of documents. Yes/no?
When, if yes?

Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

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

Date: Thu, 7 Mar 2002 10:42:34 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-nystrom-http-sasl-02.txt
Sender: [email-masked]

All,

The above draft is now available from http://ietf.org/internet-drafts/.
Comments and suggestions for improvements are most welcome. Especially,
perhaps, in the area of dealing with proxies and SASL mechanisms offering
privacy/integrity.

Thanks,
-- Magnus