Subject: Major SASL issues (was Re: Last Call: 'XMPP Core' to Proposed Standard)

From: Alexey Melnikov <[email-masked]>
Date: Tue, 07 Oct 2003 22:49:33 +0100

The IESG wrote:

>The IESG has received a request from the Extensible Messaging and Presence 
>Protocol WG to consider the following document:
>
>- 'XMPP Core '
>   <draft-ietf-xmpp-core-18.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by 2003-10-09.
>                                                                                       
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-xmpp-core-18.txt
>
I would like to raise several SASL related issues in XMPP document.
(Sorry for crosspost and sorry for being late with reviewing this.)

1).
 >   7.  The initiating entity MUST provide an authzid during SASL
 >       negotiation. The authzid-value MUST be a valid JID of the form
 >       <domain> (i.e., a domain identifier only) for servers and of the
 >       form <user@domain/resource> (i.e., node identifier, domain
 >       identifier, and resource identifier) for clients. The initiating
 >       entity MAY process the authzid-value in accordance with the rules
 >       defined in Addressing Scheme (Section 3) before providing it to
 >       the receiving entity, but is NOT REQUIRED to do so; however, the
 >       receiving entity MUST verify that the authzid-value provided by
 >       the initiating entity conforms to the rules defined therein.

Not all SASL mechanisms are capable of transmitting authorization 
identity, so this requirement might be problematic.

Also, the revision of RFC 2222 says that the client must not specify 
authorization-id unless it wants to impersonate some other entity:

   As a client might not have the same information as the server,
   clients SHOULD NOT themselves try to derive authorization identities
   from authentication identities when clients could instead transmit an
   authorization identity of the empty string.

So, the text should be reworded reflect that an authorization identity 
is optional and that if one is provided, it is in the form described above.

2).

 >   This series of challenge/response pairs continues until one of three
 >   things happens:
 >
 >   1.  The initiating entity aborts the handshake by sending an <abort/>
 >       element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
 >       namespace to the receiving entity. Upon receiving the <abort/>
 >       element, the receiving entity MUST terminate the TCP connection.

I think the requirement to drop TCP connection is unreasonable here.
There are several valid reasons why the client may retry failed 
authentication:
1). User typed in a wrong password, the client should retry the same 
SASL mechanism a reasonable number of times.
2). The client invoked a SASL mechanism that reported that it can't be 
used because of misconfiguration (e.g. kerberos configuration file is 
missing). The client than sends <abort/> to the server and tries another 
mechanism.

3).

 >   3.  The receiving entity reports success of the handshake by sending
 >       a <success/> element qualified by the
 >       'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
 >       entity; this element MAY optionally contain character data (in
 >       SASL terminology "additional data with success"). Upon receiving
 >       the <success/> element, the initiating entity MUST initiate a new
 >       stream by sending an opening XML stream header to the receiving
 >       entity (it is not necessary to send a closing </stream:stream>
 >       element first, since the receiving entity and initiating entity
 >       MUST consider the original stream to be closed upon sending or
 >       receiving the <success/> element). Upon receiving the new stream
 >       header from the initiating entity, the receiving entity MUST
 >       respond by sending a new XML stream header to the initiating
 >       entity, along with any remaining available features (but NOT
 >       including the STARTTLS feature or any authentication mechanisms)
 >       or an empty features element (to signify that no additional
 >       features are available); note that any such additional features
 >       are not defined herein, and MUST be defined by the relevant
 >       extension to XMPP.

Other protocols (IMAP/SMTP/POP) list available SASL mechanisms after a 
successful SASL authentication.
Some of them require that the client compares the list of the advertised 
mechanism with the one before the authentication.
This is done to prevent man-in-the-middle attacks when an attacker 
removes strong SASL mechanisms from the list of supported mechanisms.
(Whether this check is useful in practice is another matter. I am not 
sure whether anybody implements it).

4). There was a recent discussion on the bugtraq mailing list about 
handling invalid base64 data. It turned out that different 
implementations handle
this differently, for example:
1). Ignore invalid characters
2). Treat an invalid character as the end of the base64 encoded data 
(and ignore the rest)
3). Truncate base64 encoded data before the invalid character.

In particular there was a discussion regarding the padding character 
('=') in the middle of a base64 data.

I suggest that some text about this be added to the Security 
considerations sections. For example:

Both the client and the server should verify the received base64 data 
and reject (and not ignore) any characters not explicitly allowed by the 
base64 alphabet
[BASE64] and should reject any sequence of base64 characters that 
contains the pad ('=') character not as the last
character of the (e.g. "=AAA" or "BBBB=CCC").

