Subject: Re: WG Action: Simple Authentication and Security Layer (sasl)

From: "Raif S. Naffah" <[email-masked]>
Date: Fri, 20 Dec 2002 06:25:35 +1100

On Friday 20 December 2002 05:46, The IESG wrote:
> A new working group has been formed in the Security Area of the IETF.
> For additional information, contact the Area Directors
> or the WG Chair.
> ...
>  Description of Working Group:
> ...
> This group will deliver a revised SASL Technical Specification
> suitable for consideration as a Draft Standard. This work will be
> based upon RFC 2222 and draft-myers-saslrev.
>
> This group will deliver revised Technical Specifications suitable for
> consideration as Draft Standards for the following SASL mechanisms:
> ANONYMOUS, PLAIN, CRAM-MD5, DIGEST-MD5, and EXTERNAL. This work will
> be based upon RFC 2195, RFC 2222, RFC 2831, draft-zeilenga-sasl-anon,
> draft-zeilenga-sasl-plain, draft-nerenberg-sasl-crammd5 and
> draft-melnikov-rfc2831bis, and draft-myers-saslrev-xx.txt.
>
> This group will deliver a revised Technical Specification suitable
> for publication as Proposed Standard for the GSSAPI family of SASL
> mechanisms. This work will be based upon RFC 2222 and
> draft-ietf-cat-sasl-gssapi.

in the proposal for the creation of this WG, there was an additional 
objective:

> Message-Id: <[email-masked]>
> From: The IESG <[email-masked]>
> To: IETF-Announce: ;
> Subject: WG Review:  Simple Authentication and Security Layer (sasl)
> Date: Thu, 05 Dec 2002 19:11:53 -0500
> ...
> This group will deliver a Technical Specification suitable for
> publication as Proposed Standard describing a family of SASL
> mechanisms using the Secure Remote Password [RFC2945] protocol.  This
> work will be based upon draft-burdis-cat-srp-sasl.

why this is not part of the deliverables of this WG anymore?

cheers;
rsn

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Dec 2002 18:55:18 -0500

>>>>> "Raif" == Raif S Naffah <[email-masked]> writes:

    Raif> why this is not part of the deliverables of this WG anymore?

Jeff indicated that because of intellectual property concerns the IESG
believes we should not include SRP in the set of documents we produce.

Note that people can still work on a SRP mechanism as an individual
submission and can ask the members of this list to review it.

---

From: "Raif S. Naffah" <[email-masked]>
Date: Fri, 20 Dec 2002 06:25:35 +1100

cheers;
rsn

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Dec 2002 18:55:18 -0500

To: [email-masked]
Cc: [email-masked]
Subject: Re: WG Action: Simple Authentication and Security Layer (sasl)
From: Sam Hartman <[email-masked]>
Date: Thu, 19 Dec 2002 18:55:18 -0500
Sender: [email-masked]

From: "Raif S. Naffah" <[email-masked]>
Reply-To: [email-masked]
To: The IESG <[email-masked]>, IETF-Announce: ;, @solomon.fl.net.au
Subject: Re: WG Action: Simple Authentication and Security Layer (sasl)
Date: Fri, 20 Dec 2002 06:25:35 +1100
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

cheers;
rsn

Date: Thu, 19 Dec 2002 11:15:34 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Fwd: WG Action: Simple Authentication and Security Layer (sasl)
Sender: [email-masked]

