Subject: RE: Compression under SASL was Re: Huffman coding?

From: Alan Lloyd <[email-masked]>
Date: Fri, 29 May 1998 09:20:40 +1000

Apologies to the list on this one - I thought that there was a
difference between a standard and HOW one implemented it, that SASL was
about security and authentication and that compression was about
transfer efficiency - and that compression techniques can be used
without authentication.

Oh well one does live and learn eh!
:-) 
alan

> -----Original Message-----
> From:	Jack De Winter [SMTP:[email-masked]]
> Sent:	Friday, May 29, 1998 7:35 AM
> To:	Alan Lloyd; 'Chris Newman'; Harald Alvestrand
> Cc:	[email-masked]
> Subject:	RE: Compression under SASL  was Re: Huffman coding?
> 
> At 09:00 AM 5/28/98 +1000, Alan Lloyd wrote:
> >Well said Chris - some of us have to build big systems and deal with
> >trust models in a distributed - authenticated environment - having
> sand
> >and rubber security components being promoted as the foundations is a
> >good way of making sure no one uses them.
> >Its easy to change a spec and a bit of code on the fly.. Try changing
> a
> >military, banking or telephone system in the same way.
> >
> >regards alan
> 
> However, take the following viewpoint:
> 
> You have 10,000 users, each dialing in over slow lines to access the
> mail servers.  
> 
> While I understand your viewpoint, please understand mine.  Why should
> compression not be put into a mechanism that has the appropriate
> framing
> and negotiation phases already built in?  Otherwise, we have to come
> up
> with a SCL (Session Compression Layer) that has to be negotiated above
> and beyond SASL, make sure that the SASL after SCL is invalid, etc...
> 
> regards,
> Jack
> -------------------------------------------------
> Jack De Winter - Wildbear Consulting, Inc.
> (519) 884-4498		http://www.wildbear.on.ca/jacks/

---

From: Alan Lloyd <[email-masked]>
Date: Thu, 28 May 1998 09:00:25 +1000

Well said Chris - some of us have to build big systems and deal with
trust models in a distributed - authenticated environment - having sand
and rubber security components being promoted as the foundations is a
good way of making sure no one uses them.
Its easy to change a spec and a bit of code on the fly.. Try changing a
military, banking or telephone system in the same way.

regards alan

> From:	Chris Newman [SMTP:[email-masked]]
> Sent:	Wednesday, May 20, 1998 7:25 AM
> To:	Harald Alvestrand
> Cc:	[email-masked]
> Subject:	Re: Compression under SASL  was Re: Huffman coding?
> 
> On Mon, 18 May 1998, Harald Alvestrand wrote:
> > This reminds me of the "application layer framing" approach that
> I've
> > seen bandied about around MMUSIC/AVT. It's a good argument.
> > But in that case, we may need to turn SASL into Simple Anything
> Session Layer,
> > with slots for authentication, encryption, integrity protection and
> > "we haven't thought of it yet".
> > Because combinatorial explosion is still a Bad Thing for deployment.
> 
> I oppose any fundamental changes to the SASL base spec, other than
> removal
> of rarely used features/mechanisms.  We're having a *very* hard time
> deploying security and the last thing we need to do is mess with
> something
> that's just starting to work. 
> 
> > SASL as I read it is a way to negotiate into a security layer.
> > From my 10.000 foot level, I don't see the great difference between
> > the exchanges
> > 
> > -> STARTTLS          -> AUTHENTICATE TLS
> > <- OK			<- OK
> > ...first byte of TLS negotiation starts here in both cases.....
> 
> SASL's primary use today is to permit use of a non-cleartext client
> authentication mechanisms.  The security layer is not used a lot yet.
> 
> TLS's primary use today is to authenticate the server and provide a
> privacy layer.  Client authentication is rarely used despite being
> widely deployed (in the form of SSL client certificate support).
> 
> The negotiation and framing they use is completely different.  The
> SASL
> negotiation occurs within the app protocol, while the TLS negotiation
> occurs at a lower level invisible to the app protocol.  The SASL
> framing
> uses just simple counted blocks (with a negotiated max size), while
> the
> TLS framing has many complex rules.
> 
> They can't be merged into a single layer without fundamental changes
> to
> one or both.  And their primary design goals were sufficiently
> different
> that I don't see any harm from having both around.
> 
> > ..............actually, why not?
> > the blocking factor I can see is the text in RFC 2222 section 5.3,
> > and we change protocols, don't we?
> 
> I am strongly opposed to any changes to SASL which would stall the
> progression along the standards track.  We need to get security
> deployed
> yesterday, not next year.  It is way too late to change the
> fundamental
> framing mechanisms.
> 
> > But I do NOT think adding compression as a property of a SASL
> > mechanism is going to cut it. Unfortunately.
> 
> How about a new standards track spec which amends SASL in a
> backwards-compatible way so that any SASL mechanism with a security
> layer
> can also negotiate compression? 
> 
> Note that this is *not* important enough in my book to merit a
> non-backwards-compatible change to SASL.  Compression is a nice way to
> use
> spare CPU cycles to save network bandwidth, but it's far from a
> requirement. 
> 
> 		- Chris
> 
> 
>