[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 
RFC 3548, July 2003.

(You might decide to relax this for XMPP and to allow spaces and/or 
CRLFs anywhere in the data.)

5).
 >6.3 SASL Errors
 >
 >   o  <bad-protocol/> -- The data provided by the initiating entity
 >      could not be processed, e.g. because does not adhere to the
 >      protocol for the requested mechanism; sent in response to the
 >      <response/> element.

Do you mean invalid base64 encoding here or something else?

6).

 >6.3 SASL Errors
 >
 >   The following SASL-related error conditions are defined:
 >
 >   o  <aborted/> -- The receiving entity acknowledges an <abort/>
 >      element sent by the initiating entity; sent in response to the
 >      <abort/> element.
 >
 >   o  <bad-protocol/> -- The data provided by the initiating entity
 >      could not be processed, e.g. because does not adhere to the
 >      protocol for the requested mechanism; sent in response to the
 >      <response/> element.

or <auth/> with initial challenge data. Example: SASL PLAIN mechanism.

 >   o  <encryption-required/> -- The mechanism chosen by the initiating
 >      entity may be used only if the stream is already encrypted; sent
 >      in response to the <auth/> element.
 >
 >   o  <invalid-authzid/> -- The authzid provided by the initiating
 >      entity is invalid, either because it is incorrectly formatted or
 >      because the initiating entity does not have permissions to
 >      authorize that ID; sent in response to a <response/> element.

or <auth/> with initial challenge data.

 >   o  <invalid-mechanism/> -- The initiating entity did not provide a
 >      mechanism or requested a mechanism that is not supported by the
 >      receiving entity; sent in response to the <auth/> element.
 >
 >   o  <invalid-realm/> -- The realm provided by the initiating entity
 >      (in mechanisms that support the concept of a realm) does not match
 >      one of the hostnames served by the receiving entity; sent in
 >      response to a <response/> element.

or <auth/> with initial challenge data.

 >   o  <mechanism-too-weak/> -- The mechanism requested by the initiating
 >      entity is weaker than server policy permits for that initiating
 >      entity; sent in response to the <response/> element.

or <auth/> with initial challenge data.

 >   o  <not-authorized/> -- The authentication failed because the
 >      initiating entity did not provide valid credentials (this includes
 >      the case of an unknown username); sent in response to a 
<response/> element.   

or <auth/> with initial challenge data.

7).

 >12.4 Order of Layers
 >
 >   The order of layers in which protocols MUST be stacked is as follows:
 >
 >   1.  TCP
 >
 >   2.  TLS
 >
 >   3.  SASL
 >
 >   4.  XMPP
 >
 >   The rationale for this order is that TCP is the base connection layer
 >   used by all of the protocols stacked on top of TCP, TLS is often
 >   provided at the operating system layer, SASL is often provided at the
 >   application layer, and XMPP is the application itself.

This should be referenced in "6.4 SASL Definition" section, because it 
is related to the XMPP profile of SASL.

Cheers,
Alexey

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 8 Oct 2003 12:40:46 -0500

> (Sorry for crosspost and sorry for being late with reviewing this.)

No apologies necessary -- your feedback is appreciated.

> is optional and that if one is provided, it is in the form described above.

My understanding from an earlier thread on the XMPP WG list was that
providing the authorization identity in this manner was the approach
preferred by the SASL community. I think the fundamental issue here is
that for XMPP clients, the authorization identity is a "full JID" (i.e.,
node@host/resource) that is asserted by the connecting client, not
derived by the server. Perhaps this usage is not consistent with the
definition of authorization identity in RFC 2222? We'd have to look at
the implications of this for client assertion of a full JID (perhaps
this should be defined only in draft-ietf-xmpp-im).

> missing). The client than sends <abort/> to the server and tries another 

This seems reasonable. I think we were attempting to ensure that the
connecting entity could not abuse the opened TCP connection for an
unspecified period of time.

> sure whether anybody implements it).

OK, I'll look at what those other protocols require, and how they word
the requirement. It seems good to have this check in place. 

> [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 

Thanks for the suggested text.

> CRLFs anywhere in the data.)

I see no strong reason to relax the requirement just for XMPP.

> Do you mean invalid base64 encoding here or something else?

It could be invalid base64 encoding, but we were thinking especially
that the decoded response is not consistent with the challenge format
required by the selected SASL mechanism.

> or <auth/> with initial challenge data.

I've fixed these in my working copy.

> is related to the XMPP profile of SASL.

Fixed in my working copy.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Oct 2003 22:56:38 -0700

To the IESG,

I concur with Alexey's recent comments regarding XMPP's SASL
Profile.  I have a few addition concerns regarding this profile.
The scope of my review was, due to time constraints, was limited
to the profile.

I not sure why the documents says that SASL and TLS security
layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2),
but this recommendation is, I believe, flawed.  There are numerous use
cases where implementations SHOULD establish additional layers.
For example, establishing additional SASL layers may prevent
certain kinds of tunneling man-in-the-middle attacks.

