Re: [Standards] IETF SASL WG meeting
On Tuesday 11 December 2007 9:15 am, Greg Hudson wrote: > On Mon, 2007-12-10 at 10:20 -0800, Justin Karneges wrote: > > I don't understand this talk about the SASL negotiation being attacked by > > a MITM when it is taking place over TLS. There is brief mention of Bob > > possibly not having a certificate or Alice not trusting Bob's CA. Does > > this mean the channel binding problem only affects > > anonymous/unauthenticated TLS? > > It strengthens your security properties in cases where you trust your > SASL authentication mechanism more than you trust the TLS authentication > mechanism. In that case, is it even relevant that TLS is used? If you trust SASL more than your underlying transport layer, then you negotiate your SASL security layer and be done with it. Is the idea that you should be able to bind to an underlying privacy layer if it is stronger than what SASL can provide? > If you trust TLS to authenticate the server to the client, then I > believe you can do client-to-server authentication without any form of > channel binding and you're fine. This makes sense to me. -Justin
Re: [Standards] Messages to unsubscribed contacts and resources
On Tuesday 11 December 2007 1:08 pm, Tomasz Sterna wrote: > On Wt, 2007-12-11 at 15:59 -0500, Greg Hudson wrote: > > It's not what clients do currently, though. I'm not sure whether it's > > wise to encourage such a fundamental change at this point. > > It's not a change... yet. > There are clients that do one, and others that do the other, by the > authors preference. > > RFC3921bis will be encouraging only one approach. And then it will be > hard to change it. It was decided long ago that replies should go to the full JID. It was even documented in RFC 3921 (see Section 4.1) from 2004. No need to bring the bis into this. This is absolutely fundamental Jabber behavior that has existed for as long as I've been involved (2001?). It's a "SHOULD", so you're probably free to deviate with the understanding that you're deviating. :) -Justin
Re: [Standards] Messages to unsubscribed contacts and resources
I also feel like bare jid sending would have better behavior in the presence of multiple client connections. I don't see why you wouldn't want your existing conversations to follow you when you switch from one device to another. I actually find it annoying beyond words to be logged in from two places at once, holding a conversation on one and then come back to find just half of the conversation sitting on the screen on the other. (AIM, I am looking at you.) It's not what clients do currently, though. I'm not sure whether it's wise to encourage such a fundamental change at this point. Why not just differentiate between type normal and type chat? Right now, most clients do not really differentiate anymore, and just handle everything as chat, so 'normal' is largely unused. Maybe we should have normal be recommended to always be sent to the bare-JID, and the server would deliver as appropriate (to all resources, or to the highest-priority, or whatever). Like e-mail, where you can read it from whatever client. Chat could then continue to use the current logic, which honestly makes more sense to me. -- Rachel Blackman <[EMAIL PROTECTED]> Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] Messages to unsubscribed contacts and resources
On Wt, 2007-12-11 at 15:59 -0500, Greg Hudson wrote: > It's not what clients do currently, though. I'm not sure whether it's > wise to encourage such a fundamental change at this point. It's not a change... yet. There are clients that do one, and others that do the other, by the authors preference. RFC3921bis will be encouraging only one approach. And then it will be hard to change it. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Messages to unsubscribed contacts and resources
I also feel like bare jid sending would have better behavior in the presence of multiple client connections. I don't see why you wouldn't want your existing conversations to follow you when you switch from one device to another. It's not what clients do currently, though. I'm not sure whether it's wise to encourage such a fundamental change at this point. On Tue, 2007-12-11 at 21:22 +0100, Tomasz Sterna wrote: > On Wt, 2007-12-11 at 13:10 -0700, Peter Saint-Andre wrote: > > Because that's what it means to be in a chat session with someone -- > > you have a FullJID-to-FullJID connection, as it were. > > This is kind of "it is like this, because it is like this" answer. > > And as Robin pointed "a chat session" is a very fuzzy "definition". > > I still se no advantage in this approach. > And Robin and I pointed a few advantages of bare JID messaging. > > > > And remember that these messages are not necessarily human-readable > > text. What if you're sending a file via In-Band Bytestreams? Does half > > the file go to one resource and half to another? Ick. > > Is a IBB a "chat session"? Really? > This makes "chat session" definition even more fuzzy... > > > And I have a feeling of deja-vu. > We had this talk before and IIRC concluded that bare JID messaging is > better and is what we should recommend it and discourage the existing > full JID binding. > > Instead, we documented the full JID binding in RFC3921bis and encourage > it even more... :-/ > >
Re: [Standards] Messages to unsubscribed contacts and resources
On Wt, 2007-12-11 at 13:10 -0700, Peter Saint-Andre wrote: > Because that's what it means to be in a chat session with someone -- > you have a FullJID-to-FullJID connection, as it were. This is kind of "it is like this, because it is like this" answer. And as Robin pointed "a chat session" is a very fuzzy "definition". I still se no advantage in this approach. And Robin and I pointed a few advantages of bare JID messaging. > And remember that these messages are not necessarily human-readable > text. What if you're sending a file via In-Band Bytestreams? Does half > the file go to one resource and half to another? Ick. Is a IBB a "chat session"? Really? This makes "chat session" definition even more fuzzy... And I have a feeling of deja-vu. We had this talk before and IIRC concluded that bare JID messaging is better and is what we should recommend it and discourage the existing full JID binding. Instead, we documented the full JID binding in RFC3921bis and encourage it even more... :-/ -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Messages to unsubscribed contacts and resources
Tomasz Sterna wrote: > On Wt, 2007-12-11 at 10:28 -0700, Peter Saint-Andre wrote: >> You should keep sending to the bare JID until you receive a reply from >> a full JID, then start sending to the full JID. > > What is the rationale for this behavior? > I mean, what advantage does it have over sticking to bare JID sending? Because that's what it means to be in a chat session with someone -- you have a FullJID-to-FullJID connection, as it were. And remember that these messages are not necessarily human-readable text. What if you're sending a file via In-Band Bytestreams? Does half the file go to one resource and half to another? Ick. I could write up some scenarios about this if people are really interested. And in any case I'll define it more precisely in the next version of rfc3921bis and then people can have something more stable to comment on. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Messages to unsubscribed contacts and resources
On Wt, 2007-12-11 at 10:28 -0700, Peter Saint-Andre wrote: > You should keep sending to the bare JID until you receive a reply from > a full JID, then start sending to the full JID. What is the rationale for this behavior? I mean, what advantage does it have over sticking to bare JID sending? -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
[Standards] Proposed XMPP Extension: Use of Domain-Based Service Names in XMPP SASL Negotiation
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Use of Domain-Based Service Names in XMPP SASL Negotiation Abstract: This document specifies a method by which a connection manager associated with an XMPP server can inform a connecting client about its domain-based service name. URL: http://www.xmpp.org/extensions/inbox/domain-based-names.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
Re: [Standards] IETF SASL WG meeting
Peter Saint-Andre wrote: This is an interesting discussion, but I'm wondering what changes we need to make (if any) in rfc3920bis to handle this. I can't think of any changes [yet] that needs to be done to rfc3920bis. This issue is relevant to SASL framework in general, so maybe it will be handled in rfc4422bis.
Re: [Standards] IETF SASL WG meeting
Alexey Melnikov wrote: > Greg Hudson wrote: > >> On Mon, 2007-12-10 at 10:20 -0800, Justin Karneges wrote: >> >> >>> I don't understand this talk about the SASL negotiation being >>> attacked by a MITM when it is taking place over TLS. There is brief >>> mention of Bob possibly not having a certificate or Alice not >>> trusting Bob's CA. Does this mean the channel binding problem only >>> affects anonymous/unauthenticated TLS? >>> >> It strengthens your security properties in cases where you trust your >> SASL authentication mechanism more than you trust the TLS authentication >> mechanism. >> >> > I would rephrase this to say: if authentication of the client to the > server happens in a different layer from authentication of the server to > the client, then channel bindings are needed. > >> If you trust TLS to authenticate the server to the client, then I >> believe you can do client-to-server authentication without any form of >> channel binding and you're fine. >> >> > Yes, mutual authentication at TLS layer + SASL EXTERNAL don't need any > channel bindings. This is an interesting discussion, but I'm wondering what changes we need to make (if any) in rfc3920bis to handle this. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] IETF SASL WG meeting
Greg Hudson wrote: On Mon, 2007-12-10 at 10:20 -0800, Justin Karneges wrote: I don't understand this talk about the SASL negotiation being attacked by a MITM when it is taking place over TLS. There is brief mention of Bob possibly not having a certificate or Alice not trusting Bob's CA. Does this mean the channel binding problem only affects anonymous/unauthenticated TLS? It strengthens your security properties in cases where you trust your SASL authentication mechanism more than you trust the TLS authentication mechanism. I would rephrase this to say: if authentication of the client to the server happens in a different layer from authentication of the server to the client, then channel bindings are needed. If you trust TLS to authenticate the server to the client, then I believe you can do client-to-server authentication without any form of channel binding and you're fine. Yes, mutual authentication at TLS layer + SASL EXTERNAL don't need any channel bindings.
Re: [Standards] Messages to unsubscribed contacts and resources
Robin Redeker wrote: > Hi! > > Some days ago I had a mail discussion on the jdev@ mailing list > about messages to unsubscribed contacts and contacts in general. > Tomasz said that messages should generally go to the bare JID instead of > the full JID, and that the local routing is up to the server. > > He meant, chat sessions should be kept track of with the > element, which completly makes sense to me. > > On the other side RFC3921bis says: > >Section 5.1.1: > >If the message is being sent in reply to a message previously >received from an address of the form <[EMAIL PROTECTED]/resource> (e.g., >within the context of a chat session), the value of the 'to' address >SHOULD be of the form <[EMAIL PROTECTED]/resource> rather than of the form ><[EMAIL PROTECTED]> unless the sender has knowledge (via presence) that the >intended recipient's resource is no longer available. > > That of course also makes sense, but my problem was: What if the sending > contact does not know about the presence of that resource? When should > he stop sending to [EMAIL PROTECTED]/resource? Should he, if he has no > knowledge about the presence, send to [EMAIL PROTECTED] generally? IMHO it is a best practice for users who do not normally share presence to send directed presence during a chat session. > Please also note that the term 'chat session' in that paragraph is quite > undefined, or at least it's meaning is a bit fuzzy to me. At its simplest, I think this is a chat session: hi! hi back! wow, a chat session! yeah, but I gotta run! OK, bye! However, I would recommend the following kind of flow, with sharing of directed presence: hi! hi back! [ ... some optional client prompt for presence sharing here ... ] wow, a chat session! yeah, but I gotta run! OK, bye! The sharing of directed presence gives both parties more knowledge about availability, but I think it should be initiated by the recipient (and subject to client prompt on a per-session basis, or configuration in the client to auto-share directed presence). > And is somewhere described how full JIDs and play together? If at > all? http://www.xmpp.org/extensions/xep-0201.html > If routing is up to the local server side, makes it sense to reveal > resources at all? Wasn't there a progress towards randomized resources? http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#bind-servergen > Sorry for so many questions, but I'm a little bit confused. I try to get > the conversation aspect in my client right, and one problem I stumbled > accross was the fact that my client has no 'windows' or 'tabs' which > could control the extend of a 'chat session'. In my client there is > always a 'tab' to a contact, and the extends of a 'chat session' are > very fuzzy and undefined. > If the term 'chat session' in XMPP means I have to keep track of the > session via some special hacks with resources and , I would have > to complicate the whole thing a bit. That is of course maybe only an issue > with my special client. IMHO, threads are *not* required to have a chat session. > But before I can implement anything resembling 'chat sessions' that > term must be more explictly defined. See above for an example. I can easily write a formal definition too. > Of course, If I don't have to keep track of the resources, that would > _greatly_ simplify everything for me. Just sending to the bare JID and > leaving the rest up to and the contacts routing settings > would make enormous sense to me. Sending every message to the bare JID is not the custom. > Back to section 5.1.1, the sections somehow contradicts the section > 8.3.1.1 (Message): > >For a message stanza of type "chat", "error", "groupchat", or >"normal", the server SHOULD deliver the stanza to the >highest-priority available resource. > > That 'feature' only makes sense if at least the initial message goes to > a bare JID. But if it is routed to a resource by the server and I have > no knowledge about the presence of that resource (eg. if I'm not > subscribed), where should the next message go to, to the full JID I > received a reply from? You should keep sending to the bare JID until you receive a reply from a full JID, then start sending to the full JID. > Will my messages, if that contacts resource goes > offline, be dropped without my knowledge? No, they will probably go to offline storage, because of this: http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-04.html#rules-fulljid-availnomatch I agree that these customary practices are not spelled out very well, so I will fix that in the next version of rfc3921bis. Thanks for the questions! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] IETF SASL WG meeting
On Mon, 2007-12-10 at 10:20 -0800, Justin Karneges wrote: > I don't understand this talk about the SASL negotiation being attacked by a > MITM when it is taking place over TLS. There is brief mention of Bob > possibly not having a certificate or Alice not trusting Bob's CA. Does this > mean the channel binding problem only affects anonymous/unauthenticated TLS? It strengthens your security properties in cases where you trust your SASL authentication mechanism more than you trust the TLS authentication mechanism. If you trust TLS to authenticate the server to the client, then I believe you can do client-to-server authentication without any form of channel binding and you're fine.
Re: [Standards] IETF SASL WG meeting
On Mon, 10 Dec 2007, Justin Karneges wrote: > > It might be cool to for Bob to cryptographically "prove" that Alice is aware > that she is talking to him, but does that have much of a practical benefit? Channel binding is a generic technique, so the privacy layer doesn't have to be TLS - it might be BTNS IPSEC. The point is it allows you to decouple authentication from privacy without allowing MITM attacks. Yes, this is slightly redundant in the case of TLS, but it's a small cost relative to the improved versatility of SASL. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ HUMBER THAMES DOVER WIGHT: NORTH 5 OR 6, OCCASIONALLY 7 AT FIRST, BECOMING VARIABLE 3 OR 4. MODERATE OR ROUGH BECOMING SLIGHT OR MODERATE. SHOWERS THEN FAIR. GOOD.
[Standards] Messages to unsubscribed contacts and resources
Hi! Some days ago I had a mail discussion on the jdev@ mailing list about messages to unsubscribed contacts and contacts in general. Tomasz said that messages should generally go to the bare JID instead of the full JID, and that the local routing is up to the server. He meant, chat sessions should be kept track of with the element, which completly makes sense to me. On the other side RFC3921bis says: Section 5.1.1: If the message is being sent in reply to a message previously received from an address of the form <[EMAIL PROTECTED]/resource> (e.g., within the context of a chat session), the value of the 'to' address SHOULD be of the form <[EMAIL PROTECTED]/resource> rather than of the form <[EMAIL PROTECTED]> unless the sender has knowledge (via presence) that the intended recipient's resource is no longer available. That of course also makes sense, but my problem was: What if the sending contact does not know about the presence of that resource? When should he stop sending to [EMAIL PROTECTED]/resource? Should he, if he has no knowledge about the presence, send to [EMAIL PROTECTED] generally? Please also note that the term 'chat session' in that paragraph is quite undefined, or at least it's meaning is a bit fuzzy to me. And is somewhere described how full JIDs and play together? If at all? If routing is up to the local server side, makes it sense to reveal resources at all? Wasn't there a progress towards randomized resources? Sorry for so many questions, but I'm a little bit confused. I try to get the conversation aspect in my client right, and one problem I stumbled accross was the fact that my client has no 'windows' or 'tabs' which could control the extend of a 'chat session'. In my client there is always a 'tab' to a contact, and the extends of a 'chat session' are very fuzzy and undefined. If the term 'chat session' in XMPP means I have to keep track of the session via some special hacks with resources and , I would have to complicate the whole thing a bit. That is of course maybe only an issue with my special client. But before I can implement anything resembling 'chat sessions' that term must be more explictly defined. Of course, If I don't have to keep track of the resources, that would _greatly_ simplify everything for me. Just sending to the bare JID and leaving the rest up to and the contacts routing settings would make enormous sense to me. Back to section 5.1.1, the sections somehow contradicts the section 8.3.1.1 (Message): For a message stanza of type "chat", "error", "groupchat", or "normal", the server SHOULD deliver the stanza to the highest-priority available resource. That 'feature' only makes sense if at least the initial message goes to a bare JID. But if it is routed to a resource by the server and I have no knowledge about the presence of that resource (eg. if I'm not subscribed), where should the next message go to, to the full JID I received a reply from? Will my messages, if that contacts resource goes offline, be dropped without my knowledge? Thanks for your time :) Robin -- Robin Redeker | Deliantra, the free code+content MORPG [EMAIL PROTECTED] / [EMAIL PROTECTED] | http://www.deliantra.net http://www.ta-sa.org/ |
