Subject: RE: SASL GSSAPI draft

From: Chris Newman <[email-masked]>
Date: Mon, 05 Jun 2000 21:51:30 -0700

--On Tuesday, May 30, 2000 9:52 -0400 "Linn, John" <[email-masked]> 
wrote:
> It's certainly true that an SPNEGO token won't be usefully processable by
> a target which doesn't support SPNEGO. If, however, a GSS implementation
> can support GSS_MECH_A and GSS_MECH_B negotiated under SPNEGO, and that
> GSS implementation is being used with SASL, it may not be too much
> incremental effort to make GSS_MECH_A and GSS_MECH_B also available for
> negotiation at the SASL level.  There's a security vs. interoperability
> tradeoff, since the SPNEGO negotiation is protected but the SASL
> negotiation isn't.  I'd suggest recommending, not discouraging, support
> for SPNEGO for use where available and appropriate, but also recommending
> configurable support to allow negotiation of individual GSS mechanisms at
> the SASL level.

Some problems with recommending SPNEGO in SASL:

There are standards-compliant email servers deployed which only support 
Kerberos 5 (GSSAPI SASL) and don't support SPNEGO.  Any email server which 
only advertises GSS-SPNEGO (not yet standardized) and not GSSAPI (standards 
track) for Kerberos 5 support is hostile both to the installed base of 
standards-compliant servers and to the deployment of Kerberos 5.  If admins 
encounter an interop problem when trying to upgrade security, the first 
thing they usually do is back out the security upgrade.  We don't want that 
to happen.

I suspect the protection provided by SPNEGO will be irrelevant to most 
SASL-based protocols in practice because they'll get integrity protection 
from either TLS or IPsec prior to the SASL negotiation if they want it at 
all.  So it just doesn't seem to be worth the extra round trip(s), IMHO.

> If an application client (and its associated SASL and/or SPNEGO client)
> supports policy-driven mechanism negotiation, the preferred set might (1)
> span both GSS and non-GSS SASL mechanisms or (2) might be GSS mechanisms
> only, with non-GSS SASL mechanisms to be invoked only as a fallback if
> none of the GSS mechanisms are available.  If (1), the client is most
> easily served by performing the negotiation (and exposing the individual
> GSS mechanisms) at the SASL level.  Given the prospect of (2), however,
> it'd be good to be able to negotiate among the available GSS mechanisms
> in an SPNEGO-protected manner.

I'm very uncomfortable with options in security protocols.  Every option 
can double the complexity of a security analysis of the software.  I 
suspect that any benefit gained by making SPNEGO an option will be 
outweighed by the cost of a security analysis of both codepaths and the 
interaction between various security polices and SPNEGO/SASL mechanism 
lists.

		- Chris

---

From: [email-masked] (John Myers)
Date: Tue, 06 Jun 2000 16:21:15 -0700

"Linn, John" wrote:
> There's a security vs. interoperability tradeoff, since the
> SPNEGO negotiation is protected but the SASL negotiation isn't.

The design criterion I've used in preparing the draft is that one should
not trade away interoperability unless there exists a requirement in a
site's security policy which is incompatible with that interoperability.

> I'd suggest
> recommending, not discouraging, support for SPNEGO for use where available
> and appropriate, but also recommending configurable support to allow
> negotiation of individual GSS mechanisms at the SASL level.

The applicable requirement in the current draft is:

   In any case, there is no down-negotiation security
   consideration with using the strongest mechanism and set of options
   the implementation supports, so for interoperability that mechanism
   and set of options MUST be negotiable without using the "GSS-SPNEGO"
   mechanism.

> only, with non-GSS SASL mechanisms to be invoked only as a fallback if none
> of the GSS mechanisms are available.  If (1), the client is most easily
> served by performing the negotiation (and exposing the individual GSS
> mechanisms) at the SASL level.  Given the prospect of (2), however, it'd be
> good to be able to negotiate among the available GSS mechanisms in an
> SPNEGO-protected manner.

If your security policy allows the negotiation of a weak mechanism
outside of SPNEGO, then what benefit are you gaining from SPNEGO?  An
active attacker can make it appear that SPNEGO is not suppported by the
other side, removing all benefit of SPNEGO over SASL mechainsm
negotiation.

This is why I discourage rather than encourage SPNEGO underneath SASL. 
Unless you have a security policy of allowing certain mechanisms only
when their negotiation has been protected, the SPNEGO negotiation
protection doesn't buy you anything.  This particular security policy is
explicitly mentioned in the draft as a reason to violate the SHOULD NOT
directive against SPNEGO under SASL.

---

From: David Margrave <[email-masked]>
Date: Thu, 08 Jun 2000 12:40:04 -0700

> directive against SPNEGO under SASL.

As long as major applications, like say LDAP or IMAP for example, are in love
with SASL (Honestly, do you blame them?  Good grief, look at the prototype for
gss_init_sec_context() some time!), don't you think it's worthwhile to at least
go to the effort to add a modicum of real security to it?  I mean, the only
SASL mech worth a darn security-wise at the moment is GSS-API.   I struggled
with this for a while, then realized that if both sides really want a secure
connection, then can simply decide they're only going to support one
SASL mech (GSS KRB5), and that SASL+GSS is simply GSS (real security) with a few
extra bytes of cruft (SASL) in front of the GSS token.   Everybody is happy,
everybody wins.

So I would think that an SPNEGO SASL mech would be a good thing, because
well-designed implementations of application protocols could be configured to
only support one SASL mech (SPNEGO), so that we get real negotiation of a
security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around
it.

Its the cases where you'd say "I'll support SPNEGO and cleartext passwords as my
SASL mechs", and the man-in-the-middle says "Okay, lets do cleartext passwords"
that you would want to avoid by policy configuration.  I believe that the best
we can hope for is that SASL and SPNEGO(GSS) toolkits will play nice together so
that SASL (which isn't going away) will support SPNEGO as an available option in
the vast majority of implementations.

Dave

---

From: [email-masked] (John Myers)
Date: Sun, 11 Jun 2000 13:06:39 -0700

David Margrave wrote:
> with SASL [...] don't you think it's worthwhile to at least
> SASL mech worth a darn security-wise at the moment is GSS-API.

Personally, I think DIGEST-MD5 [RFC 2831] has an acceptable level of security.

One cannot simply "add security" by throwing in cryptographic protocols
wherever they are convenient.  One has to form a threat model, devise
security policies to address the modeled threats, and evaluate an
implementation of those policies as a whole against said threats.  To
claim that SPNEGO adds "a modicum of real security" to SASL, one must
show how the combination implements security policies to thwart which
classes of threats.

> I struggled

If both sides are configured to only support GSS KRB5, then what threat
does the addition of SPNEGO protect against?

> security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around

Please address how a client supporting only Kerberos V5 underneath
SPNEGO underneath SASL would interoperate with a server supporting only
Kerberos V5 underneath SASL.

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 12 Jun 2000 00:07:42 -0400

>Kerberos V5 underneath SASL.

You keep bringing up these mythical "only Kerberos V5 underneath
SPNEGO" implementations.  Even if you're doing SPNEGO, you still
have to parse V5 GSSAPI tokens; I can't really imagine a reason
why you would not be able to handle a V5 GSSAPI token exchange
without SPNEGO.  I don't think this is a legitimate reason for
recommending against the use of SPNEGO.

I am still undecided on this issue; maybe it is right to not recommend
the use of SPNEGO with SASL, but I don't think this is a valid reason.

--Ken

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 12 Jun 2000 13:23:04 -0400 (EDT)

Date: Mon, 12 Jun 2000 00:07:42 -0400
   From: Ken Hornstein <[email-masked]>
[...]
   You keep bringing up these mythical "only Kerberos V5 underneath
   SPNEGO" implementations.  Even if you're doing SPNEGO, you still
   have to parse V5 GSSAPI tokens; I can't really imagine a reason
   why you would not be able to handle a V5 GSSAPI token exchange
   without SPNEGO.  I don't think this is a legitimate reason for
   recommending against the use of SPNEGO.

If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition
to SPNEGO, no additional security is obtained via SPNEGO (the active
attacks that SPNEGO prevents are just circumvented by removing SPNEGO
from the capabilities line).

Thus, it only makes sense to support SPNEGO/Krb5 if it is going to be
used without advertising/allowing Krb5 without SPNEGO---which leads to
the interoperability problems.

Larry

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 12 Jun 2000 17:37:16 -0400

>from the capabilities line).

That's true, with the current draft.  But if GSSAPI simply means, "any
GSSAPI mechanism", then there's no reason a non-SPNEGO client can't
interoperate with a SPNEGO-aware server, without any loss of security
that I can tell (since there wouldn't be any negotiation in the
non-SPNEGO case).

I was under the impression that "the interoperability problem" was given
as a reason not to use SPNEGO; that's the only reason why I'm saying
I don't think it's a valid reason.

--Ken

---

From: [email-masked] (John Myers)
Date: Fri, 16 Jun 2000 14:58:25 -0700