---

From: Alan Lloyd <[email-masked]>
Date: Fri, 29 May 1998 09:20:40 +1000

> and beyond SASL, make sure that the SASL after SCL is invalid, etc...

From: Alan Lloyd <[email-masked]>
To: "'Jack De Winter'" <[email-masked]>, "'Chris Newman'" <[email-masked]>, Harald Alvestrand <[email-masked]>
Cc: [email-masked]
Subject: RE: Compression under SASL  was Re: Huffman coding?
Date: Fri, 29 May 1998 09:20:40 +1000
Sender: [email-masked]

> and beyond SASL, make sure that the SASL after SCL is invalid, etc...

Date: Thu, 28 May 1998 17:35:15 -0400
To: Alan Lloyd <[email-masked]>, "'Chris Newman'" <[email-masked]>, Harald Alvestrand <[email-masked]>
From: "Jack De Winter" <[email-masked]>
Subject: RE: Compression under SASL  was Re: Huffman coding?
Cc: [email-masked]
Sender: [email-masked]

While I understand your viewpoint, please understand mine.  Why should
compression not be put into a mechanism that has the appropriate framing
and negotiation phases already built in?  Otherwise, we have to come up
with a SCL (Session Compression Layer) that has to be negotiated above
and beyond SASL, make sure that the SASL after SCL is invalid, etc...

regards,
Jack

From: Alan Lloyd <[email-masked]>
To: "'Chris Newman'" <[email-masked]>, Harald Alvestrand <[email-masked]>
Cc: [email-masked]
Subject: RE: Compression under SASL  was Re: Huffman coding?
Date: Thu, 28 May 1998 09:00:25 +1000
Sender: [email-masked]

regards alan

> spare CPU cycles to save network bandwidth, but it's far from a

Date: Wed, 20 May 1998 10:55:31 -0400
To: Chris Newman <[email-masked]>, Harald Alvestrand <[email-masked]>
From: "Jack De Winter" <[email-masked]>
Subject: Re: Compression under SASL  was Re: Huffman coding?
Cc: [email-masked]
Sender: [email-masked]

At 02:25 PM 5/19/98 -0700, Chris Newman wrote:
>I oppose any fundamental changes to the SASL base spec, other than removal
>deploying security and the last thing we need to do is mess with something
>...
>non-backwards-compatible change to SASL.  Compression is a nice way to use

On part of this we agree, and part of this we dont.  Some of our
customers use our software to allow their sales forces to communicate
with the home office on land lines and on cellular lines.  For them,
every second online is costing them money.

regards,
Jack

Date: Wed, 20 May 1998 13:58:10 +0200
To: Chris Newman <[email-masked]>
From: Harald Alvestrand <[email-masked]>
Subject: Re: Compression under SASL  was Re: Huffman coding?
Cc: [email-masked]
Sender: [email-masked]

For those mechanisms that have a "function bitmap", it's fairly trivial
to extend those specs with another bit for the "compression" function.

But the bitmap is part of the mechanism, not of SASL.

We could write up a new document entitled "how to write a SASL mechanism",
and recommend that all mechanisms use the same bits in a common way.
We could even make it a requirement on new SASL mechanisms, and claim that
those that do not have it as "implicitly zero".

But I don't feel good about it. Not at all.

               Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

Date: Tue, 19 May 1998 14:25:00 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Compression under SASL  was Re: Huffman coding?
To: Harald Alvestrand <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Mon, 18 May 1998, Harald Alvestrand wrote:
> This reminds me of the "application layer framing" approach that I've
> But in that case, we may need to turn SASL into Simple Anything Session Layer,

I oppose any fundamental changes to the SASL base spec, other than removal
of rarely used features/mechanisms.  We're having a *very* hard time
deploying security and the last thing we need to do is mess with something
that's just starting to work. 

The negotiation and framing they use is completely different.  The SASL
negotiation occurs within the app protocol, while the TLS negotiation
occurs at a lower level invisible to the app protocol.  The SASL framing
uses just simple counted blocks (with a negotiated max size), while the
TLS framing has many complex rules.

They can't be merged into a single layer without fundamental changes to
one or both.  And their primary design goals were sufficiently different
that I don't see any harm from having both around.

I am strongly opposed to any changes to SASL which would stall the
progression along the standards track.  We need to get security deployed
yesterday, not next year.  It is way too late to change the fundamental
framing mechanisms.

How about a new standards track spec which amends SASL in a
backwards-compatible way so that any SASL mechanism with a security layer
can also negotiate compression? 

Note that this is *not* important enough in my book to merit a
non-backwards-compatible change to SASL.  Compression is a nice way to use
spare CPU cycles to save network bandwidth, but it's far from a
requirement. 

		- Chris

Date: Tue, 19 May 1998 11:48:29 -0400
To: Chris Newman <[email-masked]>, Harald Alvestrand <[email-masked]>
From: "Jack De Winter" <[email-masked]>
Subject: Re: Compression under SASL  was Re: Huffman coding?
Cc: [email-masked]
Sender: [email-masked]

