Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Oh, and MD5 has been heavily criticized, is it not time somebody used SHA?
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Or, alternatively, what I said before, is that the SSL/TLS be two way, that is both the client and the server present certificates (SASL EXTERNAL). Certificates are freely available from start.com, so that needn't be an issue for the client. We just need the mainstream servers, like JAIM and J.O to implement it: and then everyone will catch on. This also runs along with the SPIMming issue from a while back. As I said, if a client is misbehaving you simply report it to the CA and get the certificate revoked. That would be a huge pain for SPIMmers, they can make accounts as they see fit, but not certificates. In the case of a SPIMmer having their own server, we could try something like the following (the server NEVER authenticates itself with other servers, rather, the client certificate is used for that): * John connects to j.o with his certificate. * He wants to send a message to Fred in jaim.org. * Jaim.org sends a SASL EXTERNAL request to j.o, which forwards it to John. * John sends his certificate to j.o, which then forwards it to jaim.org. * Jaim.org checks his certificate against his CA. * John, and not j.o, is now authenticated on Jaim.org.
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
On Wed Sep 12 07:46:28 2007, Jonathan Chayce Dickinson wrote: Hmm, AFAIK such password protection is a designed feature of DIGEST-MD5. To take advantage of the feature, when registering a new account a user must provide their DIGEST-MD5 inner password hash instead of their password. Which brings you round to square one. Server sends salt, client sends MD5(salt+password). I.e. server also needs password to do the exact same operation to check for equality, which isn't the best. What we really need is a static and dynamic salt, one that never changes and one that changes for each login, thus: MD5(salt1+MD5(salt2+password)). This means that each user in the database can have a different salt (protecting users in the case of a compromised database), and the digest can be different each time for the same password (protecting users from a replay attack). I really recommend you read the specifications before making comments like this. You seem to be describing CRAM-MD5, then trying to describe DIGEST-MD5, and then thinking there's replay attacks in both, whereas there aren't in either. If the server needs to enforce password policies, then it does of course need the password. But only with CRAM is there a need to store it. (Even with those daft policies that insist you cycle through 28 passwords every two weeks). Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
[Standards] MD5 is weak...?
Yes, folks, it's time for the MD5 is weak show. Join in if you know the words, and don't worry if you miss it, it'll be repeated very soon. All this is my limited understanding only. Not a qualified or licensed cryptographer. Please consult your own cryptographic expert. The value of hashes may go down as well as up. Etc. On Wed Sep 12 07:57:31 2007, Jonathan Chayce Dickinson wrote: Oh, and MD5 has been heavily criticized, is it not time somebody used SHA? MD5 has several known weaknesses. It's also one of the most carefully examined cryptographic hash functions, which is why. SHA-1 is now also showing weaknesses, although it's not yet reached the point where they're useful. SHA-2 (including SHA-256) is effectively just SHA-1 but more so, so most experts seem to think there's a possibility that a severe flaw in SHA-1 would yield flaws in SHA-2 as well. There are several key exploitable weaknesses in MD5, in particular, if the attacker knows X and H(X), it's possible (ie, slightly easier than it should be) for them to construct Y, such that H(Y)==H(X). It's actually trivial if they can choose both X and Y. This means in particular that MD5 is worthless as a signature - so if you see a software package which is apparently signed with MD5, this is not a useful guide that the software package is authentic. This is harder (in both cases) for the attacker if X and Y must fit a particular tight syntax, since there's then less room to wiggle. Luckily, this doesn't affect CRAM-MD5, or DIGEST-MD5, or SCRAM/HEXA when used with MD5. It doesn't even affect many uses of HMAC-MD5, which is also used for signatures. This is because the X is (partially or completely) unknown. MD5 is not susceptible to a second preimage attack, that is, given only H(X), an attacker cannot determine what X might be, nor can they find Y such that H(Y)==H(X) - you need to know X first. (As an aside, this is also harder to do even with an entirely unbroken hash, thanks to the Birthday Paradox). There is one reason pushing change, which is that with modern hardware, it's simply too quick to do, making dictionary attacks more feasable. (Actually, there's the reputation of MD5, too, but there's only one *technical* reason). CRAM-MD5 and DIGEST-MD5 are not hash agile, whereas SCRAM and YAP (and HEXA) are, so the answer to your question is that somebody is using SHA (in particular, SHA-256 is popular), and moreover, somebody is expecting the entire SHA family of cryptographic hashes to be broken utterly one day. In the case of HEXA, I elected to continue using MD5 as the mandatory hash, but used several rounds of it, increasing the computational cost trivially, but leveraging the vast deployed base of MD5-capable software. Most people disagreed with this decision, not because MD5 was weak in this respect, but because they pointed out that SHA-256 was a lot better deployed than I thought. This means that - assuming MD5 second preimage attacks are likely to become viable before SHA-256 second preimage attacks, which seems a reasonable asusmption - deploying SHA-256 to begin with will extend the life of the mechanism at little cost to initial deployments. (To be fair, a lot of people agreed that use of MD5 in HEXA was safe, but said that they felt uncomfortable with it nonetheless). Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
[Standards] XEP-0016 vs. XEP-0191 inconsistency
I have an issue with XEP-0016. XEP-0016 does not block outgoing IQ and Message stanzas when the incoming are blocked. On the contrary XEP-0191 blocks both incoming and outgoing stanzas. While, I can see a use case for unblocked outgoing IQ stanzas, I cannot see a use case for unblocked outgoing messages, besides flooding other users with messages, while being safe under incoming message blocking privacy list. I do worry though, that would lead to dangerous miscommunication, when Aunt Tillie unknowingly blocks incoming messages from Nephew Joe, then messages him. When he replies, he thinks that the reply was delivered, she thinks that there was no reply and Houston we have a problem. Besides that, this leads to uncertainty in implementations that integrates privacy lists and simple communications blocking. User blocked messages. Message is going out of session. What to do? Let it through according to XEP-0016 or stop it according to XEP-0191? I vote to unify this handling, and change XEP-0016 to stop outgoing messages when incoming messages are blocked in line with XEP-0191. I don't know what to do with IQs. I would probably like to loosen the XEP-0191 to allow outgoing IQs to blocked contacts. -- Tomasz Sterna Xiaoka.com http://www.xiaoka.com/
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Peter Saint-Andre wrote: Ian Paterson wrote: In real life servers will always be compromised (especially in cases where the attacker is the service provider). So SASL PLAIN still contains a serious vulnerability that is easily fixed in those cases where DIGEST-MD5 is a practical option. Except that DIGEST-MD5 is effectively being deprecated by the IETF. Thus the interest in SCRAM, YAP, and their ilk. With all due respect to the experts at the IETF, I feel (as a non-expert) that they are trying to depricate DIGEST-MD5 before it has a suitable replacement (i.e. another one that protects users' passwords from a compromised server). I strongly agree we should recommend/require SCRAM and/or YAP as soon as they are baked. But is that likely to happen before 3920bis is puiblished? I agree that if we start recommending SASL PLAIN in addition to DIGEST-MD5 now, *and if we continue to do so in the future*, then we can ensure that current implementations will still be compatible with future implementations that have removed support for DIGEST-MD5. However I don't understand why we are considering recommending weakening the security of XMPP servers in the short and medium term by not requiring any of DIGEST-MD5 or SCRAM or YAP. Are XMPP implementors experiencing interoperability issues with DIGEST-MD5? If so can't we fix them with a Best Practices XEP - as we did with SASL ANONYMOUS and SASL EXTERNAL? Which of the 7 problems with DIGEST-MD5 mentioned in [1] make DIGEST-MD5 less secure for XMPP authentication than SASL PLAIN? - Ian [1] http://www.ietf.org/internet-drafts/draft-melnikov-digest-to-historic-00.txt
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Jonathan Chayce Dickinson wrote: Or, alternatively, what I said before, is that the SSL/TLS be two way, that is both the client and the server present certificates (SASL EXTERNAL). TLS + SASL EXTERNAL is also mandatory-to-implement. But how many people have or use X.509 certificates? I seem to be just about the only person who signs their email with such a certificate on this list, or even on the security-related IETF lists. If even members of the IETF security mafia don't eat their own dogfood, I don't see how we can expect the average Jabber user to do so. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
On Tue, 2007-09-11 at 19:51 +0100, Dave Cridland wrote: If I ruled the world, I'd mandate TLS+SCRAM, and have a SHOULD for TLS+YAP (the latter being plaintext-equiv on the server, but only a single round-trip, so great for mobiles). You may be missing the most popular reason for sending plain-text passwords to the server (over TLS, one hopes): it's the only way for the server to check the password against an external verifier such as an LDAP server, AD controller, or Kerberos KDC. (GSSAPI krb5 auth is much better if you have an AD controller or Kerberos KDC, of course, but I don't hold out much hope for that being universally implemented in clients.)
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Greg Hudson wrote: On Tue, 2007-09-11 at 19:51 +0100, Dave Cridland wrote: If I ruled the world, I'd mandate TLS+SCRAM, and have a SHOULD for TLS+YAP (the latter being plaintext-equiv on the server, but only a single round-trip, so great for mobiles). You may be missing the most popular reason for sending plain-text passwords to the server (over TLS, one hopes): it's the only way for the server to check the password against an external verifier such as an LDAP server, AD controller, or Kerberos KDC. (GSSAPI krb5 auth is much better if you have an AD controller or Kerberos KDC, of course, but I don't hold out much hope for that being universally implemented in clients.) Yes, I mentioned the same a few posts back - auth proxying can be done across a variety of mechisms/deployments only with sasl plain (and the deprecated jabber:iq:auth) in xmpp. - Mridul
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Hello On Wed, Sep 12, 2007 at 08:37:34PM +0200, Jonathan Chayce Dickinson wrote: Anyway, truth be told, if the client can't use Jabber unless they get a certificate, chances are they will, which would not only benefit Jabber, but the internet as a whole. You could even use xmpp.org as the CA, which 'we' would have more control over: so 'we' could crack down on SPIMmers quite easily. Then users go after MSN instead. -- Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. -- Fred Brooks Michal 'vorner' Vaner pgp5VqcgzRFuV.pgp Description: PGP signature
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Ian Paterson wrote: Greg Hudson wrote: On Tue, 2007-09-11 at 19:51 +0100, Dave Cridland wrote: If I ruled the world, I'd mandate TLS+SCRAM, and have a SHOULD for TLS+YAP (the latter being plaintext-equiv on the server, but only a single round-trip, so great for mobiles). You may be missing the most popular reason for sending plain-text passwords to the server (over TLS, one hopes): it's the only way for the server to check the password against an external verifier such as an LDAP server, AD controller, or Kerberos KDC. (GSSAPI krb5 auth is much better if you have an AD controller or Kerberos KDC, of course, but I don't hold out much hope for that being universally implemented in clients.) I think Dave is well aware of that benefit. :-) I agree that servers that support external verification should implement SASL PLAIN. However, SASL PLAIN's support for external verification comes at a very significant security cost (since some servers *will* be compromised). IMHO, the spec should not sacrifice the security of users of servers that could employ internal verification (by requiring support only for SASL PLAIN). How do people feel about the following rules: 1. Clients and servers MUST implement both DIGEST-MD5 and SASL PLAIN. DIGEST-MD5 is already mandatory to impl (not deploy), and jabber:iq was is the basic compliance suite for servers. We could add SASL PLAIN instead of jabber:iq ? That will take care of this ? 2. Each server installation MUST include either (but not both) DIGEST-MD5 (when inner hash verification is available) or SASL PLAIN (when only external verification is available) in the list of mechanisms it offers clients. We cannot expect to enforce policy on how a deployment should look like - that is the deployment administrator's prerogative. In our case, depending on the realm used (ldap, access manager, text, etc) different default auth mechanisms features are enabled (no DIGEST-MD5 in ldap case for example). In context of sasl, new mechanisms can be added (through spi's) or existing out of the box ones disabled based on the deployment configuration - and it is essential that we give admin the freedom to customize it the way he wants. Btw, we did have some confusion regarding mandatory to implement vs deploy, but devcon 2006 cleared it up for us :) - Mridul - Ian
[Standards] Better Privacy Lists (and Invisibility)
Let me summarise our current experience with XEP-0016 Privacy Lists first. 1. We separated Privacy Lists from RFC3921bis to make it possible to change it (XEP-0016 is in Draft status now). 2. We have reports, that developers find Privacy Lists hard to use, thus 3. We have developed simpler frontends to Privacy Lists such as XEP-0191 Simple Communications Blocking and XEP-0126 Invisibility 4. XEP-0126 Invisibility shows problems with using Invisibility together with other communications blocking (such as XEP-0191) We are starting using Privacy Lists in a similar manner as Pub-Sub - as a more powerful backend that drives simpler protocols (like PEP). My experience with XEP-0191 implementations tells me, that this is a good direction. But problems with XEP-0126 shows, that we need Privacy Lists be even more flexible. We need to have more than one active list at a time, which XEP-0016 does not support. I think we could fix it without changing the Privacy List spec. Instead we could put another layer on top of it, that adds support for many active list at a time. 1. Server advertises new disco#info feature: feature var='urn:xmpp:stacked-privacy-lists'/ 2. New attribute 'order' of list activation packet is then allowed (in 'urn:xmpp:stacked-privacy-lists' namespace): iq from='[EMAIL PROTECTED]/orchard' type='set' id='active1' query xmlns='jabber:iq:privacy' xmlns:spl='urn:xmpp:stacked-privacy-lists' active name='invisible-to-all' spl:order='first'/ /query /iq that would activate list 'invisible-to-all' and insert it on top of stack. If a packet passes the first active list it is put through second and so on. Options for the 'order' attribute are 'first', 'last' or numeric value of the position of the stack (begining from one). The order is not fixed after activation. If one puts new active list on position 5, the previously fifth active list will have order of 6. 3. More than one active/ child on lists IQ get query with additional 'order' attribute in 'urn:xmpp:stacked-privacy-lists' namespace: iq type='result' id='getlist1' to='[EMAIL PROTECTED]/orchard' query xmlns='jabber:iq:privacy' xmlns:spl='urn:xmpp:stacked-privacy-lists' active name='invisible-to-all' spl:order='1'/ active name='private' spl:order='2'/ default name='public'/ list name='public'/ list name='private'/ list name='special'/ /query /iq 4. A way to deactivate a list is simple: iq from='[EMAIL PROTECTED]/orchard' type='set' id='inactive1' query xmlns='urn:xmpp:stacked-privacy-lists' inactive name='special'/ /query /iq Everything else from XEP-0016 works as before. And if client does not know 'urn:xmpp:stacked-privacy-lists' it would not even notice the existence. Question is, whether we should add more than one default list? I personally think, we don't need to. I want to submit formal XEP with this proposal, but before, I open to discussion. :-) Side note: The Privacy List name 'invisible-to-all' was chosen to show how nicely XEP-0126 Invisibility fits as another layer over the proposal. * * * There are some problems with XEP-0016 Privacy Lists too. 1. With RFC3921 support was mandatory, so there was no need for feature advertisements. With RFC3921bis it's not, so we need a disco#info feature for Privacy Lists 2. Outgoing messages and IQs are not blocked when incoming are. This is inconsistent with XEP-0191 that requires blocking both outgoing and incoming. I vote for requiring blocking outgoing messages in XEP-0016 Privacy Lists and allowing for outgoing IQs in XEP-0191 Simple Communications Blocking. (With same error for aoutgoing messages as in XEP-0191.) -- Tomasz Sterna Xiaoka.com http://www.xiaoka.com/
Re: [Standards] UPDATED: XEP-0186 (Invisible Command)
Dnia 12-09-2007, Śr o godzinie 13:43 -0600, Peter Saint-Andre napisał(a): XEP-0186 is just this sh$%^ XEP-0018 in a pretty IQ envelope. Please do look at both the XEP-0016 and XEP-0186 specs. It is spaghetti. So many conditions, corner cases, if this than thats. Sorry about that. We pushed that protocol into RFC 3921 before it was fully baked, I think. Urm. I meant XEP-0018 Invisible Presence. And XEP-0186 Invisible Command is same as Invisible presence, only the trigger packet is IQ instead of presence. Both specs XEP-0016 Privacy List is actually quite good. Let's start speaking names, not numbers - less space for typos. ;-) We do not have to mirror patches for deficiencies in legacy protocols. We really could do better with Privacy Lists. I'm sure we could. The question is: do we throw away privacy lists or develop something better? I don't know if it is worth the time. Or at least I'm too lazy to work on a whole new protocol. What I meant is that: We really could do better [than simple invisibility] with Privacy Lists. For the rest, let me start a new thread. :-) -- Tomasz Sterna Xiaoka.com http://www.xiaoka.com/
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Mridul Muralidharan wrote: Ian Paterson wrote: Greg Hudson wrote: On Tue, 2007-09-11 at 19:51 +0100, Dave Cridland wrote: If I ruled the world, I'd mandate TLS+SCRAM, and have a SHOULD for TLS+YAP (the latter being plaintext-equiv on the server, but only a single round-trip, so great for mobiles). You may be missing the most popular reason for sending plain-text passwords to the server (over TLS, one hopes): it's the only way for the server to check the password against an external verifier such as an LDAP server, AD controller, or Kerberos KDC. (GSSAPI krb5 auth is much better if you have an AD controller or Kerberos KDC, of course, but I don't hold out much hope for that being universally implemented in clients.) I think Dave is well aware of that benefit. :-) I agree that servers that support external verification should implement SASL PLAIN. However, SASL PLAIN's support for external verification comes at a very significant security cost (since some servers *will* be compromised). IMHO, the spec should not sacrifice the security of users of servers that could employ internal verification (by requiring support only for SASL PLAIN). The spec dictates what a software implementation must support. Naturally an implementation may support more than that. In terms of SASL that means additional mechanisms such as GSSAPI or whatever. How do people feel about the following rules: 1. Clients and servers MUST implement both DIGEST-MD5 and SASL PLAIN. The text in RFC 3920 says that both DIGEST-MD5 and SASL EXTERNAL are mandatory-to-implement (MTI) but does not differentiate between clients and servers. No one is arguing for removal of SASL EXTERNAL, but I am proposing that it should be MTI for server-to-server only. I am also proposing (based on the IETF discussions) that we add TLS + SASL PLAIN as MTI for client-to-server. Then the question is: do we retain DIGEST-MD5 as MTI for client-to-server? (For our purposes it is useless for s2s.) Ian says yes. I say I don't know because it seems that the IETF is relegating it to historic. But perhaps if we can document the potential points of ambiguity regarding implementation (as Ian points out, we have done that for SASL EXTERNAL) then perhaps we'd be on the road to keeping it. DIGEST-MD5 is already mandatory to impl (not deploy), and jabber:iq was is the basic compliance suite for servers. But jabber:iq:auth is truly historical at this point. It comes in handy for testing, but we're not especially encouraging deployment of it. We could add SASL PLAIN instead of jabber:iq ? That will take care of this ? There is nothing to add jabber:iq:auth to, since it was not mentioned in RFC 3920. 2. Each server installation MUST include either (but not both) DIGEST-MD5 (when inner hash verification is available) or SASL PLAIN (when only external verification is available) in the list of mechanisms it offers clients. That's a deployment decision. We cannot expect to enforce policy on how a deployment should look like - that is the deployment administrator's prerogative. Correct. In our case, depending on the realm used (ldap, access manager, text, etc) different default auth mechanisms features are enabled (no DIGEST-MD5 in ldap case for example). In context of sasl, new mechanisms can be added (through spi's) or existing out of the box ones disabled based on the deployment configuration - and it is essential that we give admin the freedom to customize it the way he wants. Btw, we did have some confusion regarding mandatory to implement vs deploy, but devcon 2006 cleared it up for us :) To clear up the confusion for everyone else: typically, a specification declares what a software implementation must include, that is, what features are included in code. Whether a given deployment enables those features in a running service is a matter of local service policy. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