>Cc: [email-masked], [email-masked]
>Subject: WG Action: Simple Authentication and Security Layer (sasl)
>Date: Thu, 19 Dec 2002 13:46:28 -0500
>
>
>Simple Authentication and Security Layer (sasl)
> -----------------------------------------------
>
>   Current Status: Active Working Group
>
>   Chair(s):
>           Sam Hartman <[email-masked]>
>           K. Zeilenga <[email-masked]>
>
>   Security Area Director(s):
>           J. Schiller <[email-masked]>
>           Steve Bellovin <[email-masked]>
>
>   Security Area Advisor:
>           J. Schiller <[email-masked]>
>
>   Mailing Lists: 
>           General Discussion:[email-masked]
>           To Subscribe: [email-masked]
>                   In Body: subscribe
>           Archive: http://www.imc.org/ietf-sasl/mail-archive/
>
>The Simple Authentication and Security Layer [RFC2222] provides key 
>security services to a number of application protocols including BEEP, 
>IMAP, LDAP, POP, and SMTP. The purpose of this working group is to 
>shepherd SASL, including select SASL mechanisms, through the Internet 
>Standards process.
>
>This group will deliver a revised Technical Specification suitable for 
>publication as Proposed Standard for the GSSAPI family of SASL 
>The following areas are not within the scope of work of this WG:
>
>- new features,
>- SASL Mechanisms not specifically mentioned above, and
>- SASL "profiles".
>
>However, the SASL WG is an acceptable forum for review of SASL-related 
>submissions produced by others as long as such review does not impede 
>progress on the WG objectives listed above.
>
>Goals and Milestones:
>
>JAN 03 Submit revised SASL (+ EXTERNAL) I-D 
>
>JAN 03 Submit revised SASL ANONYMOUS I-D 
>
>JAN 03 Submit revised SASL PLAIN I-D 
>
>JAN 03 Submit revised SASL CRAM-MD5 I-D 
>
>JAN 03 Submit revised SASL DIGEST-MD5 I-D 
>
>JAN 03 Submit revised SASL GSSAPI I-D 
>
>JUN 03 Submit Implementation Report 
>
>JUL 03 Submit revised SASL, CRAM-MD5, DIGEST-MD5 I-Ds with 
>        Implementation Report to IESG for consideration as a Draft 
>        Standard 
>
>JUL 03 Submit revised SASL GSSAPI I-D to IESG for consideration as 
>        a Proposed Standard 
>
>AUG 03 Revise charter or conclude 

Date: Wed, 18 Dec 2002 11:57:04 -0800
From: Marshall Rose <[email-masked]>
To: [email-masked]
Subject: can i get some help with the unwashed?
Organization: Dover Beach Consulting, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

--Multipart_Wed__18_Dec_2002_11:57:04_-0800_081c6a00
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

hi. can some folks from this list pop over to [email-masked] and
explain to some of the highly-opinionated new arrivals why sasl is a
good thing? my gut reaction is to write the guy off as a
mini-me-for-djb, but perhaps i should be more kind in my old age.

specifically, the ietf chartered a syslog wg some time ago. the wg
developed two specs for doing syslog, one is "reliable syslog", which is
beep-based where you pick the bells-and-whistles you want, and the other
is "signed syslog", which is udp-based with some clever crypto to
provide in-order delivery over a certain timeframe.

the folks at sdsc produced an implementation of reliable syslog and
announced it on the [email-masked] list, where some folks
hit the roof because what got standardized doesn't match their model.

as expected, the arguments boil down to: just run tcp/ssl and it's all good.

so i try to start the education process by asking why sasl got put into the
ietf's apps if we already had tls.

the response i got back is such a discontinuity from the real world that i'm
tempted to just ignore it.  however, some folks on this list might feel a need
to bring light to the masses, so  i'm forwarding this note here.

/mtr

ps: obviously, i see the "we hate beep" stuff from time-to-time, and
frankly, i don't really care. if someone sits down and does the work,
they'll figure out why. however, since the message is specifically
about sasl, i thought i'd bring it up here...

"enjoy!"
    
/mtr

--Multipart_Wed__18_Dec_2002_11:57:04_-0800_081c6a00
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Delivery-Date: Wed, 18 Dec 2002 06:11:28 -0800
Date: Wed, 18 Dec 2002 09:08:52 -0500
From: Bennett Todd <[email-masked]>
To: Marshall Rose <[email-masked]>
Cc: [email-masked]
Subject: Re: Any chance for a Simple Reliable Syslog Protocol?