At 12:14 PM 5/18/98 -0800, Chris Newman wrote:
>Finally, I think a compression-only layer is counter-productive.  Let's
>use the desire for compression as a hook to get integrity protection (at
>least) deployed.

Hrm... how about the case where you would like to provide compresses
SMTP access?  Now I know that anonymous logins are possible, but unless
we frame the compression within something like GSSAPI or SCRAM, we would
have to provide <type>-ANON and <type>-CRAM-MD5 as Harald mentioned
earlier.

However, as Chris has pointed out to me in private, there are probably
not going to be that many compression types, so this may not be that
bad.

regards,
Jack

Date: Mon, 18 May 1998 23:06:24 +0200
To: Chris Newman <[email-masked]>
From: Harald Alvestrand <[email-masked]>
Subject: Re: Compression under SASL  was Re: Huffman coding?
Cc: [email-masked]
Sender: [email-masked]

At 12:14 18.05.98 -0800, Chris Newman wrote:
>On Fri, 15 May 1998, Harald Alvestrand wrote:
>> Count me as one of those *not* happy with defining compression as
>> a part of the SASL layer; it's the kitchen sink/hammer analogy again:
>> burdening a layer with things that do not fit there damages that layer.
>
>I'm of the opinion that there should be *at most* one layer between TCP
>and an application protocol.  I prefer putting integrity protection,
>encryption and compression in the same layer since it saves framing
>overhead and implementation complexity which would otherwise be necessary.
>
This reminds me of the "application layer framing" approach that I've
seen bandied about around MMUSIC/AVT. It's a good argument.
But in that case, we may need to turn SASL into Simple Anything Session Layer,
with slots for authentication, encryption, integrity protection and
"we haven't thought of it yet".
Because combinatorial explosion is still a Bad Thing for deployment.

>> (If you want to change the scope of SASL, I think it makes much more
>> sense to define TLS as a SASL mechanism; the special treatment it
>> gets now may make sense at a microscopic level, but at the 10.000 foot
>> level it seems sillier every time I look at it.)
>
>TLS and SASL have different framing mechanisms for their security layers.
>So you can't combine them without breaking one or the other security
>layer.

the exchanges

>Personally, I think it's convenient they're separate given current usage. 
>SSL/TLS is normally used for server authentication and privacy, while SASL
>is normally used for client authentication.  So it often makes sense to
>use both at the same time, which would not be possible if they were
>combined. 

The requirement would be that there at any time be only one of:
- client authentication identity
- client authorization identity
- server authentication identity
- server authorization identity (if there is such a thing)
- protection mechanism
- compression mechanism
- integrity mechanism
and some renegotiations of one should nullify some others.

                        Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

Date: Mon, 18 May 1998 12:14:46 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: Compression under SASL  was Re: Huffman coding?
To: Harald Alvestrand <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Fri, 15 May 1998, Harald Alvestrand wrote:
> Count me as one of those *not* happy with defining compression as
> a part of the SASL layer; it's the kitchen sink/hammer analogy again:
> burdening a layer with things that do not fit there damages that layer.

I'm of the opinion that there should be *at most* one layer between TCP
and an application protocol.  I prefer putting integrity protection,
encryption and compression in the same layer since it saves framing
overhead and implementation complexity which would otherwise be necessary.

> (If you want to change the scope of SASL, I think it makes much more
> sense to define TLS as a SASL mechanism; the special treatment it
> gets now may make sense at a microscopic level, but at the 10.000 foot
> level it seems sillier every time I look at it.)

TLS and SASL have different framing mechanisms for their security layers.
So you can't combine them without breaking one or the other security
layer.

Personally, I think it's convenient they're separate given current usage. 
SSL/TLS is normally used for server authentication and privacy, while SASL
is normally used for client authentication.  So it often makes sense to
use both at the same time, which would not be possible if they were
combined. 

Now you wouldn't want to use TLS and SASL's security layer at the same
time, because that's an unnecessary (and redundant) layer.

Finally, I think a compression-only layer is counter-productive.  Let's
use the desire for compression as a hook to get integrity protection (at
least) deployed.

		- Chris

Date: Fri, 15 May 1998 10:29:11 -0400
To: Harald Alvestrand <[email-masked]>, [email-masked] (Kai Henningsen), [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: Re: Compression under SASL  was Re: Huffman coding?
Sender: [email-masked]

At 10:04 AM 5/15/98 +0200, Harald Alvestrand wrote:
>Count me as one of those *not* happy with defining compression as
>a part of the SASL layer; it's the kitchen sink/hammer analogy again:
>burdening a layer with things that do not fit there damages that layer.
>
>(If you want to change the scope of SASL, I think it makes much more
>sense to define TLS as a SASL mechanism; the special treatment it
>gets now may make sense at a microscopic level, but at the 10.000 foot
>level it seems sillier every time I look at it.)

Well, I do remember John trying to do this and getting tonnes of
problems, mainly stemming from the double framing that would go
on.  

I had a look over TLS specs the past couple of days, and I seem to
have made the following observations:

1) Compression seems to be a sideline.  From page 29 of the TLS main
draft, it says that "a client and server will always be able to agree
on a compression method".  My problem with this is that it does not allow
me to set a policy of "anything from [a.b.c.d] must use on of the following
compression methods.
	1a) Because of this, it does not seem to have any way to indicate
		that compression negotiation failed.