My apologies, I accidentally left the ietf-cat-wg list off the recipient
list when I first sent this message:

Ken Hornstein wrote:
> SPNEGO" implementations.

Reportedly, the Microsoft Windows 2000 SSPI implementation only
advertises the availability of the SPNEGO GSSAPI mechanism.  A
straightforward implementation of SASL on Windows 2000 would be unlikely
to advertise or recognize GSSAPI SASL mechanisms other than the
"GSS-SPNEGO" mechanism that was registered by Microsoft.

> Even if you're doing SPNEGO, you still
> without SPNEGO.

Consider a SPNEGO client and a non-SPNEGO server.  The server will be
unable to parse the SPNEGO GSSAPI token that the client sends.

> that I can tell (since there wouldn't be any negotiation in the

If the "GSSAPI" SASL mechanism means "any GSSAPI mechanism," then a
client which supports more than one GSSAPI mechanism doesn't know which
one to send to the server.  If a client supports both Kerberos V5 and
SPKM-1 and sees the server advertising "GSSAPI", which one should it
send?  Surely you don't intend for an IMAP client to take two round
trips per GSSAPI mechanism in order to find out the server only supports
the last mechanism the client tried?

What do you mean there wouldn't be any negotiation in the non-SPNEGO
case?  There's always negotiation in SASL.  A man in the middle can
always make it look like either side doesn't support SPNEGO, so my "no
additional security is obtained" statement still applies.

> I don't think it's a valid reason.

I'm sorry, I don't understand.  What is the reason you're saying you
don't think "the interoperability problem" is a valid reason?

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 16 Jun 2000 23:14:38 -0400

>"GSS-SPNEGO" mechanism that was registered by Microsoft.

Hm, back up here.

Are we talking about advertisement at the SASL or GSSAPI level?  I think
I'm a bit confused, because I thought SSPI was roughly equivalant to GSSAPI.

I will say that when I telnetted to the SMTP server on a coworkers
Windows 2000 box, one of the SASL mechanisms it advertised was "GSSAPI",
and I didn't see GSS-SPNEGO anywhere.  Maybe that will change in the
future.

Everything I have seen from Microsoft has led me to believe that
this server would accept a valid Kerberos 5 GSSAPI token (but I
haven't actually tested it yet), _and_ it would accept a SPNEGO
token.  I actually thought that this interoperability has been
tested by Microsoft, but I'd appreciate a correction.

>unable to parse the SPNEGO GSSAPI token that the client sends.

I agree, this is a problem; I don't think I ever disagreed with that.

>one to send to the server.

No disagreement here.  But ... it was my thinking that if you supported
more than one mechanism, you'd really have to do SPNEGO (or your proposed
draft).

>additional security is obtained" statement still applies.

My apologies; I should have been clearer.  I meant, "there wouldn't
be any _SPNEGO_ negotiation in the non-SPNEGO case" (e.g., a Kerberos 5
only GSSAPI implementation would only send a Kerberos 5 GSSAPI mechanism).
But you're right; you still don't gain any security, because you can
then simply remove GSSAPI from the supported mechanism line.  My apologies.

>don't think "the interoperability problem" is a valid reason?

It's been said a number of times that Kerberos 5-only GSSAPI
implementations won't interoperate with GSSAPI implementations that
support Kerberos 5 only under SPNEGO, and this is one of the reasons
a seperate GSS-SPNEGO SASL mechanism is needed.

It is my belief that there are no GSSAPI implementations that
support SPNEGO which do not support GSS Kerberos 5, and furthermore
there is no reason why you would ever _create_ such a GSSAPI
implementation (number one: you'd lose interoperability with Kerberos
5 GSSAPI implementations on non-SASL protocols such as FTP).  So
I don't think that any such interoperability problem exists.

(from another note)

>If a server supports Kerberos underneath SPNEGO but rejects Kerberos
>GSSAPI tokens not underneath SPNEGO, which requirement of RFC 2478 is
>that server violating?

None, as far as I can tell (that exists outside of the SPNEGO spec,
as far as I can tell).  But is there a reason why you would do such
a thing?

Please understand that I'm not raising an objection to your draft; I'm
just trying to understand the reasoning better.

--Ken

---

From: Chris Newman <[email-masked]>
Date: Mon, 05 Jun 2000 21:51:30 -0700

- Chris

---

From: [email-masked] (John Myers)
Date: Tue, 06 Jun 2000 16:21:15 -0700

---

From: David Margrave <[email-masked]>
Date: Thu, 08 Jun 2000 12:40:04 -0700

Dave

---

From: [email-masked] (John Myers)
Date: Sun, 11 Jun 2000 13:06:39 -0700

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 12 Jun 2000 00:07:42 -0400

--Ken

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 12 Jun 2000 13:23:04 -0400 (EDT)

Larry

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 12 Jun 2000 17:37:16 -0400

--Ken

---

From: [email-masked] (John Myers)
Date: Fri, 16 Jun 2000 14:58:25 -0700

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 16 Jun 2000 23:14:38 -0400

Hm, back up here.

(from another note)

--Ken

To: [email-masked], [email-masked]
Subject: Re: SASL GSSAPI draft 
Date: Fri, 16 Jun 2000 23:14:38 -0400
From: Ken Hornstein <[email-masked]>
Sender: [email-masked]

Hm, back up here.

(from another note)

--Ken

Date: Fri, 16 Jun 2000 16:34:28 -0700
From: [email-masked] (John Myers)
To: [email-masked], [email-masked]
Subject: Re: SASL GSSAPI draft
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msD28D6A4382055AF44DF9B865
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Linn, John" wrote:
> Properly, I think, the interoperability concern applies to the case where
> GSS mechanisms are exposed for negotiation only via SPNEGO, and not also at
> the SASL level.

Agreed.  There is also a problem case where the policy prefers a
non-GSSAPI mechanism over a particular GSSAPI mechanism.  One possible
reasonable policy would be to first prefer Kerberos, then DIGEST-MD5,
then GSS-API-Easy.  If a server only supports DIGEST-MD5 and
GSS-API-Easy, a client might through SPNEGO inadvertently use
GSS-API-Easy instead of DIGEST-MD5.

> If GSS mechanisms are exposed for negotiation at both the
> SPNEGO and SASL levels, this would provide the broadest degree of
> interoperability, supporting even those clients whose policies reject
> negotiation of any non-GSS SASL mechanisms and which demand to use SPNEGO as
> a protected means to select among the available GSS mechanisms.

One issue is whether or not it is a reasonable policy for the server to
only accept certain weaker GSS mechanisms when their use has been
negotiated through SPNEGO.  If it is a reasonable policy, then the
draft's current MUST wording about advertising the strongest GSS
mechanism at the SASL layer is sufficient.  If it is not a reasonable
policy, then the requirement needs to be strengthened to say that all of
the GSS mechanisms supported inside SPNEGO MUST also be advertised at
the SASL layer.

For SPNEGO to be useful, a client must not only have the policies you
state, but must additionally support and have access to credentials for
at least two GSS mechanisms.  Steve Hole, who has implemented both
Kerberos and SPKM, reports that in his experience any given client or
server only has access to infrastructure for one GSS mechanism.

I won't claim that it will never happen, but the set of policies and
circumstances for which SPNEGO under SASL is necessary is rarely
practical.

> One argument against SPNEGO under SASL (additionally to SASL-level
> exposure of the same GSS mechanism set) is that it adds complexity which
> would be superfluous in some situations; the (apparently modest) incremental
> complexity might be justified by the fact that it enables a protected
> negotiation which would be usefully and additionally secure in other
> situations.

The incremental complexity of implementing SPNEGO is not necessarily
modest.  The SASL implementation I am currently working on and the CMU
Cyrus SASL library both allow for SASL mechanism plug-ins.  It would be
relatively straightforward to create a SASL mechanism plug-in
implementing Kerberos--that plug-in could then be loaded into any
product implemented using the library.  To support Kerberos underneath
SPNEGO, either the SASL library would have to implement both GSSAPI and
SPNEGO or one would have to create a GSSAPI/SPNEGO SASL plug-in and then
have Kerberos plug-in to the GSSAPI plug-in.

> Generally, wrt SPNEGO support under SASL, we've seen arguments for both
> positions.  Rather than the present SHOULD NOT (albeit with listed
> exception), would this be a good candidate for compromise on a MAY?

I am extremely worried about offering two different ways to do the same
thing.  When a protocol offers multiple ways to do something, it is not
uncommon for an implementation to only test one of them.  Even if only
one way is a MUST IMPLEMENT, that is not necessarily the way that gets
tested.  If an implementation botches the MUST way and gains wide
deployment due to some some other way working, the protocol effectively
ends up with two or more MUST IMPLEMENTS.

(This is a form of the "be liberal considered harmful" argument.)

This is why I wrote this as a SHOULD NOT requirement with a listed
exception.  I am trying to get implementors to think about their
customer's security requirements and only take on the complexity and
risk of noninteroperation if the security policy and set of
circumstances require.  If we change the SHOULD NOT to a MAY, how else
can we minimize the risk of clients and servers which only work with
SPNEGO due to implementation laziness or error?
--------------msD28D6A4382055AF44DF9B865
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msD28D6A4382055AF44DF9B865--