The requirement that initiating receiving entity drop all knowledge
it learned before negotiating SASL layers (rule 5) is too broad.
This could be viewed as requiring the implement to forget knowledge
it gained previously in a secure manner (such as an externally
established lower level (IPSEC or TLS) identity information).
Likewise for rule 6.

For rule 8, a normative reference to the base64 encoding algorithm
should be provided.

I am also concerned by the use of the term "stream encryption"
in the document as this doesn't imply, in my eyes, "stream
integrity".   It's unclear to me which imperatives imply when
encryption, integrity, and/or in combination with other security
services which TLS provides.

Additionally, I would like to note that the document suffers
from a number of nits.  As I only did a casual scan, this
list is likely no where near complete.  I suggest that XMMP
WG members be asked to do a more careful review for nits.

	Acronym not spelled out in title: XMMP
	Citiation in abstract
	Used old citation style (numeric tags instead of mnemonic tags)
	Acronyms not spelled out on first use in Abstract: XML
	Table of contents too long
	Acronyms not spelled out on first use in body: XML, JID
	Confusing upper casing of words: COULD
	Odd use of 2119 keywords: "MAY optionally"

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 8 Oct 2003 14:24:40 -0400 (EDT)

> > mechanism with the one before the authentication.

This claim isn't true.  SMTP has a MAY for this, the other protocols don't
express an opinion one way or the other.  I know some IMAP and POP
implementations remove the capability after a successful authentication
(to indicate that the AUTHENTICATE/AUTH command is no longer valid)

> the requirement. It seems good to have this check in place.

I'm not sure its terribly useful, since the real way to prevent this MitM
attack is that a client should not use a mechanism that does not support
its minimum security requirements, not find out after the fact that you
have an active attacker.

I will also be posting IDs within the next few days that are revisions to
RFC 1734 (and the SASL bits of RFC 2449) and RFC 2554, which may also be
useful to look at (hopefully they will be clearer).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 20:10:23 +0100

>unspecified period of time.
Closing connection or refusing to perform any tasks after a certain 
number of failures are two common implementation practice in SMTP and 
other protocols.
I think you should mention them, but don't require everyone to implement 
them.

>the requirement. It seems good to have this check in place. 
I don't have a strong feeling about this. I am just emphasizing the 
difference between other protocols and XMPP in this case.

A security person should comment on this.

>>...
This is fine. I was just thinking about a base64 encoder that enforces a 
line length limit and will insert CRLF automatically.

>required by the selected SASL mechanism.
Challenge format is specific to a SASL mechanism. As far as the protocol 
using SASL is concerned, invalid SASL mechanism format is not different 
from "authentication failure".
An error from a SASL mechanism is different from an error resulting in 
inability to decode base64 data.
These errors happen at different layers, so they should have different 
error tags.

Regards,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 20:31:34 +0100

>this should be defined only in draft-ietf-xmpp-im).
There are two issues here:
1). Format of an authorization identity - your document has to define it
2). Requirement to always specify authorization identity.

Short answer to the second issue is probably "you can't do that".
But here I will try to give a long answer to explain that you probably 
don't need 2 anyway.

This is a bit tricky. SASL defines two types of identities. 
Authentication identity is derived from your authentication credentials 
and its format is SASL mechanism specific. Authorization identity is 
protocol specific. If authorization identity is not specified ("empty 
authorization identity"), it is derived from the authentication 
identity. This is the usual case ("just act as yourself").

However is authorization identity is specified, additional authorization 
checks take place. The server has to verify that the authentication 
identity can act as the authorization identity.  Authorization identity 
is useful, for example, when an administrator (or proxy server) wants to 
authenticate as himself, but act as the user.
In XMPP case I can also imagine a client that tries to authenticate as 
"node@host", but act as "node@host/resource".

So, what does this means for a server implementor? The text below 
describes my implementation experience and doesn't specify a standard of 
any kind.

Usually deployed SASL mechanisms (PLAIN/CRAM-MD5/DIGEST-MD5) don't put 
any restrictions on how an authentication identity looks like.
So, in most cases "node@host/resource" (for the client-to-server) or 
"host" (for the server-to-server) format will be used.

For Kerberos mechanisms (KERBEROS_V4, GSSAPI), authentication identity 
has the format dictated by Kerberos (usually user@realm or 
service@realm). An XMPP implementation will have to internally map 
Kerberos principals to XMPP JID format (or host), before verifying an 
authorization identity, if the one was provided.

Of course, there is also SASL EXTERNAL that can be used together with 
TLS. In this case authentication identity will have syntax of a DN.

The bottom line is that the syntax used for authorization identities for 
a protocol is [most likely] the syntax that is going to be used 
internally by the server and is the same syntax that is used by the user 
in the "enter your username" dialog for the protocol.

(Hopefully this makes sense ;-)).

