Subject: [xmpp] Agenda for the Interim Meeting

From: Ben Campbell <[email-masked]>
Date: Tue, 1 Feb 2011 09:11:41 -0600

Hi,

Here's the agenda for the interim meeting. Please send any comments, or requests for adjustment, to the list as soon as possible. Please remember the room is expected to be very full, so please let us know in advance if you have not already done so and plan to attend.

Thanks!

Ben.

-----------------------------------

Interim Meeting of the IETF XMPP Working Group, in conjunction with XMPP Summit 10.

Date and Time: Monday 7 February, 2011 from 1300-1630 CET

Location: Cisco Systems, Pegasus Park, De Kleetlaan 6, 1831 Diegem, Belgium (Brussels)

Agenda:

-- Status and Agenda Bashing: 10 minutes -- Chairs

-- Internationalization Issues: 120 minutes -- Peter

-- Domain Name Assertions:  30 minutes -- Richard

-- SASL preference ordering:  15 minutes -- Alexey and/or Peter

-- Handling namespace prefix rule violations: 15 Minutes -- Matthew and/or Peter

-- Open Discussion: Any remaining time and energy.							

Please note that the Internationalization topic has priority for this meeting. If we run out of time while having useful discussion, more time may be allocated at the expense of the other topics.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Feb 2011 08:22:13 -0700

Thanks, Ben! A few comments inline.

> -- Internationalization Issues: 120 minutes -- Peter

I've created slides for a tutorial on this topic, which I plan to
present on Friday at the "hackfest". I need to tweak the slides today
but will send them out before flying to Brussels tomorrow.

> -- Domain Name Assertions:  30 minutes -- Richard

Perhaps Richard or Joe could post about this. I'm hoping that they can
do some brainstorming around the topic with Jonas Lindberg before the
meeting on Monday.

> -- SASL preference ordering:  15 minutes -- Alexey and/or Peter

Alexey, could you post to the list about that issue?

> -- Handling namespace prefix rule violations: 15 Minutes -- Matthew

This is something that Matthew Wild and I discussed privately a few
weeks ago. I'll send a message to the list summarizing our discussion
and conclusions.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Feb 2011 13:31:09 -0700

> Alexey, could you post to the list about that issue?

I forgot that Alexey is offline most of this week, so I'll raise the issue.

Section 6.3.3 of 3920bis states:

   Any entity that will act as a SASL client or a SASL server MUST
   maintain an ordered list of its preferred SASL mechanisms according
   to the client or server, where the list is ordered according to local
   policy or user configuration (which SHOULD be in order of perceived
   strength to enable the strongest authentication possible).  The
   initiating entity MUST maintain its own preference order independent
   of the preference order of the receiving entity.  A server MUST offer
   and a client MUST try SASL mechanisms in preference order.  For
   example, if the server offers the ordered list "PLAIN SCRAM-SHA-1
   GSSAPI" or "SCRAM-SHA-1 GSSAPI PLAIN" but the client's ordered list
   is "GSSAPI SCRAM-SHA-1", the client MUST try GSSAPI first and then
   SCRAM-SHA-1 but MUST NOT try PLAIN (since PLAIN is not on its list).

Therefore XMPP mandates the presentation order of SASL mechanisms by the
application server. However, no other application protocols that re-use
SASL (e.g., IMAP) mandate such a thing.

Some people consider this a bug in XMPP (or so it seems -- I have not
been privy to their conversations, but I think they are on this list).
Others consider it a feature of XMPP, or an example of a protocol aspect
that XMPP specifies (because 3920bis is one of the most thorough
specifications in existence) despite the fact that other protocols do not.

I don't have strong feelings in the matter, and in any case I think the
server's preference order doesn't really matter because the client has
its own preference order, which it develops independently of the server.

I'd appreciate it if those who consider this a bug could make their
voices heard on the list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Feb 2011 13:53:25 -0700

> weeks ago. I'll send a message to the list summarizing our discussion

Matthew and I had a long off-list discussion about this several weeks
ago. At issue is this paragraph in Section 4.8.5 of 3920bis:

   An XMPP entity MUST NOT accept data that violates this rule (in
   particular, an XMPP server MUST NOT route or deliver such data to
   another entity); instead it MUST either ignore the data or close the
   stream with a stream error, which SHOULD be <bad-namespace-prefix/>
   (Section 4.9.3.2).