Date: Fri, 16 Jun 2000 14:58:25 -0700
From: [email-masked] (John Myers)
To: [email-masked], [email-masked]
Subject: Re: SASL GSSAPI draft
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msEB93552D1CF51C9180CCE623
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm sorry, I don't understand.  What is the reason you're saying you
don't think "the interoperability problem" is a valid reason?
--------------msEB93552D1CF51C9180CCE623
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msEB93552D1CF51C9180CCE623--

Date: Wed, 14 Jun 2000 23:32:46 -0700
From: [email-masked] (John Myers)
CC: [email-masked], [email-masked]
Subject: Re: SASL GSSAPI draft
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms49DFB204291C59317B913E32
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ken Hornstein wrote:
> As I read RFC 2478,
> you always deal with the OID of the underlying mechanism, so I
> don't think it's possible to support, for example, Kerberos "under"
> SPNEGO without just supporting Kerberos

If a server supports Kerberos underneath SPNEGO but rejects Kerberos
GSSAPI tokens not underneath SPNEGO, which requirement of RFC 2478 is
that server violating?
--------------ms49DFB204291C59317B913E32
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms49DFB204291C59317B913E32--

From: "Linn, John" <[email-masked]>
To: "'Ken Hornstein'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: SASL GSSAPI draft 
Date: Tue, 13 Jun 2000 09:59:06 -0400
Sender: [email-masked]

Properly, I think, the interoperability concern applies to the case where
GSS mechanisms are exposed for negotiation only via SPNEGO, and not also at
the SASL level.  If GSS mechanisms are exposed for negotiation at both the
SPNEGO and SASL levels, this would provide the broadest degree of
interoperability, supporting even those clients whose policies reject
negotiation of any non-GSS SASL mechanisms and which demand to use SPNEGO as
a protected means to select among the available GSS mechanisms.  If it's
plausible for a client to have such a policy, even though it's interacting
with a server which may also have clients having other policies,
interoperability would be best served by allowing negotiation at both
levels.  One argument against SPNEGO under SASL (additionally to SASL-level
exposure of the same GSS mechanism set) is that it adds complexity which
would be superfluous in some situations; the (apparently modest) incremental
complexity might be justified by the fact that it enables a protected
negotiation which would be usefully and additionally secure in other
situations. 

Generally, wrt SPNEGO support under SASL, we've seen arguments for both
positions.  Rather than the present SHOULD NOT (albeit with listed
exception), would this be a good candidate for compromise on a MAY?   

--jl

> -----Original Message-----
> From: Ken Hornstein [mailto:[email-masked]]
> Sent: Monday, June 12, 2000 5:37 PM
> To: [email-masked]; [email-masked]
> Subject: Re: SASL GSSAPI draft 
> 
> 
> -++**==--++**==--++**==--++**==--++**==--++**==--++**==
> 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]
> 

To: [email-masked], [email-masked]
Subject: Re: SASL GSSAPI draft 
Date: Mon, 12 Jun 2000 17:37:16 -0400
From: Ken Hornstein <[email-masked]>
Sender: [email-masked]

--Ken

Date: Mon, 12 Jun 2000 13:23:04 -0400 (EDT)
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], [email-masked]
Cc: Ken Hornstein <[email-masked]>
Subject: Re: SASL GSSAPI draft 
Sender: [email-masked]

Larry

To: [email-masked], [email-masked]
Subject: Re: SASL GSSAPI draft 
Date: Mon, 12 Jun 2000 00:07:42 -0400
From: Ken Hornstein <[email-masked]>
Sender: [email-masked]

--Ken

Date: Sun, 11 Jun 2000 13:06:39 -0700
From: [email-masked] (John Myers)
To: [email-masked]
CC: [email-masked]
Subject: Re: SASL GSSAPI draft
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms21CF901E3143C20952D5E60F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Please address how a client supporting only Kerberos V5 underneath
SPNEGO underneath SASL would interoperate with a server supporting only
Kerberos V5 underneath SASL.
--------------ms21CF901E3143C20952D5E60F
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms21CF901E3143C20952D5E60F--

content-class: urn:content-classes:message
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Date: Sat, 10 Jun 2000 15:31:48 -0700
From: "Paul Leach" <[email-masked]>
To: "Magnus Nystrom" <[email-masked]>
Cc: "John Myers" <[email-masked]>, "Robert Zuccherato" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFD32B.AA1D8DC2
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> -----Original Message-----
> From: Magnus Nystrom [mailto:[email-masked]]
> Sent: Saturday, June 10, 2000 1:51 AM
> To: Paul Leach
> Cc: John Myers; Robert Zuccherato; [email-masked]
> Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
>=20
>=20
> Paul,
>=20
> On Fri, 9 Jun 2000, Paul Leach wrote:
> >=20
> > > -----Original Message-----
> > > From: Magnus Nystrom [mailto:[email-masked]]
> > > Sent: Friday, June 09, 2000 3:04 AM
> > >=20
> > > The TLS endpoint isn't always the same as the application=20
> endpoint and
> > > that is the very reason for this proposal. Maybe this should=20
> > > be made more explicit in the draft.
> >=20
> > Why not? What stops any app that would use the proposed new
> > authentication protocol from making the two end points the same and
> > using TLS instead?
> >=20
> > In fact, nothing does.
>=20
> How about:
> A client uncapable of verifying certificates? A situation=20
> where unilateral
> authentication is enough?  A client uncapable of performing a full TLS
> handshake?

If your complaint is that TLS doesn't readily admit to reducing the
level of security, I would argue that TLS is easy enough to implement in
it entirety that that is an irrelevane argument, and that _less_
security isn't what the world needs right now.

Besides, as John pointed out, it is possible to handle those cases. And,
given the existence of open source TLS implementations, why would anyone
bother to implement a totally new package that has less security?

Paul

------_=_NextPart_001_01BFD32B.AA1D8DC2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4390.0">
<TITLE>RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: Magnus Nystrom [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]=
</FONT>

<BR><FONT SIZE=3D2>&gt; Sent: Saturday, June 10, 2000 1:51 AM</FONT>

<BR><FONT SIZE=3D2>&gt; To: Paul Leach</FONT>

<BR><FONT SIZE=3D2>&gt; Cc: John Myers; Robert Zuccherato; =
[email-masked]</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: RE: I-D Action: =
draft-zuccherato-9798-3-sasl-00.txt</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Paul,</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; On Fri, 9 Jun 2000, Paul Leach wrote:</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Magnus Nystrom [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]=
</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Friday, June 09, 2000 3:04 =
AM</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; &gt; The TLS endpoint isn't always the same =
as the application </FONT>

<BR><FONT SIZE=3D2>&gt; endpoint and</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; &gt; that is the very reason for this =
proposal. Maybe this should </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; &gt; be made more explicit in the =
draft.</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; Why not? What stops any app that would use =
the proposed new</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; authentication protocol from making the two =
end points the same and</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; using TLS instead?</FONT>

<BR><FONT SIZE=3D2>&gt; &gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt; In fact, nothing does.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; How about:</FONT>

<BR><FONT SIZE=3D2>&gt; A client uncapable of verifying certificates? A =
situation </FONT>

<BR><FONT SIZE=3D2>&gt; where unilateral</FONT>

<BR><FONT SIZE=3D2>&gt; authentication is enough?&nbsp; A client =
uncapable of performing a full TLS</FONT>

<BR><FONT SIZE=3D2>&gt; handshake?</FONT>
</P>

<P><FONT SIZE=3D2>If your complaint is that TLS doesn't readily admit to =
reducing the level of security, I would argue that TLS is easy enough to =
implement in it entirety that that is an irrelevane argument, and that =
_less_ security isn't what the world needs right now.</FONT></P>

<P><FONT SIZE=3D2>Besides, as John pointed out, it is possible to handle =
those cases. And, given the existence of open source TLS =
implementations, why would anyone bother to implement a totally new =
package that has less security?</FONT></P>

<P><FONT SIZE=3D2>Paul</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD32B.AA1D8DC2--

Date: Sat, 10 Jun 2000 13:54:03 -0700
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms2C4BBC890518868687607636
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Magnus Nystrom wrote:
> A client uncapable of verifying certificates? A situation where unilateral
> authentication is enough?

A client can perform a TLS handshake and ignore the cert sent by the
server.  Like the proposed mechanism, such a client would be subject to
active attacks.  Unlike your proposed mechanism, such a client would be
protected from passive eavesdropping and would interoperate with the
installed base.

Our implmentation of STARTTLS in outgoing SMTP relay uses this mode. 
Subsequent releases will allow the site to configure which domains
require protection against active attack in outgoing SMTP relay.

> A client uncapable of performing a full TLS handshake?

Why would a client capable of managing a client cert and signing
authentication requests be uncapable of performing a full TLS handshake?
--------------ms2C4BBC890518868687607636
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms2C4BBC890518868687607636--