So, the paragraph should probable read:

 7.  An authorization identity used in SASL is a valid JID of the form
      <domain> (i.e., a domain identifier only) for servers and of the
      form <user@domain/resource> (i.e., node identifier, domain
      identifier, and resource identifier) for clients. ...

Regards,
Alexey

Cell: +44 7753759732

---

From: Eric Rescorla <[email-masked]>
Date: 08 Oct 2003 13:28:14 -0700

> certain kinds of tunneling man-in-the-middle attacks.
Could you describe some of them?

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Tony Hansen <[email-masked]>
Date: Wed, 08 Oct 2003 16:52:59 -0400

White space and CRLFs were specifically allowed in the original MIME base64 
specification because of:

	line length limitations in the underlying protocols

	gateways that would add or subtract white space willy-nilly

	it was useful being able to work with base64 data in small chunks when
	doing development and debugging

The first two issues don't apply here, but the last one certainly still does.

So I'd recommend that whitespace and CRLFs be ignored.

	Tony Hansen
	[email-masked]

Alexey Melnikov wrote:
> The IESG wrote:
> 
>> The IESG has received a request from the Extensible Messaging and 
>> Presence Protocol WG to consider the following document:
>>
>> - 'XMPP Core '

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 08 Oct 2003 19:14:11 -0400

>certain kinds of tunneling man-in-the-middle attacks.
The "security" is specific to the SASL encryption and integrity 
protection; not authentication.  Clearly, SASL authentication might be 
used to help detect a man-in-the-middle attack.  If you are arguing that 
SASL encryption/integrity protection should be used on top of TLS 
encryption/integrity protection, the only reason for doing so is that 
you do not trust the TLS encryption/integrity protection.  I do not see 
where the man-in-the-middle attack would be coming from?

>established lower level (IPSEC or TLS) identity information).
Rules 5 and 6 are specific to the use of SASL mechanisms which are 
actively providing encryption/integrity protection.  In this situation, 
it is known that TLS is not in use.  I doubt it is known whether or not 
IPSec is in use for the entire communication path.  Therefore, all 
information obtained prior to the establishment of encryption/integrity 
protection must be considered suspect.

I believe the problem is one of language.  Can we replace all references 
to "security layer" to read "data protection layer"?

>services which TLS provides.

I agree.  We are not concerned with Stream Encryption but Data 
Protection.  Replace "Stream Encryption" with "Data Protection" throughout.

I have not completed a security review of these documents as yet.  I am 
simply responding to Kurt's comments.

Jeffrey Altman

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 09 Oct 2003 03:41:49 -0700

>Could you describe some of them?

XMPP's TLS profile allows establishment of TLS even though the
implementation's certificate verification has failed:
  If the above methods fail, the certificate SHOULD be presented
  to a human (e.g., an end user or server administrator) for
  approval; if presented, the receiver MUST deliver the entire
  certificate chain to the human, who SHOULD be given the option
  to store the Root CA certificate (not the service or End Entity
  certificate) and to not be queried again regarding acceptance of
  the certificate for some reasonable period of time.

Given the likelihood that the end user will inappropriately
accept the certificate, attackers can easily insert a
TLS-protected machine in the middle.  Given this, it is quite
reasonable for implementors to offer (and deployers to demand)
additional safeguards.

Kurt

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 08 Oct 2003 19:37:37 -0400

>reasonable for implementors to offer (and deployers to demand)
If the policy requirement of the deployers is to not accept the risk
that the end user will accept certificate chains which cannot be verified
by algorithmic means, then the policy should fail the certificate validation
without presenting the certificates to the end user.  The TLS session at
that point must be aborted.  At this point the TCP session must be closed.

When XMPP attempts to reconnect, it must not attempt to establish a TLS 
session
and in turn must attempt to negotiate a SASL mechanism which provides
encryption/integrity protection. 

There is zero benefit to negotiating both TLS and SASL encryption/integrity
protection.

Btw, if it is possible for SASL to validate the TLS Client and Server 
Finished
messages as computed by both the client and server, this can be 
performed during
SASL authentication to detect a man-in-the-middle attack.  This is the 
process
which is used in TELNET START-TLS when combined with TELNET AUTH. 

Jeffrey Altman

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Oct 2003 17:24:30 -0700

At 04:37 PM 10/8/2003, Jeffrey Altman wrote:
>by algorithmic means,

The policy might be to mitigate the risk that users won't do the
appropriate checks by requiring an additional layer of security.

>There is zero benefit to negotiating both TLS and SASL encryption/integrity

I disagree.  Multiple layer defenses have benefits.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Oct 2003 20:47:49 -0400

Do we actually need to have this argument here?  I tend to agree with
Kurt but it's not clear that having this discussion will actually
influence the draft.