--uh9ZiVrAOUUm9fzH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

2002-12-17-18:11:43 Marshall Rose:
> here's an interesting thought experiment: if TLS (nee SSL) is
> around, why did the IETF add SASL to all of its application
> protocols?

Errh, because the Cyrus team implemented it, and nobody was
offering a better way to stuff authentication into SMTP? The
hideous overcomplexity of SASL has been the main barrier to getting
authenticated SMTP more widely deployed. Notably, the Cyrus SASL
libraries --- the only SASL implementation available[1] --- have
been found to have security bugs in them.

> to understand the answer to this, is to understand why TLS, while
> very good at what it does, doesn't meet the requirements of many
> environments.

To understand why SMTP auth is so rarely deployed, and why so many
people are using the revolting pop-before-smtp kluge instead, is to
understand why wading off into the bright open and inventing your
own crypto protocols from scratch is best avoided.

> here are two hints: kerberized enterprises?

Haven't ever cared especially; even when I've worked in a totally
kerberized enterprise, certs were just as good for host-to-host
auth (and operationally equivalent). But now that I do a quick RFC
search, it looks like RFC 2712 describes Kerberos authentication for
TLS, so it looks like someone decided to enable the general-purpose
tool to encompass that problem.

> integrity-sans-privacy?

I'm having trouble envisioning a real motivation for that, but it
seems to be supported within TLS as it stands, BulkCipherAlgorithm
null.

> again, it's not that TLS isn't adequate, it's perfectly adequate
> and extensible for its mission. the problem is that its mission
> may not have quite the reach that a lot of folks require...

Before concluding that, it's good to make positively certain TLS
can't do the job as it stands, and that it's impractical to extend
it, before going out and re-inventing the functionality; there's a
lot of engineering benefit to re-using existing analysis and
implementation, and if the existing protocol is inadequate for a new
job, better to extend it, and thereby leave it fitted to a broader
set of tasks, then re-implementing the functionality elsewhere.

I really think the security needs of syslog are best met by just
getting it off UDP and onto TCP, whereupon it's easy to transport it
securely.

-Bennett

[1] I've heard of other SASL library implementation attempts. I
    haven't heard of any that got far enough to be a viable
    alternative to Cyrus SASL for a real application.

--uh9ZiVrAOUUm9fzH
Content-Type: application/pgp-signature
Content-Disposition: inline

--uh9ZiVrAOUUm9fzH--

--Multipart_Wed__18_Dec_2002_11:57:04_-0800_081c6a00--

Date: Tue, 10 Dec 2002 09:16:12 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: "Peter 'Luna' Runestig" <[email-masked]>
CC: Hack Kampbjorn <[email-masked]>, [email-masked], Cyrus SASL Mailing List <[email-masked]>
Subject: Re: OPENSSL_VERSION_NUMBER (Was: Cyrus SASL 2.1.10 Released)
Sender: [email-masked]

Oops!

I pulled the wrong SASL address out of my address book.  Please do not
send any more replies to ietf-sasl.

Ken

