Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

[Alexey Melnikov]

Hi,

On 09/02/2017 08:58, Evgeny Khramtsov wrote:


Thu, 9 Feb 2017 08:40:49 +
Dave Cridland  wrote:


3) 

I still do not understand, what's the point in sending
=?
In the case of SASL EXTERNAL empty initial response has a special 
meaning, so it has to be encoded differently from absent initial response.


Initial SASL response was not in the original SASL specification, so it 
was added later. So some clients (possibly using older SASL libraries) 
would never emit it. The server can't know whether the client doesn't 
support initial response, so it has to respond to absent initial 
response with an empty string.


Best Regards,
Alexey

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A new SASL Profile strawman

[Alexey Melnikov]

On 04/05/2016 22:58, Peter Saint-Andre wrote:

On 5/4/16 8:00 AM, Dave Cridland wrote:

Folks,

I had a nice chat with Ralph Meijer, and we idly discussed replacing the
SASL profile in order to gain access to 2FA, fold in the Stream
Resumption (Florian Schmaus's design, in effect), and make it a little
more extensible, particularly with more detailed error messaging.

Since then I've found some fo these might be being addressed by work
Adam Roach and Matthew Miller are doing,


Got a pointer to that work?

Doing this work (eventually) at the IETF might make the most sense, 
but what makes even more sense is making sure that implementers are on 
board with whatever approach we come up with.

+1.

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: I-D Action: draft-saintandre-jabberid-09.txt

[Alexey Melnikov]

On 23/09/2013 17:32, Peter Saint-Andre wrote:

On 9/23/13 10:03 AM, Dave Cridland wrote:

On Mon, Sep 23, 2013 at 4:50 PM, Peter Saint-Andre
stpe...@stpeter.im mailto:stpe...@stpeter.im wrote:


Many header fields include [CWFS] (folding whitespace with
optional comments) instead of [FWS]. For simplicity of parsing
I would avoid using these, unless needed. But if you choose to
use [CFWS], that would still be fine.

Personally I see no need to allow comments. Keep it simple.


Comments are traditional. Besides, we don't want just anyone able
to write a parser, so we?

Seriously, comments aren't much of a bother to deal with unless
they're in the (like this) middle of something else you're trying
to parse, but on the other hand they rarely add value.

Right. But if they're traditional, what is the traditional syntax to
handle them? ;-)


[CFWS] is what you use if you want comment. At least this way there 
are plenty of parsers available for them.

Re: [Standards] Fwd: I-D Action: draft-saintandre-jabberid-09.txt

[Alexey Melnikov]

On 21/09/2013 03:34, Peter Saint-Andre wrote:

To my chagrin, I just realized that this header field is in fact registered:

http://www.iana.org/assignments/message-headers/message-headers.xhtml#prov-headers

It's been so long since I looked into this issue that I must have forgotten.

However, I do plan to get an RFC published so that there is stable
documentation for the Jabber-ID header field.

Hi Peter,
Some comments on -10:

Your ABNF in Section 2:

  Jabber-ID = SP *WSP pathxmpp *WSP CRLF

And your example in at the end of 3.2 is:

   Following the rules in [RFC5122] and the Jabber-ID header field
   syntax, the resulting header field might be as shown below (note that
   this representation includes folding white space, which is allowed in
   accordance with the ABNF):

  Jabber-ID:
 ji%C5%99i@%C4%8Dechy.example

I think this doesn't match your ABNF I think the ABNF should be:

  Jabber-ID = SP [FWS] pathxmpp [FWS] CRLF

For your convenience, the definition of FWS is quoted below:

   FWS =   ([*WSP CRLF] 1*WSP) /  obs-FWS
  ; Folding white space

I would also make the leading SP optional. While Netnews spec decide to make 
this explicit, software should cope with the lack of it. (But I don't feel 
strongly about the leading SP, most software always insert it anyway.)

Best Regards,
Alexey

Re: [Standards] Fwd: I-D Action: draft-saintandre-jabberid-09.txt

[Alexey Melnikov]

On 23/09/2013 15:45, Peter Saint-Andre wrote:

On 9/23/13 7:21 AM, Alexey Melnikov wrote:

On 21/09/2013 03:34, Peter Saint-Andre wrote:

To my chagrin, I just realized that this header field is in fact
registered:

http://www.iana.org/assignments/message-headers/message-headers.xhtml#prov-headers

It's been so long since I looked into this issue that I must have

forgotten.

However, I do plan to get an RFC published so that there is
stable documentation for the Jabber-ID header field.

Hi Peter, Some comments on -10:

Hi Alexey,

Hi Peter,

Thanks for the feedback. When I submitted this I-D to the ISE, I said
that you'd be a potential reviewer. It seems I was right. :-)


Your ABNF in Section 2:

Jabber-ID = SP *WSP pathxmpp *WSP CRLF

And your example in at the end of 3.2 is:

Following the rules in [RFC5122] and the Jabber-ID header field
syntax, the resulting header field might be as shown below (note
that this representation includes folding white space, which is
allowed in accordance with the ABNF):

Jabber-ID: ji%C5%99i@%C4%8Dechy.example

I think this doesn't match your ABNF I think the ABNF should be:

Jabber-ID = SP [FWS] pathxmpp [FWS] CRLF

Thanks for the correction. Do most of the header field definitions
allow folding white space?
Yes, but there are some inconsistencies in whether they are allowed at 
the end of the value.


Many header fields include [CWFS] (folding whitespace with optional 
comments) instead of [FWS]. For simplicity of parsing I would avoid 
using these, unless needed. But if you choose to use [CFWS], that would 
still be fine.



I was trying to make it consistent with
general practices, but I admit that I last looked at this almost 6
years ago. I'll check some of the header fields that are registered
with IANA.

Re: [Standards] Fwd: I-D Action: draft-saintandre-jabberid-09.txt

[Alexey Melnikov]

On 23/09/2013 16:50, Peter Saint-Andre wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/23/13 9:16 AM, Alexey Melnikov wrote:

On 23/09/2013 15:45, Peter Saint-Andre wrote:

On 9/23/13 7:21 AM, Alexey Melnikov wrote:

On 21/09/2013 03:34, Peter Saint-Andre wrote:

To my chagrin, I just realized that this header field is in
fact registered:

http://www.iana.org/assignments/message-headers/message-headers.xhtml#prov-headers


It's been so long since I looked into this issue that I must have

forgotten.

However, I do plan to get an RFC published so that there is
stable documentation for the Jabber-ID header field.

Hi Peter, Some comments on -10:

Hi Alexey,

Hi Peter,