Jeff, do you see anything wrong with allowing a SASL security layer
and TLS to be used in conjunction?  If I'm reading your argument
right, you have not actually presented any argument against this
configuration, you have just argued that Kurt's reason for wanting to
do so is not correct.

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 8 Oct 2003 20:40:43 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eric Rescorla
> Sent: Wednesday, October 08, 2003 1:28 PM
> To: [email-masked]
> Cc: [email-masked]; SASL WG
> Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
> 
> 
> 
> > I concur with Alexey's recent comments regarding XMPP's 
> SASL Profile.  
> > I have a few addition concerns regarding this profile. The 
> scope of my 
> > review was, due to time constraints, was limited to the profile.
> > 
> > I not sure why the documents says that SASL and TLS security layers 
> > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), 
> but this 
> > recommendation is, I believe, flawed.  There are numerous use cases 
> > where implementations SHOULD establish additional layers. 
> For example, 
> > establishing additional SASL layers may prevent certain kinds of 
> > tunneling man-in-the-middle attacks.

If the TLS tunnel is only server authenticated and the client supports a
particular SASL method (perhaps even in a different protocol)that
provides mutual authentication both inside and outside a TLS tunnel
there is a vulnerability.  In this case if only the message protection
of TLS is used you cannot be sure that the client endpoint of the TLS
tunnel is the same client endpoint that the server authenticated with
SASL.  

To mitigate this problem you can: 

- Use the protection from the inner SASL method
- Have the SASL authentication mechanism authenticate the TLS Session ID
or some similar parameter 
- Require different credentials be used by a SASL mechanism when
operating inside or outside a TLS tunnel.   

Joe

---

From: Eric Rescorla <[email-masked]>
Date: 08 Oct 2003 21:20:35 -0700

> tunnel is the same client endpoint that the server authenticated with

How's that again? Please explain the network topology you're considering
here.

-Ekr

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Oct 2003 01:10:06 -0400

Joseph Salowey wrote:

>
>Ok. I might be misunderstanding something, here is a summary:
>
>A client C that is willing to use SASL mechanism X both inside and
>outside a TLS tunnel.
>A server S that supports a server authenticated TLS tunnel and then
>authenticates the client using SASL mechanism X within the tunnel.
>An attacker M who can act as a TLS client and a SASL server for
>mechanism X.
>
>The network topology/deployment must allow for M to trick C into trying
>to authenticate to him using SASL Mechanism X (without TLS) while M
>simultaneously establishes a TLS connection with S. 
>
>M establishes a TLS session with S 
>M tricks C into trying to authenticate to him using SASL mechanism X
>without TLS protection (these first steps could happen in the reverse
>order)
>M forwards the SASL exchange from C to S and vice versa.  
>The SASL authentication will succeed and S will believe that the
>endpoint of the TLS tunnel is C instead of M (For some mechanisms M may
>have to spoof S's address in order for the authentication to complete).
>M can disconnect from C and continue sending messages to S.  
>S thinks the messages from M originate from C. 
>
>Joe
> 
>  
>
As far as I am aware, the endpoints negotiating the TLS tunnel are 
identical to
endpoints negotiating SASL.  Both TLS and SASL are negotiated as part of 
the
same connect/accept operation.

Jeffrey Altman

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 8 Oct 2003 21:53:32 -0700

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Wednesday, October 08, 2003 9:21 PM
> To: Joseph Salowey
> Cc: [email-masked]; [email-masked]; 'SASL WG'
> > > > layers
> > If the TLS tunnel is only server authenticated and the 
> client supports 
> > a particular SASL method (perhaps even in a different protocol)that 
> How's that again? Please explain the network topology you're 
> considering here.
> 

Joe

---

From: Eric Rescorla <[email-masked]>
Date: 08 Oct 2003 22:16:31 -0700

> S thinks the messages from M originate from C. 

Yes, this will work. But here's the thing:

This only works if the client would have been prepared to do this weak
mechanism over a non-TLS connection.  Generally the client knows when
it expects to do TLS and when it doesn't. 

-Ekr

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 8 Oct 2003 22:19:47 -0700

> Sent: Wednesday, October 08, 2003 10:17 PM
> To: Joseph Salowey
> > outside a TLS tunnel. A server S that supports a server 
> authenticated 
> > TLS tunnel and then authenticates the client using SASL mechanism X 
> > within the tunnel. An attacker M who can act as a TLS client and a 
> > SASL server for mechanism X.
> > 
> > The network topology/deployment must allow for M to trick C into 
> > trying to authenticate to him using SASL Mechanism X (without TLS) 
> > while M simultaneously establishes a TLS connection with S.
> > 
> This only works if the client would have been prepared to do 
> this weak mechanism over a non-TLS connection.  Generally the 
> client knows when it expects to do TLS and when it doesn't. 
> 

Agreed.  If the client only uses this mechanism over TLS then this is
not a problem. How easy this is to enforce depends upon the deployment
environment, it may be reasonable to assume for XMPP (I'm not very
familiar with XMPP).  I'm not completely sure, but with some mechanisms
using the same mechanism without TLS in a different protocol may lead to
the same problem (If the mechanism does not authenticate the
protocol/service context).  

Joe

---

From: Philip Guenther <[email-masked]>
Date: Wed, 08 Oct 2003 23:22:20 -0700

...
>protocol/service context).  