Date: Sat, 10 Jun 2000 13:38:41 -0700
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msF60FEB9B648E5FBF63A83891
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Magnus Nystrom wrote:
> The TLS endpoint isn't always the same as the application endpoint and
> that is the very reason for this proposal. Maybe this should be made more
> explicit in the draft.

What is HostA authenticating to, HostB or HostC?  Whenever I address one
case, you counter with an argument about the other.

If the TLS endpoint isn't the same as the application endpoint, you have
the TLS endpoint authenticate to the application endpoint using its own
credentials, passing the original client's identity in the authorization
ID.  This results in much better security, as only middlemen the
application endpoint is configured to trust are permitted to eavesdrop
or modify the the connection.

> > I'm sorry, I don't see the argument behind these assertions.  What
> > difference between TLS and SASL makes TLS a "link" protocol as opposed
> > to an "application" protocol?
> 
> IMHO, since it is possible to "insert" SASL in many higher-level protocols
> it is a useful mechanism when, for one reason or another, lower level
> protocols (I include TLS here) terminates at a gateway or similar, or the
> application using the SASL-enabled protocol is unable to run TLS for one
> reason or another, but is still capable of doing public-key operations.

One can also "insert" TLS in higher-level protocols.  See RFC's 2817,
2595, and 2487.  TLS is no different than SASL in this regard.

How does the theoretical existence of applications which support SASL
and public-key operations make TLS a "link" protocol but not an
"application" protocol?  There do exist applications which support TLS
and public-key operations, but are unable to run SASL for one reason or another.

> > In your HostA, HostB, HostC situation, how would you handle a SASL
> > negotiation using a mechanism that provides perfect forward secrecy of
> > the identity being authenticated?
> 
> Just so we are talking about the same thing here: Perfect forward secrecy
> = Disclosing one key/authentication does not give an attacker the
> possibility to reuse that information in subsequent exchanges.

Exactly.  Consider a SASL mechanism where the client and server first
perform a Diffie-Hellman key exchange.  The client then sends the server
his cert encrypted with the Diffie-Hellman key and an authenticator
formed by signing the Diffie-Hellman key with his private key.

Or just explain how in your HostA, HostB, HostC situation you would
handle a Kerberos authentication which negotiates a privacy security
layer.  I brought up the issue of perfect forward secrecy of the
identity being authenticated to prevent the answer where HostB and HostC
both have access to the server key.

> The proposed protocol is vulnerable to session hi-jacking, this fact is
> also mentioned in the draft, and true also for other SASL mechanisms not
> inserting a security layer.

Most of the other SASL mechanisms which don't have a security layer
don't have it because they are incapable of negotiating a session key. 
The thing I don't like about this particular proposal are the
implications that this lack of security layer somehow improves security
or makes it significantly easier to implement than TLS.
--------------msF60FEB9B648E5FBF63A83891
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msF60FEB9B648E5FBF63A83891--

Date: Sat, 10 Jun 2000 7:10:14 EDT
From: Jeffrey Altman <[email-masked]>
Reply-To: [email-masked]
To: Magnus Nystrom <[email-masked]>
Cc: Paul Leach <[email-masked]>, John Myers <[email-masked]>, Robert Zuccherato <[email-masked]>, [email-masked]
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

> Paul,
> 
> On Fri, 9 Jun 2000, Paul Leach wrote:
> > 
> > > -----Original Message-----
> > > From: Magnus Nystrom [mailto:[email-masked]]
> > > Sent: Friday, June 09, 2000 3:04 AM
> > > 
> > > The TLS endpoint isn't always the same as the application endpoint and
> > > that is the very reason for this proposal. Maybe this should 
> > > be made more explicit in the draft.
> > 
> > Why not? What stops any app that would use the proposed new
> > authentication protocol from making the two end points the same and
> > using TLS instead?
> > 
> > In fact, nothing does.
> 
> How about:
> A client uncapable of verifying certificates? A situation where unilateral
> authentication is enough?  A client uncapable of performing a full TLS
> handshake?
> 
> BR,
> -- Magnus
> 

Use a TLS cipher suite that does not use X.509 certificates for
authentication.  At the moment there is only Kerberos 5 defined as an
RFC but there is nothing to stop someone from defining a cipher suite
that uses something else.

Or you can use TLS in an anonymous mode if you have another
authentication mechanism that can prove shared knowledge of unverified
data.  If so, you take the TLS client finished message and the server
finished message and you verify them as part of the authentication
method.  That will ensure there is no MITM.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

Date: Sat, 10 Jun 2000 10:51:09 +0200 (MET DST)
From: Magnus Nystrom <[email-masked]>
Reply-To: Magnus Nystrom <[email-masked]>
To: Paul Leach <[email-masked]>
cc: John Myers <[email-masked]>, Robert Zuccherato <[email-masked]>, [email-masked]
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

Paul,

On Fri, 9 Jun 2000, Paul Leach wrote:
> 
> > -----Original Message-----
> > From: Magnus Nystrom [mailto:[email-masked]]
> > Sent: Friday, June 09, 2000 3:04 AM
> > 
> > The TLS endpoint isn't always the same as the application endpoint and
> > that is the very reason for this proposal. Maybe this should 
> > be made more explicit in the draft.
> 
> Why not? What stops any app that would use the proposed new
> authentication protocol from making the two end points the same and
> using TLS instead?
> 
> In fact, nothing does.

How about:
A client uncapable of verifying certificates? A situation where unilateral
authentication is enough?  A client uncapable of performing a full TLS
handshake?

BR,
-- Magnus

content-class: urn:content-classes:message
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Date: Fri, 9 Jun 2000 13:14:54 -0700
From: "Paul Leach" <[email-masked]>
To: "Magnus Nystrom" <[email-masked]>, "John Myers" <[email-masked]>
Cc: "Robert Zuccherato" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFD24F.602B0186
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> -----Original Message-----
> From: Magnus Nystrom [mailto:[email-masked]]
> Sent: Friday, June 09, 2000 3:04 AM
> To: John Myers
> Cc: Robert Zuccherato; [email-masked]
> Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
>=20
>=20

> The TLS endpoint isn't always the same as the application endpoint and
> that is the very reason for this proposal. Maybe this should=20
> be made more
> explicit in the draft.

Why not? What stops any app that would use the proposed new
authentication protocol from making the two end points the same and
using TLS instead?

In fact, nothing does.

Paul

------_=_NextPart_001_01BFD24F.602B0186
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4390.0">
<TITLE>RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: Magnus Nystrom [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]=
</FONT>

<BR><FONT SIZE=3D2>&gt; Sent: Friday, June 09, 2000 3:04 AM</FONT>

<BR><FONT SIZE=3D2>&gt; To: John Myers</FONT>

<BR><FONT SIZE=3D2>&gt; Cc: Robert Zuccherato; [email-masked]</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: Re: I-D Action: =
draft-zuccherato-9798-3-sasl-00.txt</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>&gt; The TLS endpoint isn't always the same as the =
application endpoint and</FONT>

<BR><FONT SIZE=3D2>&gt; that is the very reason for this proposal. Maybe =
this should </FONT>

<BR><FONT SIZE=3D2>&gt; be made more</FONT>

<BR><FONT SIZE=3D2>&gt; explicit in the draft.</FONT>
</P>

<P><FONT SIZE=3D2>Why not? What stops any app that would use the =
proposed new authentication protocol from making the two end points the =
same and using TLS instead?</FONT></P>

<P><FONT SIZE=3D2>In fact, nothing does.</FONT>
</P>

<P><FONT SIZE=3D2>Paul</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD24F.602B0186--

content-class: urn:content-classes:message
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Date: Fri, 9 Jun 2000 09:22:16 -0700
From: "Paul Leach" <[email-masked]>
To: "Magnus Nystrom" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFD22E.E0481654
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> -----Original Message-----
> From: Magnus Nystrom [mailto:[email-masked]]
> Sent: Friday, June 09, 2000 2:50 AM
> To: Paul Leach
> Cc: [email-masked]; [email-masked]
> Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
>=20
>=20
>=20
> Dear Paul,
>=20
> No, I am not mis-speaking. There are in fact architectures like this.
>=20
> -- Magnus
>=20

Well, then they are deliberately allowing untrusted parties, _including
malicious ones, against whom the proposal offers no protection_, to
access their communications. They don't need authentication at all, in
which case.

Paul

------_=_NextPart_001_01BFD22E.E0481654
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4390.0">
<TITLE>RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: Magnus Nystrom [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]=
</FONT>

<BR><FONT SIZE=3D2>&gt; Sent: Friday, June 09, 2000 2:50 AM</FONT>

<BR><FONT SIZE=3D2>&gt; To: Paul Leach</FONT>

<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]; =
[email-masked]</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: RE: I-D Action: =
draft-zuccherato-9798-3-sasl-00.txt</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Dear Paul,</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; No, I am not mis-speaking. There are in fact =
architectures like this.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; -- Magnus</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Well, then they are deliberately allowing untrusted =
parties, _including malicious ones, against whom the proposal offers no =
protection_, to access their communications. They don't need =
authentication at all, in which case.</FONT></P>