Thanks for the feedback. When I submitted this I-D to the ISE, I
said that you'd be a potential reviewer. It seems I was right.
:-)


Your ABNF in Section 2:

Jabber-ID = SP *WSP pathxmpp *WSP CRLF

And your example in at the end of 3.2 is:

Following the rules in [RFC5122] and the Jabber-ID header
field syntax, the resulting header field might be as shown
below (note that this representation includes folding white
space, which is allowed in accordance with the ABNF):

Jabber-ID: ji%C5%99i@%C4%8Dechy.example

I think this doesn't match your ABNF I think the ABNF should
be:

Jabber-ID = SP [FWS] pathxmpp [FWS] CRLF

Thanks for the correction. Do most of the header field
definitions allow folding white space?

Yes, but there are some inconsistencies in whether they are allowed
at the end of the value.

FWS at the end doesn't sound like a great idea.


Many header fields include [CWFS] (folding whitespace with
optional comments) instead of [FWS]. For simplicity of parsing I
would avoid using these, unless needed. But if you choose to use
[CFWS], that would still be fine.

Personally I see no need to allow comments. Keep it simple.

So I suggest:

Jabber-ID = Jabber-ID: [SP] [FWS] pathxmpp CRLF

I even wonder about the FWS...

Strictly speaking not necessary. But I would actually do

Jabber-ID = Jabber-ID: [FWS] pathxmpp CRLF


because SP is allowed by FWS and FWS is more generic anyway.

Re: [Standards] jabber-id email header

[Alexey Melnikov]

On 20 Sep 2013, at 16:12, Peter Saint-Andre stpe...@stpeter.im wrote:

 On 9/20/13 8:25 AM, Alexey Melnikov wrote:
 On 20/09/2013 03:44, Peter Saint-Andre wrote:
 
 Back in 2007 we defined an email header for advertising your
 Jabber ID in your email messages:
 
 http://tools.ietf.org/id/draft-saintandre-jabberid-08.txt
 
 For various reasons we never got this header registered with
 IANA, but on re-reading RFC 3864 I've concluded that we could add
 it to the provisional register through a XEP instead of an RFC.
 Can you do an Independent submission to RFC Editor? You already
 have a draft...
 
 Now that I think about it, I might resurrect this as an I-D and get it
 published as an RFC. I last pursued this back in 2007 when everyone
 (well, some influential people at the IETF) thought that the world
 would switch to using 'im:' and 'pres:' URIs. That hasn't exactly
 happened. :-)

Indeed.
And I remember some people who didn't like the idea.

Re: [Standards] jabber-id email header

[Alexey Melnikov]

On 20/09/2013 03:44, Peter Saint-Andre wrote:


Back in 2007 we defined an email header for advertising your Jabber ID
in your email messages:

http://tools.ietf.org/id/draft-saintandre-jabberid-08.txt

For various reasons we never got this header registered with IANA, but
on re-reading RFC 3864 I've concluded that we could add it to the
provisional register through a XEP instead of an RFC.
Can you do an Independent submission to RFC Editor? You already have a 
draft...

Is there still interest in registering this header?

Yes yes yes :-).

Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)

[Alexey Melnikov]

On 13/06/2013 12:35, Ralph Meijer wrote:

On 2013-06-13 09:06, Philipp Hancke wrote:

[..]
The use of trickle might be interesting... basically that would be the
example from
http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00#section-4 


(note that m-line-id should be mid there)


Please, do not copy examples, but create new ones. There might be 
legal issues.
Why are you saying this? I thought copying examples from RFC or IETF 
drafts is fine.

Re: [Standards] Login with OpenID

[Alexey Melnikov]

On 03/09/2012 17:58, Randy Turner wrote:

Looked at this draft, and it is based on traditional OpenID and GSS-API (an API 
I've never been a fan of :)


You don't need to implement or use GSS-API in order to implement the RFC.


I'm wondering is something more API/REST-friendly like a solution based on 
OpenID Connect might be more attractive…

http://openid.net/connect

Randy


On Sep 3, 2012, at 3:24 AM, Peter Saint-Andre wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/2/12 12:35 PM, Ivan Martinez wrote:

Hello all, I'm thiking of making it possible to log into my XMPP
server with OpenID accounts. Is there any existing standard about
this?. I have seen the discussion from June 2009:

http://mail.jabber.org/pipermail/jdev/2009-June/thread.html#87693

Peter talked about working in a new draft, how did it turn out?.

Some other folks worked on that, and it turned into RFC 6616:

https://datatracker.ietf.org/doc/rfc6616/

It was published only a few months ago, so probably it is not yet
widely implemented in SASL libraries or in XMPP servers and clients.

Peter

- -- 
Peter Saint-Andre

https://stpeter.im/

Re: [Standards] [Summit] FOSDEM Friday

[Alexey Melnikov]

Kurt Zeilenga wrote:


On Dec 20, 2010, at 5:49 AM, Kevin Smith wrote:

 


Hi all,
As Board kindly volunteered me to arrange the agenda for the Friday
before FOSDEM, what would people like to do? (Replies to the summit
list please).

Suggestions have been a coding sprint, some interop testing, or an
extension of the discussions of Monday.
   



I'm available for anyone who wants to do XEP 258 testing.  Also for 
spec/implementation discussion/work on DSIGs, object level encryption, key 
management, or anything in the general XMPP authentication, authorization, 
object/stream security areas.
 

And I would be available for testing SCRAM (and SASL in general), 
including channel bindings; talking and testing IDNA2008 / stringprep 
related stuff.

[Standards] Request for review: IETF vcardxml

[Alexey Melnikov]

I hope people don't mind me asking for review of IETF drafts here.

IETF VcardDAV Working Group is working on XML mapping for vcard. This is 
replacement for XEP-0054 (vcard-temp). I would appreciate if people can 
have a look at the draft and let me know if it seems reasonabel. The 
draft can be found here:


http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-01

Thank you,
Alexey

Re: [Standards] Request for review: IETF vcardxml

[Alexey Melnikov]

Peter Saint-Andre wrote:


On 11/22/09 11:05 AM, Alexey Melnikov wrote:
 


I hope people don't mind me asking for review of IETF drafts here.
   


Not at all.
 


Good, I have authorization from the boss ;-).


IETF VcardDAV Working Group is working on XML mapping for vcard. This is
replacement for XEP-0054 (vcard-temp). I would appreciate if people can
have a look at the draft and let me know if it seems reasonabel. The
draft can be found here:

http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-01
   