2) Unless I am severely misreading this, there is no way to specify
   NULL/NULL/NULL for the connection.  That is no key exchange, no
   cipher and no hash.  For the anonymous example, this is a serious
   impediment.  This means that using TLS between two SMTP servers,
   where those servers did not "know" each other would prevent the use
   of TLS, and hence, any compression that may have been gained is lost.
   2a) There are several places in the TLS docs that state that
       NULL/NULL/NULL is a starting state and is not permitted for the
       connection, as it does not add any extra security.

Because of these "facts" (more like "because of my understanding of the
facts presented in the TLS draft"), I would say that mandatory compression
is not well suited to TLS due to the above points.

As such, I would still like to see extra comments about compression using
SASL, be it combining it with existing types or using an extra parameter.

regards,
Jack

Date: Fri, 15 May 1998 10:04:06 +0200
To: "Jack De Winter" <[email-masked]>, [email-masked] (Kai Henningsen), [email-masked]
From: Harald Alvestrand <[email-masked]>
Subject: Re: Compression under SASL  was Re: Huffman coding?
Sender: [email-masked]

At 12:53 14.05.98 -0400, Jack De Winter wrote:
>2) The SASL mechanism handler would be able to enforce Harald's
>   "rule" that compression should be done before encryption.

It's not my rule, just an observation that compression after encryption
is 100% useless - an encrypted bitstream is, almost by definition,
indistinguishable in statistical properties from random noise, and
random noise does not compress very well.

Count me as one of those *not* happy with defining compression as
a part of the SASL layer; it's the kitchen sink/hammer analogy again:
burdening a layer with things that do not fit there damages that layer.

(If you want to change the scope of SASL, I think it makes much more
sense to define TLS as a SASL mechanism; the special treatment it
gets now may make sense at a microscopic level, but at the 10.000 foot
level it seems sillier every time I look at it.)

                       Harald

Harald Tveit Alvestrand
IETF Area Director, Operations and Management
NOTE: No longer Area Director for Applications.

Date: Thu, 14 May 1998 11:32:04 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Compression under SASL  was Re: Huffman coding?
To: Jack De Winter <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Thu, 14 May 1998, Jack De Winter wrote:
> Well, seeing as this has got the ball rolling, could people voice
> their opinions regarding compression under SASL, pros and cons, and
> whether or not they believe that compression types should be placed
> under SASL (along with reasons why and why not)?

In general, I think a compression layer should be done in combination
with a security layer (integrity/privacy protection).  Adding a new layer
is fairly expensive and making multiple layers above the TCP level work
well is hard.  This follows the "avoid unnecessary layers" design goal.

I'll point out that you may be better off using TLS for compression since
the feature is already built in and the TLS layer is more popular than the
SASL security layer (SASL is more popular for client authentication than
TLS).

If you do compression under SASL, pick only one good algorithm. 
Compression has diminishing returns, so if you start with a good-enough
algorithm, then it's not worth suffering the interoperability problems
necessary to upgrade.  I recommend zlib-deflate because it's good-enough,
already documented in RFC 1950/1951 and it's patent-free.

Security layers are currently negotiated by asking for "integrity" or
"privacy" protection.  Add one more bit to negotiate "zlib-deflate"
compression.  This is a backwards compatible change to the KERBEROS_V4, 
GSSAPI and SCRAM-MD5 mechanisms.  Mechanisms without a security layer
will either have to be revised to add one, or left alone.

Since SCRAM-MD5 is backwards compatible with CRAM-MD5 and supports a
security layer, I'd say that doing just CRAM-MD5 plus compression would be
a waste of time.

		- Chris

Date: Thu, 14 May 1998 12:53:26 -0400
To: Harald Alvestrand <[email-masked]>, [email-masked] (Kai Henningsen), [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: Compression under SASL  was Re: Huffman coding?
Sender: [email-masked]

At 08:48 AM 5/14/98 +0200, Harald Alvestrand wrote:
>I don't think you have seriously thought about the deployment issue.
>If we have 15 different compression algorithms being defined through
>SASL schemes, and 15 implementations choose 4 at random, the chances
>of any two of these parties being able to communicate in compressed mode
>become microscopic.
>
>There's also a combinatorial explosion with authentication schemes;
>do you really, really want to do KERBEROS-HUFFMAN, KERBEROS-ZLIB,
>GSSAPI-HUFFMANN, GSSAPI-ZLIB,  SKEY-HUFFMAN, SKEY-ZLIB et cetera ad
>nauseam ad infinitum?

Very important point, and one that I have not overlooked, but was hoping
to get input from the community on.

Right now, it looks like SASL is being adopted throughout the IETF community
in the various specs (ACAP, SMTP, POP3, IMAP to name a few).  From what
John Meyers mentioned one time, that road of getting authentication
(and compression) to be distributed in such a fashion has been a long
and painful road.

Compression is something that a lot of people are asking for.  If we
have to go through the same thing again, I fear it would never get done.
As such, I asked John about compression one time, and he thought it was
a good idea.

>You already have a "null" authentication, it's called "anonymous".
>But I think this approach has serious problems. I'd rather see if you
>could make it an orthogonal attribute of the connection.
>And remember - when doing encryption, compression must be applied
>*before* encryption.

You know... I had totally missed that one.

Personally, I would prefer to see compression stay within SASL's scope.
A good way to do this might be to extend SASL to allow for an optional
compression type.  A possibility might be:

A01 AUTHENTICATE-COMP <auth-mechanism> <comp-mechanism> <auth-start-data>

I would prefer to see "AUTHENTICATE" by itself, but then there would be
no way of knowing that the second parameter is a compression mechanism
versus the authentication mechanism's start data.

Pros
1) Uses deployed architecture, with minor changes to the authentication
   invocation mechanism and capabilities mechanism (if supported).