For those who don't watch the ietf-announce list or didn't have
their interest perked by the announcement, a discussion of this
problem in the context of EAP can be found in:

http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt

            The Compound Authentication Binding Problem
...
Abstract

There are several motivations for using compound authentication methods
using tunnels, but man-in-the-middle attacks are possible in certain 
circumstances when they are used, without cryptographically binding the 
methods together. At the time of writing this document, several 
protocols being proposed within the IETF are vulnerable to these 
attacks, including IKE with XAUTH, PIC, PANA over TLS, EAP TTLS and 
PEAP. This document studies the problems and suggests potential 
solutions to mitigate them.

(I have nothing to do with this document; it just seems extremely
relevant and fairly thorough on the point under discussion.  Perhaps
SASL over TLS should be added to the list in the quoted abstract?)

Philip Guenther
[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 09 Oct 2003 11:35:29 +0100

Jeffrey Altman wrote:

> actively providing encryption/integrity protection.  In this 
> situation, it is known that TLS is not in use. I doubt it is known 
> whether or not IPSec is in use for the entire communication path.  
> Therefore, all information obtained prior to the establishment of 
> encryption/integrity protection must be considered suspect.
>
> I believe the problem is one of language.  Can we replace all 
> references to "security layer" to read "data protection layer"? 

"security layer" is a SASL term, so changing it to something else will 
cause additional confusion.

Alexey

Cell: +44 7753759732

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Oct 2003 08:04:30 -0700

> operating inside or outside a TLS tunnel.   

Why does this sound really familiar?  Ah, because one solution is to
"bind" one layer (SASL) to the key exchange and negotiation of the other
(TLS) to prove that there's no MITM at the lower layer (TLS) - which, of
course, relies on an MITM's inability to make the key exchange/nego look
the same on both side of the lower layer channel.

In the GSS-API we call this channel bindings.  Perhaps SASL should have

The second solution you give is an attempt at doing just this sort of
binding.

Unfortunately, a TLS MITM can make the TLS session ID be the same on
both sides of the tunnel - that's because in TLS the server assigns the
session ID which, in turn, is not bound or required to be bound in any
way to the TLS key exchange / negotiation.  So you can't use TLS session
IDs as channel bindings.

Cheers,

Nico
--

---

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 9 Oct 2003 08:37:37 -0700

> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Thursday, October 09, 2003 8:05 AM
> To: Joseph Salowey
> Cc: 'EKR'; [email-masked]; [email-masked]; 'SASL WG'
> Subject: SASL channel bindings (was Re: [xmppwg] Last Call: 
> 'XMPP Core' to Proposed Standard)
> 
> 
> > - Have the SASL authentication mechanism authenticate the 
> TLS Session 
> > ID or some similar parameter
> Why does this sound really familiar?  Ah, because one 
> solution is to "bind" one layer (SASL) to the key exchange 
> and negotiation of the other
> (TLS) to prove that there's no MITM at the lower layer (TLS) 
> - which, of course, relies on an MITM's inability to make the 
> key exchange/nego look the same on both side of the lower 
> layer channel.

[Joe] Yes, this is all too familiar

> The second solution you give is an attempt at doing just this 
> sort of binding.
> 
> Unfortunately, a TLS MITM can make the TLS session ID be the 
> same on both sides of the tunnel - that's because in TLS the 
> server assigns the session ID which, in turn, is not bound or 
> required to be bound in any way to the TLS key exchange / 
> negotiation.  So you can't use TLS session IDs as channel bindings.
> 
[Joe] Yes, I agree the Session ID is probably not the best choice
(although in would probably work in the case outlined, it will fail if
the attacker can trick the client into accepting it as a valid TLS
endpoint, but this is a different problem).  

In any case SASL might benefit from channel bindings, although one has
to be careful with channel bindings (for example binding to addresses
tends to cause problems).  Maybe it is possible to temporarily turn on
SASL integrity services to authenticate binding information.  I don't
think that SASL intends for the security layer to be removed after it
starts, but I didn't find a place in the draft where it explicitly
forbids it.  If it is allowed then applications which negotiate TLS can
use this binding technique.

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Oct 2003 11:44:10 -0400

>way to the TLS key exchange / negotiation.  So you can't use TLS session

The channel binding would be made utilizing the TLS Client and Server 
Finished Messages.  If both the client and server concatenate those 
messages in a well defined order, they can then attempt to verify that 
both the client and server have the same bytes.  This is how TELNET AUTH 
binds to TLS when STARTTLS is used.  The benefit of this is that we 
would get mutual authentication from SASL which would allow TLS to be 
used in anonymous-DH mode completely removing the need to have or 
validate X.509 certificates.

Unfortunately, SASL does not have this functionality at the current 
time.  I very much think it should.  If it did, this entire discussion 
of the use of SASL Security Layers on top of TLS could just go away.

I completely understand why the SASL folks want to be able to use a SASL 
Security Layer on top of TLS when they do not have the ability to bind 
to lower layers.  Unfortunately, if SASL Security Layers are always to 
be used then I believe that TLS should never be negotiated.  To do so 
adds nothing to the strength of the security of the session, increases 
the complexity, wastes CPU cycles, and spreads FUD regarding the 
trustworthiness of TLS.  The lack of trust is not caused by TLS, but by 
the inability of SASL to verify a previously known shared secret between 
two parties.

Jeffrey Altman

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Oct 2003 09:14:55 -0700

On Thu, Oct 09, 2003 at 08:37:37AM -0700, Joseph Salowey wrote:

Nico> Why does this sound really familiar?  Ah, because one solution is
Nico> to "bind" one layer (SASL) to the key exchange and negotiation of
Nico> the other (TLS) to prove that there's no MITM at the lower layer
Nico> (TLS) - which, of course, relies on an MITM's inability to make
Nico> the key exchange/nego look the same on both side of the lower
Nico> layer channel.

> [Joe] Yes, this is all too familiar
Nico> In the GSS-API we call this channel bindings.  Perhaps SASL should
Nico> have

[I meant to say "Perhaps SASL should have a channel bindings facility."]

Nico> Unfortunately, a TLS MITM can make the TLS session ID be the same
Nico> on both sides of the tunnel - that's because in TLS the server
Nico> assigns the session ID which, in turn, is not bound or required to
Nico> be bound in any way to the TLS key exchange / negotiation.  So you
Nico> can't use TLS session IDs as channel bindings.

> use this binding technique.

It's probably not possible to add a channel bindings facility to SASL at
this point, but it should be possible to describe how applications
should do channel binding with SASL, more or less as you describe.

And as you point out, the traditional use of GSS-API channel bindings to
bind to network addresses causes problems, and, I might add, isn't
really secure.

Therefore we need to generally address channel bindings for the channels
one might like to bind to:

 - What to use as channel bindings for SSHv2?

   Easy, the SSHv2 session ID!

 - What to use as channel bindings for TLS?

   TLS defines no suitable value.  So one may have to be constructed
   (e.g., hash of all TLS session setup messages).

 - What to use as channel bindings for IKEv1 IPsec?

   Don't.  IKEv1 rekeying isn't like SSHv2 rekeying - there's no binding
   to the previous or original IKE_SA - so that when the IKE_SA expires
   so do the bindings.

 - What to use as channel bindings for IKEv2 IPsec?

   IKEv2 rekeying does bind the new SA to the previous one, so binding
   to IPsec SAs negotiated with IKEv2 is ok, but we need to define the
   what to use as the channel bindings.

   I've asked the IPSEC WG to define a value for use as channel
   bindings, but so far they are ignoring me.

   Ultimately, the same octets of which signatures are exchanged in the
   AUTH part of the IKEv2 exchange (see section 2.15 of the IKEv2 draft)
   can be used as channel bindings, or, rather, a hash thereof.

 - What to use as channel bindings for Kerberos V-protected tunnels?

   Again, nothing useful for this is provided in RFC1510.  But who wants
   this?  :)  Still something could be defined (e.g., a hash of the AP
   exchange messages).

 - What to use as channel bindings for GSS-API-protected tunnels?

   Same thing.  I'd propose: the ret_flags of the context and a hash of
   the byte-wise concatenation of the context tokens used to initialize
   the context, in order.

 - What to use as channel bindings for SASL-protected tunnels?

   Again, same thing...

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Oct 2003 09:25:07 -0700