Peter 'Luna' Runestig wrote:
> 
> Ken Murchison wrote:
> > OK.  I now have two conflicting reports regarding testing for
> > OPENSSL_VERSION_NUMBER with OpenSSL 0.9.7 (both quoted below).  Could
> > somebody who has 0.9.7 installed please try to figure out what the deal
> > is?  I tend to believe that I was originally correct in including the
> > check,
> 
> Back to my original question then: why? Why treat OpenSSL version 0.9.7
> and above different than the previous versions? Is there any change in
> the MD5 code between those versions (I don't think so, not anything that
> affects this issue anyway)?
> 
> Anyway, here's what happens to me, if 'MD5_H' isn't defined:
> 
> $ ./configure --with-openssl=/usr/local
> [tweak the Makefiles to make Kerberos somewhat compile (RH 7.2)]
> [snip a lot of other output]
> /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..
> -I/usr/kerberos/include -I/usr/kerberos/include/kerberosIV -I../include
> -I../lib -I../sasldb  -I/usr/local/include -I/usr/local/include  -Wall
> -W -Wall -g -O2 -c otp.c
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/kerberos/include
> -I/usr/kerberos/include/kerberosIV -I../include -I../lib -I../sasldb
> -I/usr/local/include -I/usr/local/include -Wall -W -Wall -g -O2 -c otp.c
>   -fPIC -DPIC -o otp.lo
> In file included from ../include/saslplug.h:11,
>                   from otp.c:60:
> ../include/md5.h:30: conflicting types for `MD5_CTX'
> /usr/local/include/openssl/md5.h:103: previous declaration of `MD5_CTX'
> make[2]: *** [otp.lo] Error 1
> 
> Yes, the name 'MD5_CTX' is used in both OpenSSL and SASL "native" MD5,
> so that clash was sure to come.
> 
> > and I'm confused as to why it doesn't work for Peter using the
> > same release as Hack.
> 
> So am I! But I have another remark further down here:
> 
> > Ken
> >
> >
> > Hack Kampbjorn wrote:
> >>
> >> More problems: with cyrus-sasl version 2.1.9 plugins/otp.c only defined
> >> MD5_H for OpenSSL versions < 0.9.7 but in version 2.1.10 the check is
> >> removed. OpenBSD 3.2 ships with OpenSSL 0.9.7-beta3 30 Jul 2000
> >> (0x00907003L) and fails with this error:
> >>
> >> /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -I.
> >> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins
> >> -I..
> >> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/include
> >> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/lib
> >> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/sasldb
> >>   -I/usr/local/include -I/usr/include/kerberosIV
> >> -I/usr/include/kerberosV -I/usr/include  -Wall -W -Wall -O2
> >> -I/usr/include/kerberosV -c
> >> /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c
> >> rm -f .libs/otp.lo
> >> cc -DHAVE_CONFIG_H -I.
> >> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins
> >> -I..
> >> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/include
> >> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/lib
> >> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/sasldb
> >> -I/usr/local/include -I/usr/include/kerberosIV -I/usr/include/kerberosV
> >> -I/usr/include -Wall -W -Wall -O2 -I/usr/include/kerberosV -c
> >> /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c
> >>   -fPIC -DPIC -o .libs/otp.lo
> >> /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c:59:
> >> invalid preprocessing directive name
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> What kind of an error is that? Is the macro 'MD5_H' used elswhere in
> OpenBSD? Unfortunately, I don't have a OBSD 3.2 around to test on...
> 
> >> /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c:61:
> >> invalid preprocessing directive name
> >> *** Error code 1
> >>
> >> Stop in
> >> /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/build-i386/plugins.
> >>
> >> Adding the version check back fixes this problem.
> >> --- plugins/otp.c.orig  Tue Dec 10 01:33:54 2002
> >> +++ plugins/otp.c       Tue Dec 10 01:39:44 2002
> >> @@ -56,7 +56,9 @@
> >>   #include <openssl/evp.h>
> >>
> >>   #include <sasl.h>
> >> +#if OPENSSL_VERSION_NUMBER < 0x00907000L
> >>   #define MD5_H  /* suppress internal MD5 */
> >> +#endif
> >>   #include <saslplug.h>
> >>
> >>   #include "plugin_common.h"
> >>
> >
> >
> > Peter 'Luna' Runestig wrote:
> >>
> >> Hi all!
> >>
> >> What's the deal with this part in plugins/otp.c (2.1.8):
> >>
> >> #if OPENSSL_VERSION_NUMBER < 0x00907000L
> >> #define MD5_H  /* suppress internal MD5 */
> >> #endif
> >>
> >> As it stands, the code doesn't compile with openssl-0.9.7-beta3 (if I
> >> remove the version check, it does). Do you expect MD5 support to be
> >> dropped in future versions of openssl, or what?
> 
> Cheers,
> - Peter
> --
> Peter 'Luna' Runestig (fd. Altberg), Sweden <[email-masked]>
> PGP Key ID: 0xD07BBE13
> Fingerprint: 7B5C 1F48 2997 C061 DE4B  42EA CB99 A35C D07B BE13
> AOL Instant Messenger Screen name: PRunestig

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