<P><FONT SIZE=3D2>Paul</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD22E.E0481654--

To: [email-masked]
Subject: RFC 2831 on Digest SASL Mechanism
Cc: [email-masked]
Date: Thu, 08 Jun 2000 11:07:36 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 2831

        Title:	    Using Digest Authentication as a SASL Mechanism 
        Author(s):  P. Leach, C. Newman
        Status:     Standards Track
	Date:       May 2000
        Mailbox:    [email-masked], [email-masked]
        Pages:      27
        Characters: 58124
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-leach-digest-sasl-05.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2831.txt

This specification defines how HTTP Digest Authentication [Digest] can
be used as a SASL [RFC 2222] mechanism for any protocol that has a
SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC
2195] and as a convenient way to support a single authentication
mechanism for web, mail, LDAP, and other protocols.

This document is a product of the LDAP Extension Working Group of the
IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

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

RETRIEVE: rfc
DOC-ID: rfc2831

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2831.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--

Date: Fri, 9 Jun 2000 8:14:05 EDT
From: Jeffrey Altman <[email-masked]>
Reply-To: [email-masked]
To: Magnus Nystrom <[email-masked]>
Cc: Paul Leach <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

It seems to me that the fact that you have untrusted middlemen is 
even more reason why you would use TLS.  You do not trust them,
therefore you must protect your data end to end.  You allow the
middlemen to proxy, translate, ... the connection and then you
perform an end to end authentication and encryption.