I would dearly like to deprecate XEP-0054, because vcard-temp has been
temp for almost 10 years now! I think draft-ietf-vcarddav-vcardxml is
not quite a replacement for XEP-0054 because it doesn't cover the XMPP
aspects (how to upload, modify, and retrieve vCards over XMPP) and it is
missing a few fields that we use (especially JabberID).

I can't promise that that would happen, but I think adding JabberID to 
the base vcardxml spec would be useful.



So I think we
need to complete a gap analysis and define how we would map vcard-temp
to an XMPP extension that reuses draft-ietf-vcarddav-vcardxml.
 

Re: [Standards] XEP-0175 v. 1.2rc1

[Alexey Melnikov]

Eloi Bail wrote:


Hi,

Indeed this draft provides more detailed information. It's great :)


I like the new text on ANONYMOUS as well.

I think it would be useful to make a similar draft for PLAIN method, 
the core xmpp RFC only explaining the digest-md5 method.


I think we need to be careful about describing handling of each SASL 
mechanism, as this defeats the purpose of having generic SASL libraries 
that support multiple authentication mechanisms.


While I agree that ANONYMOUS and PLAIN are a bit special, we need to 
have a criteria on which mechanisms should deserve own XEPs. If there 
are issues with how some SASL mechanisms are described, which are not 
specific to XMPP, then the IETF SASL WG needs to be notified.

Re: [Standards] LAST CALL: XEP-0198 (Stream Management)

[Alexey Melnikov]

Peter Saint-Andre wrote:


The sender does not have to wait for an ack to continue sending
stanzas. Because acks indicate stanza acceptance, a server that is
throttling stanzas MUST delay the response until the client is no
longer being penalized (but SHOULD notify the client that it is
throttling incoming stanzas, as described under Throttling
imap://stpe...@mailhost.dizzyd.com:993/fetch%3EUID%3E.INBOX%3E152686?header=quotebodypart=1.1.3filename=xep-0198.html).
 


In Section 5:
   


Definition: The 'id' attribute defines a unique identifier for
purposes of stream management (an SM-ID). The SM-ID MUST be
generated by the receiving entity (server). The initiating entity MUST
consider the SM-ID to be opaque and therefore MUST NOT assign any
semantic meaning to the SM-ID. The receiving entity MAY encode any
information it deems useful into the SM-ID, such as the full JID
localp...@domain.tld/resource of a connected client (e.g., the full
JID plus a nonce value). Any characters allowed in an XML attribute
are allowed. The SM-ID MUST NOT be reused for simultaneous or
subsequent sessions (as long as the receiving entity is available).
 


I am not sure I understand the comment in (). Should it read as long as
the session is available?
 
   


No, in practice it means that as long as the server does not crash the
server MUST ensure that SM-IDs are unique, but if it crashes then it
doesn't need to keep track of every SM-ID it has ever generated.

 


Right. This makes more sense. I suggest you either expand the sentence,
and/or avoid using the word available for the receiving entity.
   



In the previous revision I modified it to read:

The SM-ID MUST NOT be reused for simultaneous or subsequent sessions
(but the server need not ensure that SM-IDs are unique for all time,
only for as long as the server is continuously running).
 


This is better, thanks.

When a session is resumed, the parties SHOULD proceed as follows: 
 


I suggest removing SHOULD here, as all items below it are already
SHOULDs.
   


OK, that's better.
 


  * Both parties SHOULD retransmit any stanzas that were not handled
during the previous session, based on the sequence number
reported by the peer.
   
 


Why is this just a SHOULD?
 
   


I suppose the client might have returned an error to the user and the
user might decide not to retransmit.

 


Ok.
It might be worth mentioning this example.
   



I had previously (in 0.10) adjusted the wording slightly here:

A user-oriented client SHOULD try to silently resend the stanzas upon
reconnection or inform the user of the failure via appropriate
user-interface elements.
 


This looks better, thanks.


In Section 8.1:
 
   


Example 16. Client sends a stanza and requests acknowledgement
C: iq id='ls72g593' type='get'
   query xmlns='jabber:iq:roster'/
 /iq

C: r xmlns='urn:xmpp:sm:2'/
 


What should be the h value from the server below if iq and r are
exchanged?
 
   


You didn't answer my question :-).
   


Increment h for each stanza handled.

Yes, but I am talking about a corner case when the other end didn't 
handle any stanzas yet.

What is the value of h in such case?


I fixed the examples to make sure
that they all are consistent with that rule.
 

Re: [Standards] reliable messaging

[Alexey Melnikov]

Peter Saint-Andre wrote:


3. I agree with Nyco that so-called whitespace pings are really
keepalives, and I'll adjust the 3920bis text accordingly. These
keepalives help to figure out if a stream is idle (especially in the
absence of stream management).
 

While I agree, SIP also has whitespace pings and they aren't called 
keep alives.

Re: [Standards] reliable messaging

[Alexey Melnikov]

Alexey Melnikov wrote:


Peter Saint-Andre wrote:


3. I agree with Nyco that so-called whitespace pings are really
keepalives, and I'll adjust the 3920bis text accordingly. These
keepalives help to figure out if a stream is idle (especially in the
absence of stream management).


While I agree, SIP also has whitespace pings and they aren't called 
keep alives.


Actually never mind, I've misremembered what 
draft-ietf-sip-outbound-20.txt said.

Re: [Standards] LAST CALL: XEP-0198 (Stream Management)

[Alexey Melnikov]

Peter Saint-Andre wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/11/09 4:30 PM, Alexey Melnikov wrote:

 


HTML version, section 4 reads:
   


Note: The value of 'h' starts at zero for the first stanza handled and
is incremented with each subsequent stanza handled. In the unlikely
case that the number of stanzas handled during a stream management
session exceeds the number of digits that can be represented by the
unsignedInt datatype as specified in XML Schema Part 2
http://www.w3.org/TR/xmlschema-2/ [9
imap://stpe...@mailhost.dizzyd.com:993/fetch%3EUID%3E.INBOX%3E152686?header=quotebodypart=1.1.2filename=xep-0198.html]
(i.e., 232), the value of 'h' shall be reset from 232-1 back to zero
(rather than being incremented to 232).
 


I think 232 is 2**32, but it doesn't look this way.
   



What browser do you use? The superscript shows up in Firefox 3 and
Safari 4 on my machine, but I have not tested this on all platforms.


Older Mozilla on Windows.


In Section 4:
   


When an r/ element (request) is received, the recipient MUST
acknowledge it by sending an a/ element to the sender containing a
value of 'h' that is equal to the number of stanzas handled by the
recipient of the r/ element. The response SHOULD be sent as soon as
possible after receiving the r/ element, and MUST NOT be withheld
for any condition other than a timeout. For example, a client with a
slow connection might want to collect many stanzas over a period of
time before acking, and a server might want to throttle incoming stanzas.
 

Are these example of things that conform to the last SHOULD?



Yes...
 


For a moment I thought they were examples demonstrating MUST NOT :-).
I don't know if you can improve the text though.