Matthew pointed out to me that some XMPP servers are able to accept such
data because they (or the XML parser they use) transform the prefixed
data into an unprefixed stanza based on the qualifying namespace. That
is, the server essentially corrects the violation, which means that the
paragraph as it stands probably violates Postel's Law ("be liberal in
what you accept and conservative in what you send").

After some back-and-forth with Matthew, I suggested the following paragraph:

   If an XMPP entity receives data that violates this rule, it MAY
   refuse to accept the data because the data is inconsistent with the
   prefixing context that the sending entity established when it sent
   the stream header for its outbound stream; i.e., the entity MAY
   either ignore the data or close the stream with a stream error,
   which SHOULD be <bad-namespace-prefix/>.  If an XMPP server accepts
   such data and routes or delivers the data over an output stream to
   another entity, then it MUST transform the data into a legitimate
   stanza whose prefixing context is the same as that of the output
   stream (e.g., an unprefixed stanza if a content namespace was
   declared as the default namespace for the output stream).

I know that Matthew still has concerns with that paragraph, so I will
let him post to the list in reply.

My major concern here is that the text about namespace prefixing is a
bit fragile and that I think we need more implementation and deployment
experience with prefix-free canonicalization at the stream level before
we can provide solid text here. That's why I suggested to Matthew that
we postpone dealing with this issue until we work on "3920ter" (i.e.,
the hopefully-small revisions to 3920bis). IMHO there are just too many
unknowns here, and we could have some very long mailing list threads (as
we have in the past) without coming to consensus at this time.

Furthermore, I remind you all of the obvious: 3920bis has been approved
for publication, so we need to make sure that any changes are,
preferably, editorial in nature or quite small in scope.

With that in mind, one small change we could make would be to change
MUST to SHOULD and MUST NOT to SHOULD NOT, plus add some clarifying
words to the parenthetical clause:

   An XMPP entity SHOULD NOT accept data that violates this rule (in
   particular, an XMPP server MUST NOT route or deliver such data to
   another entity without correcting the violation); instead it SHOULD
   either ignore the data or close the stream with a stream error,
   which SHOULD be <bad-namespace-prefix/> (Section 4.9.3.2).

This allows a server to be liberal in what it accepts, while mandating
that it needs to be conservative in what it sends to other entities even
if it accepts such data.

Personally, I think that's the best we're going to do right now, and
that we should revisit this topic when we revise 3920bis. But let's not
get into major surgery on 3920bis at this point, because the time for
that is past.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 01 Feb 2011 22:23:21 +0100

> specifications in existence) despite the fact that other protocols do not.

RFC 4422 may be useful to compare here, it says:

   3.2.  Mechanism Negotiation

   Mechanism negotiation is protocol specific.

   Commonly, a protocol will specify that the server advertises
   supported and available mechanisms to the client via some facility
   provided by the protocol, and the client will then select the "best"
   mechanism from this list that it supports and finds suitable.

I believe this speaks for itself, but I'm curious to learn about other
point of views.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Feb 2011 00:27:35 +0300

Simon Josefsson wrote:

>I believe this speaks for itself,
>  
>
Does it? The text you quoted doesn't prohibit or encourage server order.

>but I'm curious to learn about other point of views.
>  
>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 01 Feb 2011 22:32:52 +0100

> Does it? The text you quoted doesn't prohibit or encourage server order.

My interpretation is that the first sentence gives protocol designers
the leeway to do what XMPP is doing here.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Feb 2011 00:56:22 +0300

>the leeway to do what XMPP is doing here.
It does, but some people argue that considering that the client 
preferences always take precendence then a) server order is meaningless 
and b) it can encourage naive client implementation that would rely on 
it (which is an issue, because a man-in-the-middle attacker who can 
reorder mechanisms can trick clients into selecting something less 
secure). So there is a question of whether the server advertised order 
is actually harmful.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Feb 2011 19:01:49 -0700

> but will send them out before flying to Brussels tomorrow.

Because I don't like to use email as a file transfer method, I've
uploaded the slides here:

http://www.saint-andre.com/jabber/i18n-for-the-perplexed.pdf

The topic is complex, and folks could spend all their time between now
and Monday reading the references I've provided at the end of the slide
deck. Because I figure that very few people will do so, I've tried to
make the slides somewhat self-contained with regard to the major issues.