2) The SASL mechanism handler would be able to enforce Harald's
   "rule" that compression should be done before encryption.
3) Would use existing deployment to deliver compression to the protocols
   that support it with little change.

Cons
???

Well, seeing as this has got the ball rolling, could people voice
their opinions regarding compression under SASL, pros and cons, and
whether or not they believe that compression types should be placed
under SASL (along with reasons why and why not)?

regards,
Jack

Date: Thu, 14 May 1998 08:48:32 +0200
To: "Jack De Winter" <[email-masked]>, [email-masked] (Kai Henningsen), [email-masked]
From: Harald Alvestrand <[email-masked]>
Subject: Re: Huffman coding?
Sender: [email-masked]

At 11:06 13.05.98 -0400, Jack De Winter wrote:
>At 11:54 AM 5/12/98 +0200, Harald Alvestrand wrote:
>>At 10:44 11.05.98 -0400, Jack De Winter wrote:
>>>Just as a side note, I am preparing a document on AHUFFMAN-CRAM-MD5,
>>>and would appreciate anyone who would like to look over it with me
>>>and give it a good first pass.  It supports Adaptive Huffman encoding
>>>with a CRAM-MD5 authenticator.
>>
>>Interesting....how did you end up with Huffman, and not zlib, deflate,
>>lz77 or one of the other compression algorithms?
>>It's been a long time since I've seen Huffman seriously mentioned....
>
>well, huffman is considered a "base" type in most computing circles, and
>I thought it would be a good place to start, and then to progress on to
>the other types.  This is kind of like CRAM-MD5 for authentication.
>CRAM-MD5 is simple and easy to implement.

I don't think you have seriously thought about the deployment issue.
If we have 15 different compression algorithms being defined through
SASL schemes, and 15 implementations choose 4 at random, the chances
of any two of these parties being able to communicate in compressed mode
become microscopic.

There's also a combinatorial explosion with authentication schemes;
do you really, really want to do KERBEROS-HUFFMAN, KERBEROS-ZLIB,
GSSAPI-HUFFMANN, GSSAPI-ZLIB,  SKEY-HUFFMAN, SKEY-ZLIB et cetera ad
nauseam ad infinitum?

>we have plans to put out docs for the others as well, just wanted
>to gauge if using SASL was a generally accepted good method for
>compression first, or if we need to go to a different access mechanism.
>the one downfall of compression under SASL is the need for authentication,
>unless we come up with a "NULL" authentication type.
>
You already have a "null" authentication, it's called "anonymous".
But I think this approach has serious problems. I'd rather see if you
could make it an orthogonal attribute of the connection.
And remember - when doing encryption, compression must be applied
*before* encryption.

                    Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

Date: Wed, 13 May 1998 14:46:16 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: SASL ABI?
To: Rob Earhart <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Tue, 12 May 1998, Rob Earhart wrote:
>   We're looking into implementing a SASL API, and realized that it'd be good
> to have some sort of SASL configuration/ABI definition to answer questions
> like
> 
> 	Where do modules live?
> 	How do we access them on a given system?
> 	Where does site-configuration live?
> 	What's the format of the site-configuration?
> 
>   Configuration's useful because we'd like to be able to have sites be able
> to say things like "Use Kerberos for IMAP connections on-site, and anything
> but plaintext off-site," - that is, we think it's useful for sites to be
> able to define their own security policies on a per-protocol basis (and to
> be able to write/purchase additional security plugins for existing
> applications).
> 
>   So has anyone looked into this?  Any thoughts/comments?  It doesn't seem
> like this'd be too hard to define, but I think it'd be a good idea to define
> it in a standard way if we're going to do it at all, and if someone's done
> it already I'd rather reuse existing work, if possible.  :-)

I've been working on all these issues, at least for our product.

The important thing for the ABI is to have the exact API with parameter
sizes, and the shared library compiliation options.

As for config files, I'm not sure it's worth the work to document a common
format.  Different products have different configuration models.  I'd be
glad to share what we're doing as the design of config files for this is
quite tricky (I had to go through a couple cycles of implement &
re-design).

Our current model for the server side is as follows:

