Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Ian Paterson wrote: 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? +1 to a Best Practices XEP. If we can more tightly describe the XMPP usage of DIGEST-MD5, then we can have consistent interoperability on our network. At that point we won't need to worry so much about DIGEST-MD5 in general. /psa [1] http://www.ietf.org/internet-drafts/draft-melnikov-digest-to-historic-00.txt smime.p7s Description: S/MIME Cryptographic Signature
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
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
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
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Interesting because most clients used Digest-MD5, so what do we use now? Cram-MD5? Or is there some other newfangled method out there? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Saint-Andre Sent: 10 September 2007 08:41 PM To: standards@xmpp.org Subject: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt] FYI re rfc3920bis... Original Message A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Moving DIGEST-MD5 to Historic Author(s) : A. Melnikov Filename: draft-melnikov-digest-to-historic-00.txt Pages : 7 Date: 2007-09-08 This memo documents problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism, as specified in RFC 2831. This document recommends DIGEST-MD5 to be marked as OBSOLETE in the IANA Registry of SASL mechanims and RFC 2831 to be moved to Historic status.Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to [EMAIL PROTECTED] A URL for this Internet-Draft is: 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]
On Tue Sep 11 11:55:35 2007, Jonathan Chayce Dickinson wrote: Interesting because most clients used Digest-MD5, so what do we use now? Cram-MD5? Or is there some other newfangled method out there? DIGEST-MD5 is still more secure than CRAM-MD5, and this won't change because of that draft. :-) Some background - since I work with both Alexey and Kurt, one of the chairs of the working group that issued this, as well as being in the SASL WG in Prague where this was decided. One upon a time, there was a mechanism called CRAM-MD5, which was thought up as a simple challenge response mechanism. But, it's got a number of weaknesses, the most important two being that its use of MD5 is weak, and it more or less stores the password in the clear on the server. So, a number of replacement mechanisms were proposed. HTTP, meanwhile, had developed Digest auth, and looking to unify HTTP auth and SASL, Chris Newman abandoned his own mechanism, and instead devoted much energy to getting a variant of Digest as a SASL mechanism - which became DIGEST-MD5. However, DIGEST-MD5 has a considerable amount of problems - these are documented in the draft. Eventually, the SASL WG decided to abandon its attempts to fix it, since it was exceedingly difficult to bring it up to date, and some problems were simply beyond fixing. Seeing this coming, a number of people decided to address the niche by designing a new password based mechanism which had approximately the same properties, but was more secure. These were: HEXA (By Alexey and myself). SCRAM-MD5 - a reissue and revamp of Chris Newman's original mechanism, by Abhijit Menon-Sen (Who, if he reads this, will no doubt correct my spelling). (Actually, it's SCRAM-*, now, as it's sprouted hash agility). YAP-* - a mechanism family intended to replace PLAIN in some circumstances for RTT-sensitive applications, and also replace CRAM-MD5 entirely. In Prague, all three were presented and discussed at length, and we decided to fold in the good bits of HEXA into SCRAM-MD5 and proceed with SCRAM and YAP, ditching DIGEST-MD5 (and saving Alexey and me lots of typing). SCRAM was designed a decade ago, and has actually seen some limited deployment. I'd heartily recommend examining it closely. Alexey and I hadn't actually read it when we designed HEXA (in a pub, on the back of a beermat), although the two come out looking very similar - both use The Powerful XOR Encryption Algorithm, as I like to call it. So the short answer is: Carry on using DIGEST-MD5 until a replacement comes out, watch SCRAM-* as a functional replacement, watch YAP-* as a functional replacement for CRAM and PLAIN. If you're clear on the patent situation - I'm not - then you may wish to look at SRP, which seems more secure than any of these. Some references for those willing to try the bleeding edge: http://tools.ietf.org/html/draft-cridland-sasl-hexa-00 http://tools.ietf.org/id/draft-newman-auth-scram-04.txt http://tools.ietf.org/wg/sasl/draft-zeilenga-sasl-yap-01.txt The last two are actively worked on, and I'm sure the authors would be interested in comments. The first is just included for completeness. Hope this helps. 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
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Dave Cridland wrote: On Tue Sep 11 11:55:35 2007, Jonathan Chayce Dickinson wrote: Interesting because most clients used Digest-MD5, so what do we use now? Cram-MD5? Or is there some other newfangled method out there? DIGEST-MD5 is still more secure than CRAM-MD5, and this won't change because of that draft. :-) Back in August I emailed about this issue [1] with the IETF area directors for applications and security, relevant WG chairs, and interested others. The conclusion was that in rfc3920bis we would make the following changes to the mandatory-to-implement technologies: 1. Remove DIGEST-MD5 2. Add TLS + SASL PLAIN /psa [1] http://mail.jabber.org/pipermail/standards/2007-August/016262.html smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Dave Cridland wrote: On Tue Sep 11 11:55:35 2007, Jonathan Chayce Dickinson wrote: Interesting because most clients used Digest-MD5, so what do we use now? Cram-MD5? Or is there some other newfangled method out there? DIGEST-MD5 is still more secure than CRAM-MD5, and this won't change because of that draft. :-) I strongly agree. Despite its imperfections, RFC 3920bis should continue recommending and requiring DIGEST-MD5 until something better has been adopted by the IETF. Furthermore I disagree with the following problem with the DIGEST-MD5 mechanism included in the Internet-Draft: Implementations may chose to store inner hashes instead of clear text passwords. While this has some useful properties, such as compromise of an authentication database on one server does not automatically compromise an authentication database with the same username and password on other servers, in practice this was rarely done. Firstly, the inner hash is not compatible with commonly deployed Unix password databases. Secondly, change of a username invalidates the corresponding inner hash. In practice inner hashes may be stored relatively rarely, however that does not necessarily make the optional feature into a problem. It is, IMHO, a critical security feature that should be employed whenever practical. Perhaps RFC 3920bis could encourage this practice - while mentioning the potential impracticalities. Note, a change in the SASL mechanisms supported by future versions of an XMPP server is probably a more likely cause of invalidating the inner hash than changing XMPP usernames (which are generally fixed). - Ian
[Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
FYI re rfc3920bis... Original Message A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Moving DIGEST-MD5 to Historic Author(s) : A. Melnikov Filename: draft-melnikov-digest-to-historic-00.txt Pages : 7 Date: 2007-09-08 This memo documents problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism, as specified in RFC 2831. This document recommends DIGEST-MD5 to be marked as OBSOLETE in the IANA Registry of SASL mechanims and RFC 2831 to be moved to Historic status.Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to [EMAIL PROTECTED] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-melnikov-digest-to-historic-00.txt smime.p7s Description: S/MIME Cryptographic Signature