The sender does not have to wait for an ack to continue sending
stanzas. Because acks indicate stanza acceptance, a server that is
throttling stanzas MUST delay the response until the client is no
longer being penalized (but SHOULD notify the client that it is
throttling incoming stanzas, as described under Throttling
imap://stpe...@mailhost.dizzyd.com:993/fetch%3EUID%3E.INBOX%3E152686?header=quotebodypart=1.1.3filename=xep-0198.html).
 


In Section 5:
   


Definition: The 'id' attribute defines a unique identifier for
purposes of stream management (an SM-ID). The SM-ID MUST be
generated by the receiving entity (server). The initiating entity MUST
consider the SM-ID to be opaque and therefore MUST NOT assign any
semantic meaning to the SM-ID. The receiving entity MAY encode any
information it deems useful into the SM-ID, such as the full JID
localp...@domain.tld/resource of a connected client (e.g., the full
JID plus a nonce value). Any characters allowed in an XML attribute
are allowed. The SM-ID MUST NOT be reused for simultaneous or
subsequent sessions (as long as the receiving entity is available).
 



 


I am not sure I understand the comment in (). Should it read as long as
the session is available?
   



No, in practice it means that as long as the server does not crash the
server MUST ensure that SM-IDs are unique, but if it crashes then it
doesn't need to keep track of every SM-ID it has ever generated.
 

Right. This makes more sense. I suggest you either expand the sentence, 
and/or avoid using the word available for the receiving entity.


When a session is resumed, the parties SHOULD proceed as follows:  


I suggest removing SHOULD here, as all items below it are already SHOULDs.
   



OK, that's better.

 


   * Both parties SHOULD retransmit any stanzas that were not handled
 during the previous session, based on the sequence number
 reported by the peer.
 


Why is this just a SHOULD?
   



I suppose the client might have returned an error to the user and the
user might decide not to retransmit.


Ok.
It might be worth mentioning this example.


In Section 8.1:
   


Example 16. Client sends a stanza and requests acknowledgement
C: iq id='ls72g593' type='get'
query xmlns='jabber:iq:roster'/
  /iq

C: r xmlns='urn:xmpp:sm:2'/
 
 


What should be the h value from the server below if iq and r are
exchanged?
   


You didn't answer my question :-).


The server immediately sends an a/ element to acknowledge handling
of the stanza and then returns the roster.

Example 17. Server acknowledges handling of client stanza and sends a
stanza

S: a xmlns='urn:xmpp:sm:2' h='0'/
 



Oops, that should be h=1 (two stanzas handled by the server).

No, I think h='0' is correct. The value starts with 0 for the first 
acknowledged stanza.

And my undestanding is that rs and as are not counted.



 

Re: [Standards] PubSub Security considerations

[Alexey Melnikov]

Ralph Meijer wrote:


On Thu, 2009-06-11 at 19:20 -0400, Brian Cully wrote:
 

On Jun 11, 2009, at 11:31, Nicolas Vérité nicolas.ver...@process-one.n 
et wrote:
   


Dear all,

In the Security considerations section of the PubSub spec, shouldn't
we warn of the possible presence leaks, since subscribers (possibly
not in the user's roster) are instantly notified of a user's
publication?
 


Agreed. This is a subtle condition and should probably be called out.
   


I think it is a lot more subtle than summarized here.

First off, the basic model of XEP-0060 is that there are nodes at some
service and items get published to it by publishers. Subscribers to
nodes get notifications on every publish, and the notifications do not
expose which entity published that item. Basically, this means that a
notification does not definitively expose an entity's availability, and
not even their existence.

Going further, notifications do not even imply explicit publish actions,
but items could merely start to exist from within a system or by some
out-of-band protocol, and cause a notification to be sent out.

Second, XEP-0060 does not depend on XMPP IM, so entities do not
necessarily represent people.

Third, we explicitly started developing a publish-subscribe protocol
because we consider information like the music somebody is playing on
their desktop, or an entity's location are orthogonal to availability.

Fourth, nodes themselves are not necessarily tied to a particular
entity. In Personal Eventing (XEP-0163), of course, this is a bit
different, because nodes are then tied to a entity's (person's?) user
account. So here the existence of a user is exposed. I suppose this is a
moot point because to discover such nodes, the existence of that user
would already need to be exposed via some other means.

But even then, a notification does not necessarily expose an entity's
availability. The actual publisher could still be another entity (e.g.
FireEagle publishing a location to your own XEP-0080 node).

And finally, whether a particular notification exposes someone's
availability highly depends on the semantics of the node and/or payload
of the item being published.

I think the only summary for a security consideration that covers all
the above is 'use your common sense'. Since this in general is a good
advice, I propose we don't add that to this specification, or any other
for that matter.
 


Ralph,
I think you explanation is very good and I actually suggest it is added 
to the security consideration.

Re: [Standards] LAST CALL: XEP-0198 (Stream Management)

[Alexey Melnikov]

One more comment:

In Section 3:

The enable/ element MAY include a 'max' attribute to specify the 
initiating entity's preferred maximum resumption time.


This doesn't say what is the unit of measurement. And I can't find this 
elsewhere.

Re: [Standards] LAST CALL: XEP-0198 (Stream Management)

[Alexey Melnikov]

My appologies for sending multipart/alternative with text/html. I didn't 
think it would be 138Kb.

Re: [Standards] secure s2s multiplexing

[Alexey Melnikov]

Philipp Hancke wrote:


Peter Saint-Andre wrote:


Joe Hildebrand and I have started working on an Internet-Draft that
describes at least the requirements and possibly proposed solutions to
the challenge of securely multiplexing multiple domains over the same
XML stream.



Btw, could you remove the other usage of 'multiplex' from RFC 3921bis?


The deployment scenario we have in mind is for a hosting provider or
application service provider to service multiple domains on the same
machine or machines. With the increasing popularity of so-called cloud
computing, some of these providers service thousands of domains (e.g.,
Google Apps). Because RFC 3920 specifies that each domain-to-domain
link shall use two XML streams (one in each direction) and because
currently XMPP has no method by which an existing stream can be re-used
for additional domains, establishing connectivity between two XMPP



The 'd' word.


clouds can quickly necessitate a large number of TCP connections. This
is true even if the clouds have authenticated to each other using TLS
and SASL with digital certificates issued by trusted roots. Therefore we
think it would be desirable to define a method by which two XMPP clouds
could optionally multiplex communications between themselves, so that an
existing domain-to-domain stream could be re-used for additional 
domains.


We see the following requirements:

* The multiplexing method must be backwards-compatible with existing
server-to-server connection methods.
* Each party to a server-to-server communication must be able to
determine if the other party supports multiplexing.


unidirectional or bidirectional s2s for this? For bidi we need a
reverse-stream:features feature anyway.


I think this should make the stream bidirectional.


* If the addition of a new domain to an existing domain-to-domain
stream fails, the existing stream must not be terminated.


if the addition of a new domain to an existing stream fails, is it
allowed to retry after x minutes?


Sure, why not.


* Multiplexing shall depend on presentation of a valid digital
certificate for the multiplexed domain.

* The certificate for a multiplexed domain should not be the same
(i.e., have the same subject) as a certificate that has previously been
accepted for the stream; however, if it is the same then it shall
replace the previous certificate with the same subject (e.g., to present
a new certificate with a different expiry time).


PSA: I am not sure why this is a requirement. I think this is a part of 
the solution you and Joe have in mind.



* When a multiplexed domain is accepted for the stream, each name on
the certificate (e.g., id-on-dnsSRV or id-on-xmppAddr) becomes valid for
the stream.


This could be nasty with wildcard certificates. Explicit negotiation or
no wildcards?


Good question!


* The protocol used accept the initial certificate for a stream may
be different from the protocol used to accept subsequent (multiplexed)
domains for the stream.


You're mixing up 'certificate' and 'domain'.
* The protocol used [to] exchange(?) the certificate for the initial
  domain on(?) a stream may be different from the protocol to exchange
  the certificates for subsequent (multiplexed) domains on the stream.


Right.


* The process of adding a subsequent domain shall not affect
transmission of application data over the stream.

* If the stream is resumed, all of the certificates that were
accepted for the previous session apply to the resumed session.



Hmm, Ok.


* It is a security violation to proceed with transmission of
application data between two domains if multiplexing for those domains
failed (however, this does not affect domains that have already been
accepted for the stream).


I think it is ok to kill the stream.


Agreed.


Is that list accurate and complete?


looks good.


Looks good to me too.

Re: [Standards] SASL digest-uri issues

[Alexey Melnikov]

Jack Moffitt wrote:


So RFC 2831 says:

digest-uri-value  = serv-type / host [ / serv-name ]

and RFC 3920 does not seem to specify anything else.

Implementations seem to expect xmpp/DOMAIN whre DOMAIN is the domain
part of the JID.

One reading of 2831 might lead one to implement something like:
xmpp/talk.google.com/gmail.com

This is actually bad news, because BOSH clients will not be able to
get this extra SRV information, unless the connection manager returns
it somehow.

Should we add some language to 3920bis to lock this down so that we
don't have implementations that are incapable of BOSH?
 


I agree with Kurt's comment about replacing DIGEST-MD5 with something else.

However, regarding the specific issue you've reported:
I've made DIGEST-MD5 plugin in Cyrus SASL implementation ignore the [/ 
serv-name] part of such URIs. So the full digest-uri-value should be 
used for hashing, but only part of it should be used for verification.