There's a mapping table and security config file. The mapping table has
the following structure:

 TCP|local-ip|local-port|remote-ip|remote-port   $Y<ruleset>|<user-domain>
 TCP|local-ip|local-port|remote-ip|remote-port   $N<refusal string>

$N means refuse connections, dumping the refusal string down the port
before closing it.  $Y means accept connections with "ruleset" as the name
of the security ruleset to use and "user-domain" as the user namespace to
use (for support of multiple domains on the same host). 

The security config we're using is broken into sections by security
ruleset and authentication source:

[RULESET=default]
ENABLE=<plugin-name>/<mechanism>,...
...
[AUTH_SOURCE=plugin-name]
IMAGE=<filename>
FUNCTION=<entry_point_name>
...

Each plugin serves an authentication source, and provides one or more SASL
mechanisms.  Authentication sources can be built-in or dynamically loaded
as specified by the [AUTH_SOURCE=...] section of the config file.

I believe this is sufficiently flexible and extensible, but I'm not sure
others will want to use the same syntax and certainly won't want the same 
locations for the config file.

		- Chris

Date: Wed, 13 May 1998 11:06:49 -0400
To: Harald Alvestrand <[email-masked]>, [email-masked] (Kai Henningsen), [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: Re: Huffman coding?
Sender: [email-masked]

At 11:54 AM 5/12/98 +0200, Harald Alvestrand wrote:
>At 10:44 11.05.98 -0400, Jack De Winter wrote:
>>Just as a side note, I am preparing a document on AHUFFMAN-CRAM-MD5,
>>and would appreciate anyone who would like to look over it with me
>>and give it a good first pass.  It supports Adaptive Huffman encoding
>>with a CRAM-MD5 authenticator.
>
>Interesting....how did you end up with Huffman, and not zlib, deflate,
>lz77 or one of the other compression algorithms?
>It's been a long time since I've seen Huffman seriously mentioned....

well, huffman is considered a "base" type in most computing circles, and
I thought it would be a good place to start, and then to progress on to
the other types.  This is kind of like CRAM-MD5 for authentication.
CRAM-MD5 is simple and easy to implement.  

we have plans to put out docs for the others as well, just wanted
to gauge if using SASL was a generally accepted good method for
compression first, or if we need to go to a different access mechanism.
the one downfall of compression under SASL is the need for authentication,
unless we come up with a "NULL" authentication type.

regards,
Jack

Reply-To: <[email-masked]>
From: "Rob Earhart" <[email-masked]>
To: <[email-masked]>
Subject: SASL ABI?
Date: Tue, 12 May 1998 17:06:24 -0400
Importance: Normal
Sender: [email-masked]

  We're looking into implementing a SASL API, and realized that it'd be good
to have some sort of SASL configuration/ABI definition to answer questions
like

	Where do modules live?
	How do we access them on a given system?
	Where does site-configuration live?
	What's the format of the site-configuration?

  Configuration's useful because we'd like to be able to have sites be able
to say things like "Use Kerberos for IMAP connections on-site, and anything
but plaintext off-site," - that is, we think it's useful for sites to be
able to define their own security policies on a per-protocol basis (and to
be able to write/purchase additional security plugins for existing
applications).

  So has anyone looked into this?  Any thoughts/comments?  It doesn't seem
like this'd be too hard to define, but I think it'd be a good idea to define
it in a standard way if we're going to do it at all, and if someone's done
it already I'd rather reuse existing work, if possible.  :-)

  )Rob

Date: Tue, 12 May 1998 11:54:02 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: regarding the mention of NIS Authentication...
To: Jack De Winter <[email-masked]>
Cc: IETF SASL Discussion List <[email-masked]>
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Thu, 7 May 1998, Jack De Winter wrote:
> well, was browsing through comp.mail.imap in my "spare"
> time, and someone was asking about IMAP supporting NIS
> authentication.  Seeing as IMAP supports SASL, I thought
> the best place to pass the questions on was here.
> 
> 1) Anyone know what NIS authentication is?
> 2) Is it relevant/needed under SASL?

NIS is a system designed by Sun to centrally manage passwords at small
sites.  It is full of security holes.  NIS basically requires plaintext
passwords, so the SASL PLAIN mechanism suffices.

		- Chris

To: IETF SASL Discussion List <[email-masked]>
Subject: Re: GSSAPI and SASL
From: Ken Raeburn <[email-masked]>
Date: 09 May 1998 16:32:02 -0400
Lines: 62
Sender: [email-masked]

Steve Hole <[email-masked]> writes:

> > I must be missing something.  I read this as implying that the first
> > SASL auth mechanism you try should be the only one, at least without
> > "explicit server permission".  E.g., if my krb5 tickets don't exist or
> > have expired, thus causing GSSAPI authentication to fail, are you
> > suggesting the client shouldn't even try using krb4 tickets?  Working
> > in an environment that mixes krb5 and krb4, I like having applications
> > fall back, myself.
> 
> In this example, the krb5 SASL mechanism would not even be started because
> your krb5 SASL driver (actually GSSAPI) would detect the fact that you 
> do not have proper credentials and would not enter into a GSSAPI negotiation.
> Therefore no fallback occurs to go to krb4 -- you would start with krb4.
> If you have valid krb5 credentials and you fail to authenticate, then you 
> failed to authenticate.   If a server only supports krb4 tickets then it
> will advertise only the krb4 mechanism and once again, the client will never
> attempt the krb5 mechanism.