Date: Mon, 09 Dec 2002 22:48:59 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Hack Kampbjorn <[email-masked]>, "Peter 'Luna' Runestig" <[email-masked]>
CC: [email-masked], SASL mailing list <[email-masked]>
Subject: Re: OPENSSL_VERSION_NUMBER (Was: Cyrus SASL 2.1.10 Released)
Sender: [email-masked]

OK.  I now have two conflicting reports regarding testing for
OPENSSL_VERSION_NUMBER with OpenSSL 0.9.7 (both quoted below).  Could
somebody who has 0.9.7 installed please try to figure out what the deal
is?  I tend to believe that I was originally correct in including the
check, and I'm confused as to why it doesn't work for Peter using the
same release as Hack.

Ken

Hack Kampbjorn wrote:
> 
> More problems: with cyrus-sasl version 2.1.9 plugins/otp.c only defined
> MD5_H for OpenSSL versions < 0.9.7 but in version 2.1.10 the check is
> removed. OpenBSD 3.2 ships with OpenSSL 0.9.7-beta3 30 Jul 2000
> (0x00907003L) and fails with this error:
> 
> /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -I.
> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins
> -I..
> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/include
> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/lib
> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/sasldb
>   -I/usr/local/include -I/usr/include/kerberosIV
> -I/usr/include/kerberosV -I/usr/include  -Wall -W -Wall -O2
> -I/usr/include/kerberosV -c
> /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c
> rm -f .libs/otp.lo
> cc -DHAVE_CONFIG_H -I.
> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins
> -I..
> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/include
> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/lib
> -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/sasldb
> -I/usr/local/include -I/usr/include/kerberosIV -I/usr/include/kerberosV
> -I/usr/include -Wall -W -Wall -O2 -I/usr/include/kerberosV -c
> /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c
>   -fPIC -DPIC -o .libs/otp.lo
> /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c:59:
> invalid preprocessing directive name
> /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c:61:
> invalid preprocessing directive name
> *** Error code 1
> 
> Stop in
> /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/build-i386/plugins.
> 
> Adding the version check back fixes this problem.
> --- plugins/otp.c.orig  Tue Dec 10 01:33:54 2002
> +++ plugins/otp.c       Tue Dec 10 01:39:44 2002
> @@ -56,7 +56,9 @@
>   #include <openssl/evp.h>
> 
>   #include <sasl.h>
> +#if OPENSSL_VERSION_NUMBER < 0x00907000L
>   #define MD5_H  /* suppress internal MD5 */
> +#endif
>   #include <saslplug.h>
> 
>   #include "plugin_common.h"
> 

Peter 'Luna' Runestig wrote:
> 
> Hi all!
> 
> What's the deal with this part in plugins/otp.c (2.1.8):
> 
> #if OPENSSL_VERSION_NUMBER < 0x00907000L
> #define MD5_H  /* suppress internal MD5 */
> #endif
> 
> As it stands, the code doesn't compile with openssl-0.9.7-beta3 (if I
> remove the version check, it does). Do you expect MD5 support to be
> dropped in future versions of openssl, or what?

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

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: GSS-SPNEGO
From: Sam Hartman <[email-masked]>
Date: Sat, 07 Dec 2002 23:50:06 -0500
Sender: [email-masked]

Are there any situations where you actually need to use SPNEGO with
GSS in order to interoperate with Microsoft clients or servers?