Re: [Standards] UPDATED: XEP-0257 (Client Certificate Management for SASL EXTERNAL)

[Alexey Melnikov]

XMPP Extensions Editor wrote:


Version 0.2 of XEP-0257 (Client Certificate Management for SASL EXTERNAL) has 
been released.

Abstract: This specification defines a method to manage client certificates 
that can be used with SASL External to allow clients to log in without a 
password.

Changelog: [See revision history] (dm)

Diff: 
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0257.xml?%40diffMode=u%40diffWrap=sr1=2598r2=2730u=3ignore=k=

URL: http://www.xmpp.org/extensions/xep-0257.html
 


This looks better. Some quick comments:

1). Semantics of disabling is not quite clear. In particular, are 
disabled certificates still returned in response to the list request? If 
they are returned, then you need a way to mark them somehow in the list 
response. If they are not returned, then it would be better to call this 
operation deletion.


2). In Section 3 the following text was added:

If the subjectAltName contains a full JID the server MUST force the 
client to use the given resource during resource binding. The client 
is only allowed to use the provided resource name. If a client with 
the same resource name is currently logged in and that client is not 
forced to use that resource name, it SHOULD be logged out by the server.


I am not entirely sure what this text is trying to achieve.

However this brings an interesting question: if the uploaded certificate 
has a JID in the subjectAltName, then I think the JID MUST correspond to 
the user's account for which it was uploaded.

Re: [Standards] UPDATED: XEP-0257 (Client Certificate Management for SASL EXTERNAL)

[Alexey Melnikov]

Peter Saint-Andre wrote:


Alexey Melnikov wrote:
 


2). In Section 3 the following text was added:
   


If the subjectAltName contains a full JID the server MUST force the
client to use the given resource during resource binding. The client
is only allowed to use the provided resource name. If a client with
the same resource name is currently logged in and that client is not
forced to use that resource name, it SHOULD be logged out by the server.
 


I am not entirely sure what this text is trying to achieve.
   

Even after Peter's clarification, I don't think I understand what the 
last sentence is saying.

In particular why that client is not forced to use that resource name?


As I understand it from talking with Dirk at the XMPP Summit, this text
is trying to achieve lockdown of resource identifiers. So for instance I
could say that the full JID for a certificate is m...@myserver.tld/TV
(my set-top box) and another is m...@myserver.tld/DVR (my digital video
recorder) or whatever. My DVR can't log in as my TV and my TV can't log
in as my DVR. You could think of these as user accounts with few
permissions, whereas an admin account could log in as any of those
resources. But probably Dirk can explain it more accurately.
 


I think some text like what you describe would make the document better.


However this brings an interesting question: if the uploaded certificate
has a JID in the subjectAltName, then I think the JID MUST correspond to
the user's account for which it was uploaded.
   


Certainly.
 


I think this statement is missing.

Re: [Standards] XEP readability

[Alexey Melnikov]

Peter Saint-Andre wrote:


Dirk Meyer wrote:
 


Dirk Meyer wrote:
   


Peter Saint-Andre wrote:
 


Some members of the XMPP Council commented recently that the front
matter (author info, legal notices, etc.) in existing XEPs is quite
lengthy. Therefore I have modified the XSLT to move almost all of that
information to appendices. All of the XEPs have been regenerated to 
use this new format:


http://xmpp.org/extensions/

Let me know what you think.
   