> validate X.509 certificates.

Yeah - I offer as much in the post I just followed up with.

This sort of thing is extremely valuable.  The NFSv4 WG is quite
interested in channel bindings as a way to offload session cryptographic
protection from RPCSEC_GSS/GSS-API to IPsec and others.

See:

http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt

(The I-D will be updated soon, I hope, and will include much improved
 text about binding to IKEv2 IPsec transport-mode IKE_SAs, as well
 nonces and an additional 1/2 round-trip for the CCM-* pseudo-
 mechanisms' context tokens so as to make their context tokens
 un-replayable independently of the underlying, real mechanisms'
 context tokens' replayability.)

> of the use of SASL Security Layers on top of TLS could just go away.

The discussion of what to use as channel bindings to TLS would still
have to be had, though you point out that TELNET already solves that
particular problem in a way that others could leverage.  But that still
leaves other channels to discuss (e.g., IPsec) - see my other followup
to Joe.

> the inability of SASL to verify a previously known shared secret between 

I agree.  But note that SASL doesn't have to "verify a previously ..." -
it just has to verify a value, public or not, that could not be made the
same for both parties by an MITM at the lower layer.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Oct 2003 18:38:03 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Oct 08, 2003 at 08:40:43PM -0700, Joseph Salowey
    Nicolas> wrote:
    >> If the TLS tunnel is only server authenticated and the client
    >> supports a particular SASL method (perhaps even in a different
    >> protocol)that provides mutual authentication both inside and
    >> outside a TLS tunnel there is a vulnerability.  In this case if
    >> only the message protection of TLS is used you cannot be sure
    >> that the client endpoint of the TLS tunnel is the same client
    >> endpoint that the server authenticated with SASL.
    >> 
    >> - Use the protection from the inner SASL method - Have the SASL
    >> authentication mechanism authenticate the TLS Session ID or
    >> some similar parameter - Require different credentials be used
    >> by a SASL mechanism when operating inside or outside a TLS
    >> tunnel.

    Nicolas> Why does this sound really familiar?  Ah, because one
    Nicolas> solution is to "bind" one layer (SASL) to the key
    Nicolas> exchange and negotiation of the other (TLS) to prove that
    Nicolas> there's no MITM at the lower layer (TLS) - which, of
    Nicolas> course, relies on an MITM's inability to make the key
    Nicolas> exchange/nego look the same on both side of the lower
    Nicolas> layer channel.

    Nicolas> In the GSS-API we call this channel bindings.  Perhaps
    Nicolas> SASL should have

I wish SASL had this feature a lot.  It's clearly out of scope for
both the XMPP working group and for the SASL working group.

---

From: Eric Rescorla <[email-masked]>
Date: 08 Oct 2003 22:16:31 -0700

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/
_______________________________________________
xmppwg mailing list
[email-masked]
http://jabber.org/cgi-bin/mailman/listinfo/xmppwg

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 20:31:34 +0100

Regards,
Alexey

Cell: +44 7753759732

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 07 Oct 2003 22:49:33 +0100

1).