Ah, I see.  You're thinking of fallback in terms of the authentication
attempts sent to the server; I was thinking of what SASL mechanisms
the SASL library (if there is one) or application code invokes.  So I
would call the above a fallback (since GSSAPI was attempted and
failed, and it just happened to be a locally detected problem of a
particular kind), but you would not.  Sorry for the confusion.

I've got to go back to the GSSAPI spec to see for sure, but I assume
the error codes returned are sufficient to decide whether or not to
try another SASL mechanism (without getting server permission etc)?

> Let me restate the point.    If your client believes that it has correct and
> sufficient information to initiate a particular SASL mechanism, AND that
> mechanism is supported by the server, AND you initiate the mechanism using
> the appropriate protocol "AUTHENTICATE" command, then failure to authenticate
> using that mechanism should be final unless:
> 
> 1. the server explicitly allows you to "fallback" to another mechanism -- 
> presumably less desirable.   And, by the way, it is reasonably easy to decide,
> as a developer, which is stronger and which is weaker.   As a site
> administrator, you will be informed by your vendor which is stronger and 
> which is weaker so that you can establish clear security policies.

Since different sites, or even different machines at a site, may have
different admins and different vendors, there'll probably be some
disagreement as to which is better and which is worse, and the
decision will probably be more political than technical in some cases.
But the client and server should still be able to find one or more
mechanisms acceptable to both of them.

I still need to go look at the stuff Chris mentioned....

> > If krb4 (for example) is considered too weak, why does your SASL
> > configuration ever allow it?
> 
> It's not weak at all.

Your message said "[if GSSAPI fails, you] shouldn't try anything
weaker."  And you were talking about not falling back at all without
permission.  I guess I read in more to that combination that you
meant.  I don't consider krb4 to be especially weak either, though I'd
prefer triple-DES or something else better than plain DES, if I
weren't stuck in this mixed environment.

Date: Thu, 07 May 1998 12:14:52 -0400
To: IETF SASL Discussion List <[email-masked]>
From: "Jack De Winter" <[email-masked]>
Subject: regarding the mention of NIS Authentication...
Sender: [email-masked]

well, was browsing through comp.mail.imap in my "spare"
time, and someone was asking about IMAP supporting NIS
authentication.  Seeing as IMAP supports SASL, I thought
the best place to pass the questions on was here.

1) Anyone know what NIS authentication is?
2) Is it relevant/needed under SASL?

regards,
Jack

From: Steve Hole <[email-masked]>
Date: Mon, 4 May 1998 10:51:09 -0600
To: IETF SASL Discussion List <[email-masked]>
Subject: Re: GSSAPI and SASL
Sender: [email-masked]

Message-ID: <[email-masked]>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 5.0 Preview Build (9)
MIME-Version: 1.0
Content-Type: Multipart/signed; BOUNDARY=Part9805041051.B; protocol="application/pgp-signature"; micalg=pgp-sha1

--Part9805041051.B
Content-Type: Text/PLAIN; CHARSET=US-ASCII

On 01 May 1998 15:28:10 -0400 Ken Raeburn <[email-masked]> wrote:

> Steve Hole <[email-masked]> writes:
> 
> > On a side note, operational experience with fallback between SASL mechanisms 
> > has shown me that client fallback really should occur only with explicit 
> > server permission.    In most cases, if you offer a GSSAPI level 
> > authentication service, and authentication fails, you probably failed for
> > a good reason and you really shouldn't try anything weaker.    You should fix
> > configuration issue that prevents you from authenticating. 
> 
> I must be missing something.  I read this as implying that the first
> SASL auth mechanism you try should be the only one, at least without
> "explicit server permission".  E.g., if my krb5 tickets don't exist or
> have expired, thus causing GSSAPI authentication to fail, are you
> suggesting the client shouldn't even try using krb4 tickets?  Working
> in an environment that mixes krb5 and krb4, I like having applications
> fall back, myself.

In this example, the krb5 SASL mechanism would not even be started because
your krb5 SASL driver (actually GSSAPI) would detect the fact that you 
do not have proper credentials and would not enter into a GSSAPI negotiation.
Therefore no fallback occurs to go to krb4 -- you would start with krb4.
If you have valid krb5 credentials and you fail to authenticate, then you 
failed to authenticate.   If a server only supports krb4 tickets then it
will advertise only the krb4 mechanism and once again, the client will never
attempt the krb5 mechanism.

Let me restate the point.    If your client believes that it has correct and
sufficient information to initiate a particular SASL mechanism, AND that
mechanism is supported by the server, AND you initiate the mechanism using
the appropriate protocol "AUTHENTICATE" command, then failure to authenticate
using that mechanism should be final unless:

1. the server explicitly allows you to "fallback" to another mechanism -- 
presumably less desirable.   And, by the way, it is reasonably easy to decide,
as a developer, which is stronger and which is weaker.   As a site
administrator, you will be informed by your vendor which is stronger and 
which is weaker so that you can establish clear security policies.