Better, but I would not move all metadata to the end. Comparing it to an
RFC, I would move Appendix A (dependencies and version), B (who wrote
that stuff), D (not important, but it should be at the top IMHO), and F
(it is necessary to read the XEP) back to the top.
 


Then we haven't really improved anything. :)
 

I would suggest moving Appendix F: Requirements Conformance and possibly 
Appendix A: Document Information to the front.
I am neutral about location of Appendix D: Relation to XMPP and Appendix 
B: Author Information.


On an unrelated note: why is it Appendix G: Notes instead of Appendix 
G: References?

Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL

[Alexey Melnikov]

Dirk Meyer wrote:


Alexey Melnikov wrote:
 


This is quite sensible reminds me of an older IETF effort called
SACRED (see RFC 3767 and friends).
   


Hello BEEP :)
 


Indeed :-).


Thanks for the pointer, I will take a look at it to see if something
useful for us is in it.
 


Good.


I've scanned the document and have some quick comments/questions:
   


Example 4. Client revokes an X.509 Certificate

iq type='get'
  from='[EMAIL PROTECTED]/denmark'
  id='revoke'
revoke xmlns='urn:xmpp:tmp:saslcert'/
  item id='428b1358a286430f628da23fb33ddaf6e474f5c5'
compromised/
 


Where is compromised defined?
   


It is part of urn:xmpp:tmp:saslcert (or will be once I write the
schema).


Ok. Please also describe purpose of various revocation reasons in prose.


The problem is that there are two reason to revoke a
certificate:
 


Yes, I understand that having different revocation reasons is important.


1. A certificate is about to expire. The client uploads a new one and
  revokes the old. The client should stay connected.

2. A device should be removed (e.g. stolen). In that case the
  certificate is compromised and if the device is logged in right now,
  it should be disconnected by the server.

I will write some more doc about this.
 


Thanks.

Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL

[Alexey Melnikov]

Dirk Meyer wrote:


I have an additional question: do you think this is a useful?
 

I can see value in using password to authenticate once and then creating 
a stronger credential (certificate).


And your proposal is simpler than possible alternatives because it 
doesn't require dealing with CSR, etc.

Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL

[Alexey Melnikov]

Dirk Meyer wrote:


Philipp Hancke wrote:
 


And it results in a certificate signed by an entity that the server
trusts.
   


Well, the server can trust the client with its own certificate. But you
raise an interessting point: what do others think? CSR or the other
way. Alexey already wrote that he prevers not to deal with CSR.
 

I don't mind doing CSR and turning XMPP server into a full CA ;-), but I 
think your idea is simpler, so it would be easier to deploy.

Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL

[Alexey Melnikov]

XMPP Extensions Editor wrote:


The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Client Certificate Management for SASL EXTERNAL

Abstract: This specification defines a method to manage client certificates 
that can be used with SASL External to allow clients to log in without a 
password.

URL: http://www.xmpp.org/extensions/inbox/sasl-external-cert-handling.html

The XMPP Council will decide at its next meeting whether to accept this 
proposal as an official XEP.

This is quite sensible reminds me of an older IETF effort called SACRED 
(see RFC 3767 and friends).


I've scanned the document and have some quick comments/questions:


Example 4. Client revokes an X.509 Certificate

iq type='get'
   from='[EMAIL PROTECTED]/denmark'
   id='revoke'
 revoke xmlns='urn:xmpp:tmp:saslcert'/
   item id='428b1358a286430f628da23fb33ddaf6e474f5c5'
 compromised/
 


Where is compromised defined?


   /item
 /revoke
/iq
 


[...]



3. SASL EXTERNAL

The protocol flow is similar to the one described in XEP-0178. Only 
step 9 is different: the certificate does not need to be signed by a 
trusted entity if the certificate was uploaded by the user. The server 
still MUST reject the certificate if it is expired. The client 
certificate SHOULD include a JID as defined in sections 15.2.1.2. and 
15.2.1.3. in rfc3920bis: a JID MUST be represented as an XmppAddr, 
i.e., as a UTF8String within an otherName entity inside the 
subjectAltName.


I assume this proposal doesn't prevent use of properly certificates 
signed by a CA, which were not uploaded?




4. Security Considerations

I think this XEP-to-be should REQUIRE at least use of TLS integrity 
protection and/or SASL security layer with integrity protection.
Without that any man-in-the-middle that can inject data into a TCP 
stream can upload arbitrary certificates (for which he/she has the 
private key), so effectively giving himself/herself full access to the 
account.

Re: [Standards] LAST CALL: XEP-0224 (Attention)

[Alexey Melnikov]

Peter Saint-Andre wrote:


This Last Call has ended, with no feedback received.
 

The document seems to be in reasonable shape, in particular it talks 
about cases when this extension should and should not be used.

One comment about the Security Considerations section:

It is RECOMMENDED that only message stanzas containing attention 
extensions from peers on the user's roster are accepted. Finer grained 
control might be implemented.


IMHO, this is not a proper security consideration, as it doesn't explain 
the reason behind using RECOMMENDED.

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Alexey Melnikov]

Dave Cridland wrote:


urn:xmpp:protoname:1