2).

3).

5).

6).

<response/> element.   

7).

Cheers,
Alexey

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 8 Oct 2003 12:40:46 -0500

Peter

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Oct 2003 22:56:38 -0700

To the IESG,

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 8 Oct 2003 14:24:40 -0400 (EDT)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 20:10:23 +0100

Regards,
Alexey

Cell: +44 7753759732

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 20:31:34 +0100

Regards,
Alexey

Cell: +44 7753759732

---

From: Eric Rescorla <[email-masked]>
Date: 08 Oct 2003 13:28:14 -0700

-Ekr

---

From: Tony Hansen <[email-masked]>
Date: Wed, 08 Oct 2003 16:52:59 -0400

Tony Hansen
	[email-masked]

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 08 Oct 2003 19:14:11 -0400

Jeffrey Altman

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 09 Oct 2003 03:41:49 -0700

Kurt

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 08 Oct 2003 19:37:37 -0400

Jeffrey Altman

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Oct 2003 17:24:30 -0700

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Oct 2003 20:47:49 -0400

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 8 Oct 2003 20:40:43 -0700

Joe

---

From: Eric Rescorla <[email-masked]>
Date: 08 Oct 2003 21:20:35 -0700

-Ekr

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Oct 2003 01:10:06 -0400

Jeffrey Altman

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 8 Oct 2003 21:53:32 -0700

Joe

---

From: Eric Rescorla <[email-masked]>
Date: 08 Oct 2003 22:16:31 -0700

-Ekr

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 8 Oct 2003 22:19:47 -0700

Joe

---

From: Philip Guenther <[email-masked]>
Date: Wed, 08 Oct 2003 23:22:20 -0700

...

Philip Guenther
[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 09 Oct 2003 11:35:29 +0100

Alexey

Cell: +44 7753759732

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Oct 2003 08:04:30 -0700

Cheers,

Nico
--

---

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 9 Oct 2003 08:37:37 -0700

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Oct 2003 11:44:10 -0400

Jeffrey Altman

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Oct 2003 09:14:55 -0700

Again, same thing...

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Oct 2003 09:25:07 -0700

See:

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Oct 2003 18:38:03 -0400

---

From: Eric Rescorla <[email-masked]>
Date: 08 Oct 2003 22:16:31 -0700

-Ekr

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 20:31:34 +0100

Regards,
Alexey

Cell: +44 7753759732