Subject: TLS Requirement in SMTP RFC4954 and SASL

From: Paul Romero <[email-masked]>
Date: Thu, 26 Feb 2009 08:13:48 -0800

Hi Simon:

I would like your interpretation of the section of  RFC 4954
which applies to  using  PLAIN authentication over TLS.
Section 4 contains the following statement on this subject:

"To ensure interoperability, client and server implementations of
this extension MUST implement the [PLAIN] SASL mechanism
running over [TLS] [SMTP-TLS]."

Does this mean that supporting both TLS and PLAIN is
an absolute requirement for a client, or that a client can
only use PLAIN authentication if it supports and agrees
to using TLS ?

I suppose a lot of people have asked this question. It is of
concern to me because small SMTP clients in embedded
environments often do not have sufficient resources to support TLS.
A strict interpretation of the section 4 language means support
for TLS is mandatory for all clients.

Best Regards,

Paul R.

Simon Josefsson wrote:

> Paul Romero <[email-masked]> writes:
>
> > Hi Simon:
> >
> > What you wrote is consistent with what I have read
> > in the SASL group E-Mail and postings. I am not
> > sure my question about SASL RFCs was 100% clear.
> > The important part of the question is, what percentage
> > of SASL implementations follow the latest version of
> > the SASL RFC ?   Is that what you understood from
> > my previous E-Mail ?
>
> Hi again.  Ah, I didn't catch that: however the latest RFCs are
> backwards compatible, and I am not aware of any change introduced that
> would generate problems.  So I believe these new RFCs are just to update
> the specification documentation itself, not to change anything in
> implementation.
>
> Regards,
> Simon
>
> > Best Regards,
> >
> > Paul  R.
> >
> > Simon Josefsson wrote:
> >
> >> Paul Romero <[email-masked]> writes:
> >>
> >> > Hi Simon:
> >> >
> >> > I  would like your observations about the use of  DIGEST-MD5
> >> > in the commercial world within the SASL context.  Do you
> >> > think it is frequently used and gaining greater acceptance ?
> >> > Also, what percentage of commercial implementations do
> >> > you think conform the RFC 4616 and 4954 SASL ?
> >>
> >> Hi Paul.  PLAIN (RFC 4616) and smtp-auth (RFC 4954) are widely
> >> implemented and deployed, and I believe all major implementations are
> >> conforming to the standard.
> >>
> >> For DIGEST-MD5, the situation is a bit different though.  DIGEST-MD5 is
> >> not as widely implemented as for example CRAM-MD5 (see RFC 2195) and
> >> interop testing of various DIGEST-MD5 implementations have demonstrated
> >> many problems.  Briefly, the security layer features of DIGEST-MD5 do
> >> not interoperate well among existing implementations.  Thus, you would
> >> typically only use it for the authentication step.  DIGEST-MD5 is
> >> relatively common, though, but I believe practically all implementations
> >> that support DIGEST-MD5 also supports CRAM-MD5 unless there a local
> >> administrator has made a policy decision to disable CRAM-MD5.
> >>
> >> Within the SASL WG in the IETF, we are trying to develop a replacement
> >> for DIGEST-MD5 called SCRAM.  The protocol is not stable yet, and there
> >> are no implementations of it, however I do think it is the future.
> >>
> >> I would recommend you to support PLAIN and CRAM-MD5 and don't spend too
> >> much time on DIGEST-MD5 if you can avoid it.
> >>
> >> Hope this helps,
> >> /Simon
> >
> > --
> > Paul Romero
> >
> > RCOM Communications Software
> >
> > Phone/Fax: (510)339-2628
> > E-Mail: [email-masked]

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 26 Feb 2009 23:29:07 -0500

> only use PLAIN authentication if it supports and agrees

It means what it says.  If a client implements RFC4954, it must be able to 
do PLAIN over TLS; otherwise, it is nonconformant.  This requirement is 
necessary to insure interoperability, because some servers will not support 
anything other than PLAIN over TLS.

> I suppose a lot of people have asked this question.

Not on the ietf-sasl list, they haven't.  Of course, the question is really 
only indirectly related to SASL, so it's possible people have asked on 
other lists.

> It is of

That is the correct interpretation; TLS is mandatory for all 
implementattions of RFC4954.  See section 7 of RFC3365 for a partial 
explanation of why.

It should be noted that nothing said by Simon, myself, or anyone else on 
this list should be interpreted as an official position of the IETF.  The 
positions of the IETF and its working groups are determined by rough 
consensus as determined by the appropriate leadership.  RFC4954 and RFC3365 
are examples of products of IETF consensus.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Carnegie Mellon University - Pittsburgh, PA

---

From: Paul Romero <[email-masked]>
Date: Thu, 26 Feb 2009 21:28:30 -0800

Hi Jeffry:

I will look at RFC 3365 as you suggested.  However,
I have observed that a lot of servers still use CRAM-MD5 which
seems OK when the E-Mail program is not used within a browser.
Disturbingly, especially in the case of an MS Outlook server,
sometimes PLAIN and LOGIN authentication without TLS are
the only choices offered.  (i.e. Bit off topic.)  It isn't obvious
to me why PLAIN over TLS would be more prevalent than
CRAM-MD5.

Best Regards,

Paul R.

--
Paul Romero

Phone/Fax: (510)339-2628

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 27 Feb 2009 09:57:45 +0000

>to me why PLAIN over TLS would be more prevalent than
Hi Paul,
A mandatory-to-implement authentication mechanism doesn't necessarily 
mean that it is prevalent, but it means that the specified 
authentication mechanism is considered to be more secure/better/etc. by 
the IETF community.

Alexey

P.S. I can rant about MS Outlook compliance with various email related 
standards, but I should probably do this off-list.

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 27 Feb 2009 05:00:27 -0800

> seems OK when the E-Mail program is not used within a browser.

If you don't mind your SMTP/IMAP/POP/... sessions being eavesdropped  
upon or highjacked.

-- Kurt

---

From: Paul Romero <[email-masked]>
Date: Fri, 27 Feb 2009 07:44:46 -0800

Hi Kurt:

CRAM-MD5  is designed to prevent disclosure of authentication
data, and not privacy, delivery authentication, or identify
confirmation.
Most of those other issues can be handled by robust end to end
encryption of  E-Mail content. In most cases identity falsification
occurs due to the E-Mail originator being sloppy about protecting
his or her authentication data rather than a CRAM-MD5 failure.

Best Regards,

Paul R.

--
Paul Romero

Phone/Fax: (510)339-2628

---

From: Tony Finch <[email-masked]>
Date: Fri, 27 Feb 2009 16:16:49 +0000

On Thu, 26 Feb 2009, Paul Romero wrote:
>
> It isn't obvious to me why PLAIN over TLS would be more prevalent than
> CRAM-MD5.

CRAM-MD5 requires plaintext passwords on the server but PLAIN does not.
(i.e. PLAIN is compatible with Unix password files.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Paul Romero <[email-masked]>
Date: Fri, 27 Feb 2009 08:27:32 -0800

Hi Tony:

CRAM-MD5 only specifies that  passwords/secrets are to be used
as plaintext and not how they are stored.

Best Regards,

Paul R.

--
Paul Romero

Phone/Fax: (510)339-2628