That last portion we'll treat as a version number. Any time we cause  
incompatibility between versions of the XEP, we update it. (Note,  
that's not every new XEP).


So by the time it moves out of Experimental and to Draft, it might be:

urn:xmpp:protoname:4

And there it stays - the advantage here is that if the protocol is  
stable earlier than its move to Draft - and actually, this is  
normally the case, a lot of the pre-draft stuff is specification  
wrangling rather than proptocol redesign - people can go ahead and  
implement it, and it'll continue to work.


Not surprisingly I like that, as Curtis and I were complaining to Dave 
about this before.

Re: [Standards] LAST CALL: XEP-0136 (Message Archiving)

[Alexey Melnikov]

Hi Peter,
Most of your changes look good to me, so I didn't include them in my 
reply. Some additional comments below.


Peter Saint-Andre wrote:

Alexey Melnikov wrote: 


[...]


2.6 Setting Archiving Method Preferences
Example 12. Client Sets Method Preferences
iq type='set' id='pref4'
pref xmlns='urn:xmpp:tmp:archive'
method type='auto' use='concede'/
method type='local' use='forbid'/
method type='manual' use='prefer'/
/pref
/iq 
 


This section doesn't describe if it is Ok for the client to only modify
one archiving type at a time (.e.g. if pref contains just one
method) and if not, what should be the error response
   



In fact that section doesn't include any text whatsoever!

I think that (1) it's fine for the client to set only one or two method
preferences, (2) the server must not modify any unset preferences, and
(3) the push must include all the prefs, not just those set by the
client.


This looks reasonable to me.

3.1 OTR Negotiation  


[...]
   


Note: A client MUST NOT propose or agree to enable OTR (i.e., disallow
message logging)
unless it has confirmed that its server will allow it to switch off
Automated Archiving.
 


An example of how this can be done (or a reference to a section
describing how this can be done) would be helpful here.


Hmm. AFAICT, the client needs to figure this out based on the rules in
Section 5.1. So if you log in and don't receive a warning message, you
can assume that automatic archiving is not on by default (yes, I hear
the objections already: but message delivery is not reliable so you
might not receive the warning message!). If you do receive a warning
message because automatic archiving is on by default, the only way to
determine if it can be turned off is to try. If you receive an error as
described in SEction 5.2 then you know that automatic archiving cannot
be turned off.

That seems rather messy.

Yes. But if you want to keep current behavior, I think you should give 
an example.



See also below.
 


[...]

In section 4.2:


Note: The content of message/ elements that have different thread
IDs SHOULD be archived in separate collections.
 

Is this a requirement on the client or on the server? 
   

I think it is a client requirement.  


Then don't use passive voice, e.g.

Note: The client SHOULD archive the content of message/ elements that have 
different thread
IDs in separate collections.


If this is a
requirement on the server, than an example demonstrating what the server
should do if it finds a message/ with non matching tread ID.


I suppose a server could try to enforce this rule to save the client
from its own stupidity, but I don't see that it's necessary.

If you want to allow a server to validate this, you should list an 
appropriate error response.



5.1 Toggling Auto-Archiving
If server administration policies require that every message is logged
automatically (see Security Considerations) then:
• The server MUST enable automatic archiving when each stream is opened.
• Clients MUST NOT be allowed to disable automatic archiving.
• Automatic archiving MUST NOT be subject to users' Archiving
Preferences.
 


I don't think the last requirement is entirely clear. How is this
different from the previous requirement?
   



I think we don't need the third bullet.


Good :-).


5.2 Not-Implemented Responses
The server MUST return a feature-not-implemented/ error in the
following cases: 



I think these should be distinct error cases. I would suggest the
following...

 


• If the client is trying to enable automatic archiving, but the
server does not allow the saving of full message stanza content, and
the user has specified the 'message' Save Mode in one of its Archiving
Preferences.
 



feature-not-implemented/

 


• If administrator policies require that every message is logged
automatically, and the client is trying to disable automatic archiving.  



not-acceptable/

 


• If the client is trying to enable encryption, but the server does
not support encryption 
 



also feature-not-implemented/

 


or the user did not specify a public key and is
not publishing any keys using XEP-0189.
 



not-allowed/
 


I like that.


The last listed case (user didn't specify a public key) is not
not-implemented. This is a distinct error condition and another error
code should be used, if possible.
   



Thus:

**

5. Automatic Archiving
 


[...]


If service policies require that every message is logged automatically,
the server MUST return a not-acceptable/ error. 

Your example below uses not-allowed/. I think not-acceptable/ is a 
cut and paste error.



Example 35. Automatic Archiving is Compulsory

iq type='error' id='auto3'
 error type='cancel'
   not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/
 /error
/iq

Re: [Standards] LAST CALL: XEP-0136 (Message Archiving)

[Alexey Melnikov]

XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on 
XEP-0136 (Message Archiving). Abstract: This document defines 
mechanisms and preferences for the archiving and retrieval of XMPP 
messages. URL: http://www.xmpp.org/extensions/xep-0136.html This Last 
Call begins today and shall end at the close of business on 
2008-04-18. Please consider the following questions during this Last 
Call and send your feedback to the standards@xmpp.org discussion list: 
1. Is this specification needed to fill gaps in the XMPP protocol 
stack or to clarify an existing protocol? 2. Does the specification 
solve the problem stated in the introduction and requirements? 3. Do 
you plan to implement this specification in your code? If not, why 
not? 4. Do you have any security concerns related to this 
specification? 5. Is the specification accurate and clearly written? 
Your feedback is appreciated!


In general I think the document is in a good shape. It contains some 
useful suggestions for implementors, which I like.


Below are my detailed comments from reviewing the document:

2.2.4 Method Element
Each method/ element specifies the the user's preferences for one
available archiving method. The method/ element MUST be empty
and MUST include both the 'type' and 'use' attributes. The pref/
element MUST include at least three method/ elements,
differentiated by the value of the 'type' attribute.

It took me several passes to figure out what this text is trying to say. 
Maybe it would be better to say that pref/ element MUST include 
method/ element for each type defined in section 2.2.4.2.



2.4 Setting Default Modes
[...]
The server MAY be configured to return a feature-not-implemented/ 
error in the following cases:
• If it does not allow the saving of full message stanza content, and 
the client set the value of the 'save'
attribute to 'message' or 'stream', and any of the user's connected 
resources have Automated Archiving enabled.
• If administrator policies require that at least the body/ elements 
(or the full content) of every message
are logged automatically, and the client sets the value of the 'save' 
attribute to 'false' (or 'body').


Should the second case return something other than 
feature-not-implemented/?
Examples show that changes to settings by a resource are pushed out to 
the resource that caused the change. Should this be optimized out?



2.6 Setting Archiving Method Preferences
Example 12. Client Sets Method Preferences
iq type='set' id='pref4'
pref xmlns='urn:xmpp:tmp:archive'
method type='auto' use='concede'/
method type='local' use='forbid'/
method type='manual' use='prefer'/
/pref
/iq 


This section doesn't describe if it is Ok for the client to only modify 
one archiving type at a time (.e.g. if pref contains just one 
method) and if not, what should be the error response



3.1 OTR Negotiation


[...]

Note: A client MUST NOT propose or agree to enable OTR (i.e., disallow 
message logging)
unless it has confirmed that its server will allow it to switch off 
Automated Archiving.


An example of how this can be done (or a reference to a section 
describing how this can be done) would be helpful here.



The following table shows what stanza session negotiation values
 the initating party (i.e., the user)

typo: initiating

should send for the 'logging' field in the initial data form for
a stanza session negotiation (note: 'may' means that the receiving
party MAY enable message logging and 'mustnot' means that
the receiving party MUST NOT enable logging).

While I think this sentence is correct, is it possible to simplify/split 
it into multiple, as it is hard to understand?



In section 4.2:

Note: The content of message/ elements that have different thread 
IDs SHOULD be archived in separate collections.


Is this a requirement on the client or on the server? If this is a 
requirement on the server, than an example demonstrating what the server 
should do if it finds a message/ with non matching tread ID.



4.6 Groupchat Messages
A client MAY archive messages that it receives from Multi-User Chat 
[8] rooms. The 'with' attribute MUST be the bare JID of the room. The 
client MUST include a 'name' attribute for each from/ element to 
specify the room nickname (and, if available, bare JID) of the message 
sender:


Before I saw the example, I misread this as the name attribute can 
contain either nickname and/or bare JID. Please clarify that any JID is 
recorded in the 'jid' attribute.



5.1 Toggling Auto-Archiving
If server administration policies require that every message is logged 
automatically (see Security Considerations) then:

• The server MUST enable automatic archiving when each stream is opened.
• Clients MUST NOT be allowed to disable automatic archiving.
• Automatic archiving MUST NOT be subject to users' Archiving 
Preferences.


I don't think the last requirement is entirely clear. How is this 
different from the previous requirement?

Re: [Standards] rfc3920bis: SASL fallback on auth failure

[Alexey Melnikov]

Justin Karneges wrote:


On Tuesday 25 March 2008 2:16 pm, Peter Saint-Andre wrote:
 


Evan Schoenberg of the Adium project pinged offlist regarding the proper
behavior for a client to follow if SASL authentication fails using one
mechanism but other mechanisms are available. I think a flow like the
following makes sense (I ran this by Alexey Melnikov and he concurred).

C: auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'=/auth

challenge + response etc.

S: failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
not-authorized/
  /failure

C: auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='PLAIN'/
   

The one trouble with this approach that I've discovered is that you can't 
easily reprompt for a password.  Suppose you have a client that doesn't save 
a password, and prompts on demand.  What should it do if DIGEST-MD5 returns 
not-authorized?


The client should try a reasonable number of retries with the same SASL 
mechanism.



The user could have just made a typo,


Indeed.

but instead we'll try 
some other mechanism?


The client needs to retry the same mechanism several times, then 
fallback to the next one, etc.


But this is a bit of oversimplification. There is one complication: some 
mechanisms require password to be asked directly from the user (e.g. 
DIGEST-MD5, CRAM-MD5, PLAIN), but others typically require the user to 
specify the password before launching the application (e.g. to obtain 
Kerberos ticket for GSSAPI). In the latter case there is no need to 
retry: either the client has a valid Kerberos ticket or it doesn't. 
However SASL APIs don't necessarily have a way of telling applications 
about differences between the two types of mechanisms described above.


Weird.  And we probably shouldn't prompt for the 
fallback mechanisms.


I guess the unfortunate solution is something like this:
 1) Try SASL mechs in some order.
 2) If one asks for a password, prompt, cache, and use a password.
 3) If another mech asks for a password, use the cached password.
 