> 
> Dear Paul,
> 
> No, I am not mis-speaking. There are in fact architectures like this.
> 
> -- Magnus
> 
> On Thu, 8 Jun 2000, Paul Leach wrote:
> 
> > 
> > 
> > > -----Original Message-----
> > > From: Magnus Nystrom [mailto:[email-masked]]
> > > Sent: Wednesday, June 07, 2000 10:26 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
> > > 
> > > 
> > > Dear Paul and John,
> > > 
> > > Thanks for your views. However, IMHO, TLS is not always suitable, for
> > > several reasons. Among them are:
> > > 
> > > -(partially quoting from a posting by P. Fahn, Certicom, sent to
> > >  another list:) Many network architectures today have
> > >  "untrusted" middlemen (gateways, proxies, translators, 
> > > formatters,
> > 
> > Allowing an "untrusted" middleman to translate or re-format information
> > flowing through it smacks of a recipe for disaster. Surely you
> > mis-speak.
> > 
> > Paul
> > 
> 
> -- Magnus
> Magnus Nystrom		Email: [email-masked]
> RSA Security
> 
> 
> 

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

From: "Scott Guthery" <[email-masked]>
To: "Magnus Nystrom" <[email-masked]>, "Paul Leach" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Date: Fri, 9 Jun 2000 06:11:08 -0400
Sender: [email-masked]

WAP, for example.

Cheers, Scott

----- Original Message ----- 
From: Magnus Nystrom <[email-masked]>
To: Paul Leach <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, June 09, 2000 5:50 AM
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

Dear Paul,

No, I am not mis-speaking. There are in fact architectures like this.

-- Magnus

On Thu, 8 Jun 2000, Paul Leach wrote:

> 
> 
> > -----Original Message-----
> > From: Magnus Nystrom [mailto:[email-masked]]
> > Sent: Wednesday, June 07, 2000 10:26 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
> > 
> > 
> > Dear Paul and John,
> > 
> > Thanks for your views. However, IMHO, TLS is not always suitable, for
> > several reasons. Among them are:
> > 
> > -(partially quoting from a posting by P. Fahn, Certicom, sent to
> >  another list:) Many network architectures today have
> >  "untrusted" middlemen (gateways, proxies, translators, 
> > formatters,
> 
> Allowing an "untrusted" middleman to translate or re-format information
> flowing through it smacks of a recipe for disaster. Surely you
> mis-speak.
> 
> Paul
> 

-- Magnus
Magnus Nystrom Email: [email-masked]
RSA Security

Date: Fri, 9 Jun 2000 12:04:21 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[email-masked]>
To: John Myers <[email-masked]>
cc: Robert Zuccherato <[email-masked]>, [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

Dear John,

On Wed, 7 Jun 2000, John Myers wrote:

> "Ramsay, Ron" wrote:
> > But then you are NOT using SASL/EXTERNAL because HostC is simply validating
> > HostB and not HostA!
> 
> In the example I provided in my last message, I am using EXTERNAL
> between HostA and HostB.  Any SASL mechanism, including EXTERNAL, that
> supports an authorization id field can be used between HostB and HostC.
> 
> This is analogous to the example you provided, since that example showed
> a TLS security association being established between HostA and HostB.
> 
> > For example, if we were using X.509 authentication, the certification path
> > and token would actually travel end-to-end and HostC would indeed receive
> > credentials from HostA.
> 
> If you instead want to establish a security association between HostA
> and HostC, then HostB should forward the TLS records through between
> HostA and HostC.

The TLS endpoint isn't always the same as the application endpoint and
that is the very reason for this proposal. Maybe this should be made more
explicit in the draft.

> > This really IS an application protocol. What you are talking about is a link
> > protocol. Your remarks about TLS being a session or application protocol are
> > simply wrong.
> 
> I'm sorry, I don't see the argument behind these assertions.  What
> difference between TLS and SASL makes TLS a "link" protocol as opposed
> to an "application" protocol?

IMHO, since it is possible to "insert" SASL in many higher-level protocols
it is a useful mechanism when, for one reason or another, lower level
protocols (I include TLS here) terminates at a gateway or similar, or the
application using the SASL-enabled protocol is unable to run TLS for one
reason or another, but is still capable of doing public-key operations.
 
> In your HostA, HostB, HostC situation, how would you handle a SASL
> negotiation using a mechanism that provides perfect forward secrecy of
> the identity being authenticated?

Just so we are talking about the same thing here: Perfect forward secrecy
= Disclosing one key/authentication does not give an attacker the
possibility to reuse that information in subsequent exchanges.

The proposed protocol is vulnerable to session hi-jacking, this fact is
also mentioned in the draft, and true also for other SASL mechanisms not
inserting a security layer.

-- Magnus

Date: Fri, 9 Jun 2000 11:50:06 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[email-masked]>
To: Paul Leach <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

Dear Paul,

No, I am not mis-speaking. There are in fact architectures like this.

-- Magnus

On Thu, 8 Jun 2000, Paul Leach wrote:

> 
> 
> > -----Original Message-----
> > From: Magnus Nystrom [mailto:[email-masked]]
> > Sent: Wednesday, June 07, 2000 10:26 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
> > 
> > 
> > Dear Paul and John,
> > 
> > Thanks for your views. However, IMHO, TLS is not always suitable, for
> > several reasons. Among them are:
> > 
> > -(partially quoting from a posting by P. Fahn, Certicom, sent to
> >  another list:) Many network architectures today have
> >  "untrusted" middlemen (gateways, proxies, translators, 
> > formatters,
> 
> Allowing an "untrusted" middleman to translate or re-format information
> flowing through it smacks of a recipe for disaster. Surely you
> mis-speak.
> 
> Paul
> 

-- Magnus
Magnus Nystrom		Email: [email-masked]
RSA Security

Date: Thu, 08 Jun 2000 12:40:04 -0700
From: David Margrave <[email-masked]>
Organization: Amazon.com, Inc.
To: John Myers <[email-masked]>
Cc: Linn John <[email-masked]>, "'Ken Hornstein'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: SASL GSSAPI draft
Sender: [email-masked]

Dave

content-class: urn:content-classes:message
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Date: Thu, 8 Jun 2000 10:10:46 -0700
From: "Paul Leach" <[email-masked]>
To: "Magnus Nystrom" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFD16C.7CC39E72
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> -----Original Message-----
> From: Magnus Nystrom [mailto:[email-masked]]
> Sent: Wednesday, June 07, 2000 10:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
>=20
>=20
> Dear Paul and John,
>=20
> Thanks for your views. However, IMHO, TLS is not always suitable, for
> several reasons. Among them are:
>=20
> -(partially quoting from a posting by P. Fahn, Certicom, sent to
>  another list:) Many network architectures today have
>  "untrusted" middlemen (gateways, proxies, translators,=20
> formatters,

Allowing an "untrusted" middleman to translate or re-format information
flowing through it smacks of a recipe for disaster. Surely you
mis-speak.

Paul

------_=_NextPart_001_01BFD16C.7CC39E72
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4384.0">
<TITLE>RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: Magnus Nystrom [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]=
</FONT>

<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, June 07, 2000 10:26 AM</FONT>

<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>

<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: RE: I-D Action: =
draft-zuccherato-9798-3-sasl-00.txt</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Dear Paul and John,</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Thanks for your views. However, IMHO, TLS is not =
always suitable, for</FONT>

<BR><FONT SIZE=3D2>&gt; several reasons. Among them are:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; -(partially quoting from a posting by P. Fahn, =
Certicom, sent to</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; another list:) Many network architectures =
today have</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; &quot;untrusted&quot; middlemen (gateways, =
proxies, translators, </FONT>

<BR><FONT SIZE=3D2>&gt; formatters,</FONT>
</P>

<P><FONT SIZE=3D2>Allowing an &quot;untrusted&quot; middleman to =
translate or re-format information flowing through it smacks of a recipe =
for disaster. Surely you mis-speak.</FONT></P>

<P><FONT SIZE=3D2>Paul</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD16C.7CC39E72--

Date: Wed, 07 Jun 2000 22:51:18 -0700
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms81E3B4AA457C0A57A98237DE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Ramsay, Ron" wrote:
> Can I substitute:
> 
> S: "Authentication failed. Try PLAIN"?

Sure.  You can even do this as soon as the client sends:

C: a AUTHENTICATE "TLS"

or even replace all the SASL mechanisms in the banner with just PLAIN. 
Or you can replace legitimate TLS records with TLS fatal alerts.

Protocol spoofers can do all sorts of interesting things if the
endpoints have a sufficiently lax security policy.

Which brings up an interesting point about the draft.  There's no point
having the mechanism support mutual authentication because the mechanism
doesn't support any security layers.  It's useless for the server to
prove its identity to the client since the moment the SASL negotiation
is over either side could be talking to anybody.
--------------ms81E3B4AA457C0A57A98237DE
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms81E3B4AA457C0A57A98237DE--

Date: Wed, 07 Jun 2000 21:55:15 -0700
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms878058F0A2C4ADC712311B67
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Ramsay, Ron" wrote:
> But then you are NOT using SASL/EXTERNAL because HostC is simply validating
> HostB and not HostA!

In the example I provided in my last message, I am using EXTERNAL
between HostA and HostB.  Any SASL mechanism, including EXTERNAL, that
supports an authorization id field can be used between HostB and HostC.

This is analogous to the example you provided, since that example showed
a TLS security association being established between HostA and HostB.

> For example, if we were using X.509 authentication, the certification path
> and token would actually travel end-to-end and HostC would indeed receive
> credentials from HostA.

If you instead want to establish a security association between HostA
and HostC, then HostB should forward the TLS records through between
HostA and HostC.

> This really IS an application protocol. What you are talking about is a link
> protocol. Your remarks about TLS being a session or application protocol are
> simply wrong.

I'm sorry, I don't see the argument behind these assertions.  What
difference between TLS and SASL makes TLS a "link" protocol as opposed
to an "application" protocol?

In your HostA, HostB, HostC situation, how would you handle a SASL
negotiation using a mechanism that provides perfect forward secrecy of
the identity being authenticated?
--------------ms878058F0A2C4ADC712311B67
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms878058F0A2C4ADC712311B67--

From: "Ramsay, Ron" <[email-masked]>
To: Lawrence Greenfield <[email-masked]>, [email-masked]
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Date: Thu, 8 Jun 2000 14:36:03 +1000 
Sender: [email-masked]

Larry,

I'm fascinated by

[ this next response would have to be done in plaintext]
S: a OK "Authentication succeeded using TLS/CRAM-MD5"

Can I substitute:

S: "Authentication failed. Try PLAIN"?

Ron.

-----Original Message-----
From: Lawrence Greenfield [mailto:[email-masked]]
Sent: Thursday, 8 June 2000 13:05
To: [email-masked]
Cc: John Gardiner Myers
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

[...]
   Magnus Nystrom wrote:
   >  The end users and content providers and application developers
   >  should be able to put in security on top of all the middlemen, at
   >  the application layer.

   TLS and SASL are both session layer protocols.  The name "Transport
   Layer Security" is a misnomer, TLS is not part of TCP, it is a layer
   above TCP.  Anywhere you can add a command to a protocol to do a SASL
   negotiation you can also add a command to do a TLS negotiation.

To be silly, why not do just this?  A "TLS" SASL mechanism could
easily be made.  For example (using ACAP as the protocol to avoid
base64 encoding):

C: a AUTHENTICATE "TLS"
S: "ok, start TLS negotiation"
C: {xxx+}
C: tls negotiation
S: + {xxx}
S: more tls negotiation
C: {xxx+}
C: tls negotiation
...
S: + "TLS done. AUTH=PLAIN AUTH=CRAM-MD5"
[ tls security layer takes effect here ]
C: "CRAM-MD5"
S: + "<[email-masked]>"
C: "response"
[ this next response would have to be done in plaintext]
S: a OK "Authentication succeeded using TLS/CRAM-MD5"
[ tls security layer resumed ]

This seems more useful than this proposed mechanism.  It allows TLS to
be negotiated in any protocol that has a SASL profile.

I shudder to add a third option to existing protocols (IMAP, POP) by
suggesting this (and I think that sinks this idea) but hey.  It does
mean that existing protocols need not define a STARTTLS command.

Larry

From: "Ramsay, Ron" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Date: Thu, 8 Jun 2000 14:19:15 +1000 
Sender: [email-masked]

But then you are NOT using SASL/EXTERNAL because HostC is simply validating
HostB and not HostA!

For example, if we were using X.509 authentication, the certification path
and token would actually travel end-to-end and HostC would indeed receive
credentials from HostA.

This really IS an application protocol. What you are talking about is a link
protocol. Your remarks about TLS being a session or application protocol are
simply wrong.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, 8 June 2000 13:21
To: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

"Ramsay, Ron" wrote:
> I connect to HostB (thinking that it is HostC, if I understand how a DMZ
> works) using TLS and receiver a server certificate. I'm using
SASL/EXTERNAL,
> so I send my client certificate. The connection is established.

Ah, it's as I thought.  Mr. Nystrom's statement:

>  The end users and content providers and application developers
>  should be able to put in security on top of all the middlemen, at
>  the application layer. And middlemen want the same thing to avoid the
>  liability that comes with seeing all the plaintext.

is entirely false.  The middlemen want to eavesdrop on and spoof the
plaintext, so you're trying to negotiate a level of security that is
lower than TLS permits.

What we do in this situation is instead of having HostB forward the
EXTERNAL authentication to HostC, we have HostB perform its own SASL
negotiation with HostC, using whatever SASL mechanism it wants,
providing its own credentials, and passing HostA's user's identity in
the authorization id field.  TLS can be used between HostB and HostC or
not, depending on the site's security requirements.

Date: Wed, 07 Jun 2000 20:20:50 -0700
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms950CC6E5C461642C245C16E9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Ramsay, Ron" wrote:
> I connect to HostB (thinking that it is HostC, if I understand how a DMZ
> works) using TLS and receiver a server certificate. I'm using SASL/EXTERNAL,
> so I send my client certificate. The connection is established.

Ah, it's as I thought.  Mr. Nystrom's statement:

>  The end users and content providers and application developers
>  should be able to put in security on top of all the middlemen, at
>  the application layer. And middlemen want the same thing to avoid the
>  liability that comes with seeing all the plaintext.

is entirely false.  The middlemen want to eavesdrop on and spoof the
plaintext, so you're trying to negotiate a level of security that is
lower than TLS permits.

What we do in this situation is instead of having HostB forward the
EXTERNAL authentication to HostC, we have HostB perform its own SASL
negotiation with HostC, using whatever SASL mechanism it wants,
providing its own credentials, and passing HostA's user's identity in
the authorization id field.  TLS can be used between HostB and HostC or
not, depending on the site's security requirements.
--------------ms950CC6E5C461642C245C16E9
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms950CC6E5C461642C245C16E9--

Date: Wed, 7 Jun 2000 23:04:30 -0400 (EDT)
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Cc: John Gardiner Myers <[email-masked]>
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

[...]
   Magnus Nystrom wrote:
   >  The end users and content providers and application developers
   >  should be able to put in security on top of all the middlemen, at
   >  the application layer.

   TLS and SASL are both session layer protocols.  The name "Transport
   Layer Security" is a misnomer, TLS is not part of TCP, it is a layer
   above TCP.  Anywhere you can add a command to a protocol to do a SASL
   negotiation you can also add a command to do a TLS negotiation.

To be silly, why not do just this?  A "TLS" SASL mechanism could
easily be made.  For example (using ACAP as the protocol to avoid
base64 encoding):

C: a AUTHENTICATE "TLS"
S: "ok, start TLS negotiation"
C: {xxx+}
C: tls negotiation
S: + {xxx}
S: more tls negotiation
C: {xxx+}
C: tls negotiation
...
S: + "TLS done. AUTH=PLAIN AUTH=CRAM-MD5"
[ tls security layer takes effect here ]
C: "CRAM-MD5"
S: + "<[email-masked]>"
C: "response"
[ this next response would have to be done in plaintext]
S: a OK "Authentication succeeded using TLS/CRAM-MD5"
[ tls security layer resumed ]

This seems more useful than this proposed mechanism.  It allows TLS to
be negotiated in any protocol that has a SASL profile.

I shudder to add a third option to existing protocols (IMAP, POP) by
suggesting this (and I think that sinks this idea) but hey.  It does
mean that existing protocols need not define a STARTTLS command.

Larry

From: "Ramsay, Ron" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Date: Thu, 8 Jun 2000 12:56:07 +1000 
Sender: [email-masked]

An example.

We are going to attempt an authenticated logon through a DMZ. Therefore, we
have my host, HostA, the DMZ host, HostB, and the destination host, HostC.

I connect to HostB (thinking that it is HostC, if I understand how a DMZ
works) using TLS and receiver a server certificate. I'm using SASL/EXTERNAL,
so I send my client certificate. The connection is established.

I logon, specifying SASL/EXTERNAL. HostB receives the logon and passes it to
HostC. HostC does not have my client certificate and rejects the logon.

Ron.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, 8 June 2000 12:23
To: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

"Ramsay, Ron" wrote:
> I thought the statement at issue was that TLS is a good poit-to-point
> solution but that it can't be used where middle-men are involved (DMZs,
for
> example).

I am indeed taking issue with this statement.  Anywhere you have a SASL
protocol definition conforming to RFC 2222 section 4, I can construct an
extension to do a TLS negotiation.

> In particular, SASL/EXTERNAL cannot be used.

I disagree.  Please provide a concrete example of where this breaks.
 
> I don't believe TLS is a session layer protocol, either. Its purpose and
> implementation are as a network layer look-alike. Wherever TCP is found,
TLS
> may be shimmed in.

TLS can also be shimmed in other places.

> I also can't understand references to SASL services and then proposing to
> use TLS without client certificates.

I am not proposing to use TLS without client certificates, I am using
the number of extant TLS implementations without client certificates to
support the arugument that client certificate management is
significantly harder to implement than TLS.

Date: Wed, 07 Jun 2000 19:23:02 -0700
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms4B5289C8F322EAB542625529
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Ramsay, Ron" wrote:
> I thought the statement at issue was that TLS is a good poit-to-point
> solution but that it can't be used where middle-men are involved (DMZs, for
> example).

I am indeed taking issue with this statement.  Anywhere you have a SASL
protocol definition conforming to RFC 2222 section 4, I can construct an
extension to do a TLS negotiation.

> In particular, SASL/EXTERNAL cannot be used.

I disagree.  Please provide a concrete example of where this breaks.
 
> I don't believe TLS is a session layer protocol, either. Its purpose and
> implementation are as a network layer look-alike. Wherever TCP is found, TLS
> may be shimmed in.

TLS can also be shimmed in other places.

> I also can't understand references to SASL services and then proposing to
> use TLS without client certificates.

I am not proposing to use TLS without client certificates, I am using
the number of extant TLS implementations without client certificates to
support the arugument that client certificate management is
significantly harder to implement than TLS.
--------------ms4B5289C8F322EAB542625529
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms4B5289C8F322EAB542625529--

From: "Ramsay, Ron" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Date: Thu, 8 Jun 2000 11:54:47 +1000 
Sender: [email-masked]

I must have blinked.

I thought the statement at issue was that TLS is a good poit-to-point
solution but that it can't be used where middle-men are involved (DMZs, for
example).

In particular, SASL/EXTERNAL cannot be used.

I don't believe TLS is a session layer protocol, either. Its purpose and
implementation are as a network layer look-alike. Wherever TCP is found, TLS
may be shimmed in. So, it provides neither transport nor session services.

I also can't understand references to SASL services and then proposing to
use TLS without client certificates. Even if SASL/EXTERNAL could be used, it
would be useless without client certificates.

Ron.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, 8 June 2000 11:26
To: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

Magnus Nystrom wrote:
>  The end users and content providers and application developers
>  should be able to put in security on top of all the middlemen, at
>  the application layer.

TLS and SASL are both session layer protocols.  The name "Transport
Layer Security" is a misnomer, TLS is not part of TCP, it is a layer
above TCP.  Anywhere you can add a command to a protocol to do a SASL
negotiation you can also add a command to do a TLS negotiation.

>  And middlemen want the same thing to avoid the
>  liability that comes with seeing all the plaintext.

Since proposed SASL mechanism doesn't support any security layers, when
it is used the middlemen will always see the plaintext.

> -As mentioned in the draft, TLS is more complex and does not carry the
>  concept of separate authentication and authorization identities.

The concept of separate authentication and authorization identities is
handled through the use of the EXTERNAL SASL mechanism once the TLS
negotiation is complete.  As I have mentioned before, TLS complexity is
small compared to the complexity of key and certificate management, as
evidenced by the number of applications implementing TLS but not
implementing client certs.

Date: Wed, 07 Jun 2000 18:26:05 -0700
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msDBB2633BB5C5E1273A580AC7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Magnus Nystrom wrote:
>  The end users and content providers and application developers
>  should be able to put in security on top of all the middlemen, at
>  the application layer.

TLS and SASL are both session layer protocols.  The name "Transport
Layer Security" is a misnomer, TLS is not part of TCP, it is a layer
above TCP.  Anywhere you can add a command to a protocol to do a SASL
negotiation you can also add a command to do a TLS negotiation.

>  And middlemen want the same thing to avoid the
>  liability that comes with seeing all the plaintext.

Since proposed SASL mechanism doesn't support any security layers, when
it is used the middlemen will always see the plaintext.

> -As mentioned in the draft, TLS is more complex and does not carry the
>  concept of separate authentication and authorization identities.

The concept of separate authentication and authorization identities is
handled through the use of the EXTERNAL SASL mechanism once the TLS
negotiation is complete.  As I have mentioned before, TLS complexity is
small compared to the complexity of key and certificate management, as
evidenced by the number of applications implementing TLS but not
implementing client certs.
--------------msDBB2633BB5C5E1273A580AC7
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msDBB2633BB5C5E1273A580AC7--

Date: Wed, 7 Jun 2000 19:29:48 +0200 (MET DST)
From: Magnus Nystrom <[email-masked]>
Reply-To: Magnus Nystrom <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

Chris,

Many thanks for your comments and suggestions for improvements. My
response below.

On Tue, 6 Jun 2000, Chris Newman wrote:

> --On Tuesday, May 30, 2000 15:00 +0200 Magnus Nystrom 
> <[email-masked]> wrote:
> > FYI. Comments and feedback is welcome and solicited.
> 
> I skimmed the document.  I'm sorry I don't have time to chase down all the 
> X.509/FIPS references necessary to grok the spec.
> 
> (1) It seems to have far too many things marked "OPTIONAL".  This makes the 
> protocol more complex than necessary.  Preferably the only OPTIONAL items 
> should be the differences between one-way and mutual auth.  RandomC 
> certainly has no business being optional.

Right, we will change this in the next draft.

> (2) I don't understand the value of this if the client cert is optional. 
> Doesn't that mean the server has to store the certs for every possible 
> client in order to guarantee interoperability?  Or am I missing something?

Yes, client CertData should probably be mandatory.

> (3) I presume this factors in the DNS name of the server which the client 
> intends to communicate with -- usually the only information the client has 
> about the server.  Where can I read the rules for how that is used?  Is 
> that put in the EntityB field?  Is the case where multiple physical servers 
> answer for the same domain name considered?  Is it possible for each 
> physical server to have a different private key in that case?

Yes it is. Only requirement is that the server is able to see that the
client intended to communicate with it - if, e.g., there is a round-robin
DNS, then for all intent and purposes involved servers are the same (from
the client's perspective). It could be that the DNS name is a SHOULD (or
even a MUST?).

> (4) I don't see a clear statement of how to determine the authorization 
> identity (user to log in as, which may be different from the user whose 
> private key is used).  If this is buried somewhere in X.509 specs, please 
> draw attention to it in the spec.

Correct, thanks for the observation. There should be an explicit,
but optional, authorization id included. If not included, the server will
have to use the authenticated id.

> (5) The reference to RFC 1738 should be updated to RFC 2396.

Right.

> (6) Is there a fast re-authentication option, or should TLS be used when 
> that's needed?  Note that many POP clients make a connection every 5 
> minutes to check mail, and some IMAP clients make a new connection every 
> time a new folder is opened so a fast re-authentication protocol could be 
> important for scalability.

No, there is no fast re-authentication option. One could add one (for
example by letting the entities negotiate a session secret) but it is our
feeling that this would complicate the mechanism unnecessarily.
 
> (7) Is there an open-source implementation of RFC 2459?  If not, this seems 
> much more complex than TLS where I can just grab OpenSSL and let it do all 
> the work.

Certificate-handling open-source is certainly available,e.g. as part of
OpenSSL, and ssleay, but the Jonah PKIX freeware library is another
alternative, I guess.

> (8) The IETF has a policy (the "Munich Mandate") which prohibits making 
> patented algorithms mandatory to implement when there's and unpatented 
> equivalent.  I consider the recommendation to implement the RSA algorithm 
> inappropriate given that policy.  Since this is a set of mechanisms rather 
> than a protocol, the recommendation is not necessary for interoperability 
> so you could simply remove it.  Alternatively you could change it to 
> recommend DSA, or wait until after September 20th for standardization.

Right, the latter was (and is) our intent.

Thanks,
-- Magnus

Date: Wed, 7 Jun 2000 19:25:57 +0200 (MET DST)
From: Magnus Nystrom <[email-masked]>
Reply-To: Magnus Nystrom <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

Dear Paul and John,

Thanks for your views. However, IMHO, TLS is not always suitable, for
several reasons. Among them are:

-(partially quoting from a posting by P. Fahn, Certicom, sent to
 another list:) Many network architectures today have
 "untrusted" middlemen (gateways, proxies, translators, formatters, and it
 is not unlikely that architectures like this will increase in numbers.

 The end users and content providers and application developers
 should be able to put in security on top of all the middlemen, at
 the application layer. And middlemen want the same thing to avoid the
 liability that comes with seeing all the plaintext. Since one will not
 always have simple two-party network topologies, simple transport-layer
 channel security will not always be enough.

-As mentioned in the draft, TLS is more complex and does not carry the
 concept of separate authentication and authorization identities.

Regards,
-- Magnus

On Tue, 6 Jun 2000, Paul Leach wrote:

> > -----Original Message-----
> > From: John Myers [mailto:[email-masked]]
> > Sent: Tuesday, June 06, 2000 5:03 PM
> > To: [email-masked]
> > Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
> > 
> > TLS does appear to have won the X.509 space and is gaining
> > implementation momentum.  I think this draft is approaching the
> > wrong problem. 
> 
> I concur completely.
> 
> Paul

content-class: urn:content-classes:message
Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Date: Tue, 6 Jun 2000 18:38:55 -0700
From: "Paul Leach" <[email-masked]>
To: "John Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFD021.244B91F6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> -----Original Message-----
> From: John Myers [mailto:[email-masked]]
> Sent: Tuesday, June 06, 2000 5:03 PM
> To: [email-masked]
> Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
>=20
>=20
>  TLS does
> appear to have won the X.509 space and is gaining implementation
> momentum.  I think this draft is approaching the wrong problem.

I concur completely.

Paul

------_=_NextPart_001_01BFD021.244B91F6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4384.0">
<TITLE>RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: John Myers [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FO=
NT>

<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, June 06, 2000 5:03 PM</FONT>

<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: Re: I-D Action: =
draft-zuccherato-9798-3-sasl-00.txt</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; TLS does</FONT>

<BR><FONT SIZE=3D2>&gt; appear to have won the X.509 space and is =
gaining implementation</FONT>

<BR><FONT SIZE=3D2>&gt; momentum.&nbsp; I think this draft is =
approaching the wrong problem.</FONT>
</P>

<P><FONT SIZE=3D2>I concur completely.</FONT>
</P>

<P><FONT SIZE=3D2>Paul</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD021.244B91F6--

Date: Tue, 06 Jun 2000 17:03:23 -0700
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms5EBBBA0BCDF14825170DA5B8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I second Chris Newman's comments, though I think that if this is
intended for standardization then waiting for September 20 is better
than switching to DSA.

I'd appreciate it if you could expand on why you want to do this as a
SASL mechanism instead of using a combination of TLS and the EXTERNAL
SASL mechanism.  My experience with implementing this stuff is that the
key and certificate management aspects are far harder to implement than
the protocol aspects.

Each of the important protocols has an extension to start a TLS
negotiation on a previously unprotected connection.  At the latest
MailConnect, there were quite a few implementations of these STARTTLS
extensions.  Only three of these companies supported client certs, this
was up from one company the previous year.

A product implementing only this draft will not interoperate with a
product implementing only the combination of TLS and EXTERNAL.  TLS does
appear to have won the X.509 space and is gaining implementation
momentum.  I think this draft is approaching the wrong problem.
--------------ms5EBBBA0BCDF14825170DA5B8
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms5EBBBA0BCDF14825170DA5B8--

Date: Tue, 06 Jun 2000 16:21:15 -0700
From: [email-masked] (John Myers)
To: "Linn John" <[email-masked]>
CC: "'Ken Hornstein'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: SASL GSSAPI draft
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms44C1D113AC5AE39E0F921503
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is why I discourage rather than encourage SPNEGO underneath SASL. 
Unless you have a security policy of allowing certain mechanisms only
when their negotiation has been protected, the SPNEGO negotiation
protection doesn't buy you anything.  This particular security policy is
explicitly mentioned in the draft as a reason to violate the SHOULD NOT
directive against SPNEGO under SASL.
--------------ms44C1D113AC5AE39E0F921503
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms44C1D113AC5AE39E0F921503--

Date: Tue, 06 Jun 2000 15:54:38 -0700
From: [email-masked] (John Myers)
To: [email-masked], [email-masked]
Subject: Re: SASL GSSAPI draft
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms7A4108F79C32C4FD17956951
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ken Hornstein wrote:
> Okay, I saw only a message from Bill Ricker asking about SPNEGO,
> posting by you, and Paul Leach's reply.

I recall some other exchange when I first published a draft, but haven't
located it.  It doesn't much matter, we're having a good discussion
about this now.

> Having said that .... I
> think that a client that sent a SPNEGO token to a SPNEGO-unaware
> server would fail.  I have been thinking for a while on how to
> migrate to clients & servers supporting SPNEGO, and I haven't come
> up with any good ideas yet (if I'm missing something obvious, then
> please let me know).

I don't think you can make this work and maintain SPNEGO's security
requirement to protect the negotiation of mechanism.  A man in the
middle could make it appear to each side that the other does not support
SPNEGO, thus forcing a downgrade to the weakest mechanism.

If you are willing to take this risk, forgoing this property of SPNEGO,
then the propsal to negoitate the mechanism directly through SASL
instead of through SPNEGO is simpler.

> This presumes that the app will have to have special-case code to
> determine which mechanisms exist and to apply policy information
> to the mechanism list; I'm not sure how you'll do that without
> giving the app knowledge of each mechanism, which would kinda defeat
> part of the purpose of GSSAPI.  I have a hard time imaging this done
> in practice (it seems that you can give SPNEGO some policy constraints,
> but it doesn't give you the ability to do the ordering you want).

Typically, a SASL library has both policy constrants and a mechanism
preference ordering.  Usually the preferences are ordered from strongest
mechanism to weakest, but sometimes the cost of obtaining a credential
affects this.  For example, if the SASL library has a Kerberos
credential available, it may want to use Kerberos over any mechanism
that will need to prompt the user.
--------------ms7A4108F79C32C4FD17956951
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms7A4108F79C32C4FD17956951--

Date: Tue, 06 Jun 2000 08:54:58 -0700
From: Chris Newman <[email-masked]>
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
To: Magnus Nystrom <[email-masked]>, [email-masked]
Sender: [email-masked]

--On Tuesday, May 30, 2000 15:00 +0200 Magnus Nystrom 
<[email-masked]> wrote:
> FYI. Comments and feedback is welcome and solicited.

I skimmed the document.  I'm sorry I don't have time to chase down all the 
X.509/FIPS references necessary to grok the spec.

(1) It seems to have far too many things marked "OPTIONAL".  This makes the 
protocol more complex than necessary.  Preferably the only OPTIONAL items 
should be the differences between one-way and mutual auth.  RandomC 
certainly has no business being optional.

(2) I don't understand the value of this if the client cert is optional. 
Doesn't that mean the server has to store the certs for every possible 
client in order to guarantee interoperability?  Or am I missing something?

(3) I presume this factors in the DNS name of the server which the client 
intends to communicate with -- usually the only information the client has 
about the server.  Where can I read the rules for how that is used?  Is 
that put in the EntityB field?  Is the case where multiple physical servers 
answer for the same domain name considered?  Is it possible for each 
physical server to have a different private key in that case?

(4) I don't see a clear statement of how to determine the authorization 
identity (user to log in as, which may be different from the user whose 
private key is used).  If this is buried somewhere in X.509 specs, please 
draw attention to it in the spec.

(5) The reference to RFC 1738 should be updated to RFC 2396.

(6) Is there a fast re-authentication option, or should TLS be used when 
that's needed?  Note that many POP clients make a connection every 5 
minutes to check mail, and some IMAP clients make a new connection every 
time a new folder is opened so a fast re-authentication protocol could be 
important for scalability.

(7) Is there an open-source implementation of RFC 2459?  If not, this seems 
much more complex than TLS where I can just grab OpenSSL and let it do all 
the work.

(8) The IETF has a policy (the "Munich Mandate") which prohibits making 
patented algorithms mandatory to implement when there's and unpatented 
equivalent.  I consider the recommendation to implement the RSA algorithm 
inappropriate given that policy.  Since this is a set of mechanisms rather 
than a protocol, the recommendation is not necessary for interoperability 
so you could simply remove it.  Alternatively you could change it to 
recommend DSA, or wait until after September 20th for standardization.

		- Chris

Date: Mon, 05 Jun 2000 21:51:30 -0700
From: Chris Newman <[email-masked]>
Subject: RE: SASL GSSAPI draft
To: "Linn, John" <[email-masked]>, "'Ken Hornstein'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

		- Chris