2. the "failed" mechanism allows the application to "try again" with the
same mechanism.   This is very useful for CRAM-MD5 and PLAIN where credentials
are user supplied and prone to typing errors.

> If krb4 (for example) is considered too weak, why does your SASL
> configuration ever allow it?

It's not weak at all.   Simeon does preferential listing of GSSAPI and krb4
at the same level.   It will try GSSAPI first simply because GSSAPI security
modules are likely to be OS or site provided and (probably) best expresses the
site security policy.   Operational experience shows that they are rarely 
jointly installed, and even when they are, they don't collide.   There are 
definitely better and worse implementations of GSSAPI however which can get
mixed up between the krb5 and krb4 thing -- but that is well before it gets
to the SASL support inside any application like Simeon.
 
> And what would constitute "explicit server permission"?

Chris answered this in his followup.   What he said.

Cheers.
---  
Steve Hole                           
The Esys Corporation
Mailto:[email-masked]  
Phone:403-424-4922

--Part9805041051.B
Content-Type: Application/pgp-signature

--Part9805041051.B--

To: IETF One-Time-Password WG <[email-masked]>
cc: [email-masked]
Subject: Re: New OTP SASL draft 
Date: Fri, 01 May 1998 16:41:02 -0300
From: Craig Metz <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, you 
write:
>Support for alternate dictionaries is mandatory for the server.  This is
>only a small burden for the server, and it permits the six-word format to
>be non-English.  Multinational support is important for applications and
>making alternate dictionaries mandatory on the server reduces
>interoperability issues.
...
>Final review of this specification would be appreciated.  I'm hoping only
>editorial changes will be necessary prior to IETF last call.

  Operational experience with alternate dictionaries has what I consider to
be crystal clear results. All that making them mandatory does is make it that
much less likely that people will implement this specification. Many existing
OTP implementations have not implemented alternate dictionaries and are not
likely to do so any time soon.

									-Craig

Date: Fri, 01 May 1998 12:57:00 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: GSSAPI and SASL
To: Ken Raeburn <[email-masked]>
Cc: IETF SASL Discussion List <[email-masked]>
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Fri, 1 May 1998, Ken Raeburn wrote:
> And what would constitute "explicit server permission"?

The "TRANSITION-NEEDED" response code as documented in:
	draft-newman-sasl-plaintrans-04.txt

It has some serious security considerations, but it does allow a site to
gracefully deploy something more secure than plaintext passwords without
resetting the passwords for all users.  All in all a net gain for site
security.

Of course, that particular draft is dead for political reasons, but half
of it has moved to draft-newman-tls-imappop-04.txt, and I plan to
eventually do a draft on protocol authentication response codes (after
SMTP AUTH and POP3 extensions have moved through the standards pipeline). 

		- Chris

To: IETF SASL Discussion List <[email-masked]>
Subject: Re: GSSAPI and SASL
From: Ken Raeburn <[email-masked]>
Date: 01 May 1998 15:28:10 -0400
Lines: 22
Sender: [email-masked]

Steve Hole <[email-masked]> writes:

> On a side note, operational experience with fallback between SASL mechanisms 
> has shown me that client fallback really should occur only with explicit 
> server permission.    In most cases, if you offer a GSSAPI level 
> authentication service, and authentication fails, you probably failed for
> a good reason and you really shouldn't try anything weaker.    You should fix
> configuration issue that prevents you from authenticating. 

I must be missing something.  I read this as implying that the first
SASL auth mechanism you try should be the only one, at least without
"explicit server permission".  E.g., if my krb5 tickets don't exist or
have expired, thus causing GSSAPI authentication to fail, are you
suggesting the client shouldn't even try using krb4 tickets?  Working
in an environment that mixes krb5 and krb4, I like having applications
fall back, myself.

If krb4 (for example) is considered too weak, why does your SASL
configuration ever allow it?

And what would constitute "explicit server permission"?

Date: Fri, 01 May 1998 11:21:14 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: New OTP SASL draft
To: IETF One-Time-Password WG <[email-masked]>
Cc: [email-masked]
Reply-to: IETF One-Time-Password WG <[email-masked]>
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

I just submitted a new OTP SASL draft to the internet-drafts editor.

A preview copy is available on the web at:
  <http://www.innosoft.com/iii/persons/chris/otpsasl.txt>
or in heuristicly generated html:
  <http://www.innosoft.com/iii/persons/chris/otpsasl.html>

This now defines only one OTP SASL mechanism (rather than OTP-MD5 and
OTP-SHA1 as the old version did).

Two other things of note:

Support for alternate dictionaries is mandatory for the server.  This is
only a small burden for the server, and it permits the six-word format to
be non-English.  Multinational support is important for applications and
making alternate dictionaries mandatory on the server reduces
interoperability issues.

I added an IANA considerations section which explicitly amends the
"intended usage" of the SKEY SASL mechanism to OBSOLETE. 

Final review of this specification would be appreciated.  I'm hoping only
editorial changes will be necessary prior to IETF last call.

		- Chris