If another mechanism asks for a password, it means that authentication 
using the previous mechanism failed.

So the client might as well ask for the password again.


 4) If all mechs fail, only then clear the password cache and start over.
 


Alexey pointed out that we probably need to specify some text like this:

  SASL mechanisms MUST be tried in the order of their strength as
  perceived by the client (assuming the client has this information).
  For example, if the server advertises PLAIN DIGEST-MD5 GSSAPI or
  DIGEST-MD5 GSSAPI PLAIN, the client should try GSSAPI first, then
  DIGEST-MD5, then PLAIN. The client should also be able to disallow
  some mechanisms (e.g. PLAIN).
   

Also, if using a SASL library, probably the best approach to ensuring the 
proper selection order is to remove the offending mechanism from the list and 
retry again using the reduced list.  Repeat until out of mechanisms.
 


Yes.

Re: [Standards] rfc3920bis: SASL fallback on auth failure

[Alexey Melnikov]

Justin Karneges wrote:


On Tuesday 25 March 2008 7:23 pm, Joe Hildebrand wrote:
 


Questions for the security folks:
- Does this lead to a potential downgrade attack?
   

Yes, an attacker could spoof an error reply by the server, so the client 
chooses a different mechanism.  For example, it could cause errors to occur 
for all mechanisms except PLAIN.  However, even without the mechanism 
fallback feature we are discussing, clients are still susceptible to a 
downgrade attack since the attacker can simply change the mechanism list 
offered by the server.  This is an even easier and more effective attack, 
since the attacker can add the PLAIN mechanism to the list if it is not 
present.
 


Indeed.

Clients using SASL libraries should be insulated from all downgrade attacks.  
Cyrus SASL, for example, will only ever choose mechanisms that match the 
selected security settings, so there's really nothing the client developer 
can do to screw this up.
 


Right.


- Does this require the use of a secure channel like TLS to prevent
downgrade attacks?
   

This is one way to solve it, although it does sort of pass the buck since TLS 
itself is vulnerable to very similar downgrade attacks 
(s/mechanisms/ciphersuites).  In the end, you need a minimum security level, 
whether it is at the TLS or SASL layer.
 


Very well said.


- If not, and we can use a negotiated security layer, what happens
when you try to switch to a SASL mechanism that doesn't support that
security layer?
   

If the client's minimum security level requires a security layer, then the 
client should never pick a mechanism that does not have one.
 

Exactly. The client should require some minimal security layer from TLS 
and/or SASL.

Re: [Standards] XMPP Certificate checking algorithm

[Alexey Melnikov]

Peter Saint-Andre wrote:


Shumon Huque wrote:
 


[...]

2. Look for expected server identity (either JID domain or 
  explicitly configured server hostname) in:


a. subjectAltName otherName field of type id-on-xmppAddr
   



But I think we deprecate this for servers, so at least it should go
after your (b).
 


This sounds reasonable.


b. subjectAltName dNSName field
c. subject DN's Common Name field
   



Do we really want to check the CN? It's been deprecated for years.

If you want to retain compatibility with other protocols like HTTP and 
SMTP, you should keep it.


As a side note, CN is the easiest thing to set with openssl tools.

Re: [Standards] Correction to 3290bis4

[Alexey Melnikov]

Peter Saint-Andre wrote:


Toly Menn wrote:
 


Also, section 7.3.4 indicates that the receiving end of the
connection SHOULD allow at least 2 and no more then 5 retries from
the abort.  Does this make sense for s2s connections?  EXTERNAL
mechanism?
   


That rule (which IIRC we borrowed from RFC 4422) may not make sense for
all SASL mechanisms or for s2s connections.


Agreed.


However, for c2s connections
it may make sense for SASL EXTERNAL because end users can have multiple
certificates (I know I do).

As a side note: how do you select a particular certificate using SASL 
EXTERNAL? Are you using different authorization identity in a hope that 
the server end will match it against the correct client certificate.