I intend to present these slides (or most of them) on Friday at the XMPP
"hackfest". I'll also put together a smaller set of more focused slides
for our decision-oriented discussion on Monday.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Feb 2011 19:02:28 -0700

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Waqas Hussain <[email-masked]>
Date: Wed, 2 Feb 2011 07:14:33 +0500

> voices heard on the list.

I didn't raise this issue, but here's how I see it:

1. Since the clients MUST use their own order, the server's ordering
is pointless. The text basically tells the initiating entity to not
use the receiving entity's ordering, and use it's own.
2. XMPP servers may not be able to order at all, if they use some
external SASL provider (which can have SASL mechanisms the server
doesn't understand). I realized that we don't order mechanisms when
using Cyrus SASL+saslauthd (optional external SASL library and auth
deamon) with Prosody, and don't understand some of the mechanisms
supported by Cyrus.

This mustn't be a MUST for the server :)

--
Waqas Hussain

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 02 Feb 2011 04:32:20 +0100

Alexey Melnikov <[email-masked]> writes:

> preferences always take precendence then a) server order is
> meaningless and b) it can encourage naive client implementation that
> would rely on it (which is an issue, because a man-in-the-middle
> attacker who can reorder mechanisms can trick clients into selecting
> something less secure). So there is a question of whether the server
> advertised order is actually harmful.

Ah, I understand, and agree it could cause confusion although it seems
like an implementation problem that would be easy to fix.  I merely
wanted to make it clear that this is not a "bug" from a SASL
specification point of view.

/Simon

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 2 Feb 2011 14:20:16 +0000

> specifications in existence) despite the fact that other protocols do not.

I don't understand why server provided order would matter to a client.  The client must maintain it's own preference and use that in selecting the mechanism ( though the text is not clear that this is a must.  s/a client MUST try SASL mechanisms in preference order/a client MUST try SASL mechanisms in its preference order/ would seem appropriate).

I don't understand how an implementation preference for which authentication exchanges are used first can be reasonably expressed by a simple ordering of the mechanisms names.   That is, if it my preference to have an exchange which results in sufficient protections against hijack attack, how this can be expressed simply by just listing mechanisms which are capable of such resulting in those protections first.  The client cannot be expected to be able to use all the capabilities of the mechanism, or to favor a particular selection of capabilities.  That is, where a server which lists a or b because they think a will result in a "stronger" session, but a client more capable of establishing "stronger" sessions with b than a, a weaker session results due to the suggestion that consider the server specified preference.

I generally think the server MUST is not implementable in that I don't think it possible to well order mechanisms by security strength.   Can you order the mechanisms listed at http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml by security strength?  Would the order be different with or with TLS?  Different depending on TLS cipher suite was in use?  Different depending on which capabilities negotiated in the mechanism are assumed to be used? 

It's been suggested to me (off list) that the server list is for clients which don't have there own means for selecting one mech over another.   I think what this text is trying to do is turn what was designed an interop solution into a security solution.   Mech nego was designed to allow a client and the server to nego a mechanism which they both support and for which mets both of their minimal security requirements.   It was never designed to, and even with the server preference order, won't result in the "strongest" exchange.

--  Kurt

Ps: i won't be able to respond much as I'm on the road.

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 2 Feb 2011 14:24:49 +0000

On Feb 1, 2011, at 9:56 PM, Alexey Melnikov <[email-masked]> wrote:

> It does, but some people argue that considering that the client preferences always take precendence then a) server order is meaningless and b) it can encourage naive client implementation that would rely on it (which is an issue, because a man-in-the-middle attacker who can reorder mechanisms can trick clients into selecting something less secure). So there is a question of whether the server advertised order is actually harmful.

I think the question is more "how does a server provided mech name ordering by preference help the client select the mechanism best meeting the client's requirements?"

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 02 Feb 2011 08:12:46 -0700

> I think the question is more "how does a server provided mech name ordering by preference help the client select the mechanism best meeting the client's requirements?"

I think we've established that it doesn't.

I suggest this...

from:

   A server MUST offer
   and a client MUST try SASL mechanisms in preference order.

to:

   A client MUST try SASL mechanisms in its preference order.

The rest of the paragraph can stay the same.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Matt Miller <[email-masked]>
Date: Wed, 2 Feb 2011 08:14:20 -0700

> The rest of the paragraph can stay the same.

Sounds good to me.  It's what I've done with all my client implementations/deployments anyway.

- m&m