I personally have limited interest in schemes like SPEKE for credential download right now, but maybe I'm missing the practical benefits. I find it workable to include CA certificates for TLS in a (trusted, signed) SACRED client-side software distribution.
Fair enough. From a systems-perspective you do still need that trusted s/w on the client. At one level, I guess protocols like SPEKE etc. are simply a bit more elegant, although maybe the bits on the wire are arguably less likely to be vulnerable and perhaps the databases can be made a bit more secure too.
My interest is primarily in using existing site-wide authentication mechanisms (via SASL, GSSAPI, PAM, etc.) for retrieving PKI credentials, for single sign-on and ease of administration, and it's not clear to me how to integrate SPEKE into this type of environment. I don't want another password verifier database to manage or another password to remember.
I don't think that SPEKE or whatever is any different here, so long as the value derived from the password used is available on both sides.
The #1 concern I hear about lately is client-side theft of passwords
(and other long-lived secrets) from keystroke loggers, trojans, etc.,
and I'm not sure how SPEKE helps me with that.
A fair point. OTOH, its no worse and I guess there ought be a way to use SPEKE (or equivalently robust schemes) so that the client can store password-derived value(s) that aren't as easy to offline dictionary attack. (I'm not sure.)
>concern with one-time passwords and short-lived session credentials (HTTP cookies, Kerberos tickets, X.509 proxy certificates, etc.).
We currently support SRP authentication in addition to TLS+DIGEST-MD5 in our SACRED implementation (http://sacred.sf.net/ -- comments, bug reports, interop testers, contributors welcome). Getting SASL-SRP working with BEEP has been an adventure. I hope to write-up our implementation experiences sometime soon.
Regards, Stephen.
Regards, Jim
Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote:
Does the lack of response mean that there's no longer much interest in using schemes like SPEKE for credential download or that no-one's reading this list anymore?
If the former, please say so.
Stephen.
Stephen Farrell wrote:
Dear sacred WG, Magnus and I have requested a slot for the sacred WG at the upcoming Paris IETF meeting [1]. There are three things to discuss (see below). One possible outcome is that we reawaken this WG to do some work. Formally, this would probably require a charter update. The outcome of the discussions could also be a decision not to take on any further SACRED work at this point. In all likelihood, this would mean that the SACRED working group will be shut down. Hopefully, we can come to consensus on this between now and a few weeks after the Paris meeting. Regardless of whether or not you intend coming to Paris, We'd encourage you to let the list know how you think we ought proceed, so that we are able to start that meeting with some idea of the level of interest and the range of opinions, (or else, we can cancel the meeting if there's no interest), So, read on...and comment to the list! Stephen & Magnus. Item 1: SACRED has always been in need of a strong password- based mechanism for download of credentials. Early on, the WG considered [2] using SPEKE for this. However, there was no concensus for this approach, at least partly due to the, at the time, unclear IPR situation. Over the last couple of months, Magnus and I have been in touch with the holders of the SPEKE patent, Phoenix Technologies [3], who have now made a generic IPR declaration to the IETF [4]. Phoenix would like the opportunity to present their technology and discuss its use in sacred. Note that while the current, generic declation is basically RAND, this does not necessarily imply that the terms for the use of SPEKE for sacred would be exactly the same. In our discussions with Phoenix so far, they appear to have made serious attempts to learn how to be "IETF-friendly" and they are coming to the meeting to explain their technology and position and to learn whether and/or how they can make use of SPEKE attractive in IETF-concensus terms. - If there is WG concensus then we could work to improve the sacred protocol [5] by incorporating SPEKE. Item 2: Independently of the discussions with Phoenix Technologues, Radia Perlman and Charlie Kaufman, who where also deeply involved in the early stages of this working group, have suggested a scheme they themselves invented which pre-dates SPEKE. Their email below summarises their scheme and its history. - If there is WG concensus then we could work to improve the sacred protocol by incorporating Radia and Charlie's scheme. Item 3: RSA Security has drafted a description [6] of how to (more or less) run the current sacred protocol using HTTP instead of BEEP as a substrate. - Were there to be WG concensus on doing work on items 1 or 2, then the WG might consider improving the protocol by changing the substrate from BEEP to HTTP. Note that in our opinion, item 3 alone is not sufficient reason to re-charter the WG. Here's a suggested 1-hour meeting agenda (we may get an additional 30 minutes in which case each item would get proportionally longer time): - Introductions (5) - Item 3: HTTP as a SACRED substrate (10) - Item 2: Radia's & Charlie's scheme (15) - Item 1: Phoenix presentation on SPEKE (15) - Discussion on new work, possible re-chartering (15) References: [1] http://www.ietf.org/meetings/IETF-63.html [2] http://www.ietf.org/proceedings/02mar/203.htm [3] http://www.phoenix.com/ [4] https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=587 [5] http://www.ietf.org/rfc/rfc3767.txt [6] ftp://ftp.rsasecurity.com/pub/rsalabs/ietf/sacred/draft-richards-sacred-http-XX.txt Charlie Kaufman wrote:
I agree with this technical and historical summary.
[...]
--Charlie
-----Original Message----- From: Radia Perlman [mailto:Radia.Perlman@xxxxxxx] Sent: Wednesday, June 15, 2005 9:49 AM To: magnus@xxxxxxxxxxxxxxx; stephen.farrell@xxxxxxxxx Cc: Charlie Kaufman Subject: A possible credentials download protocol
Charlie...correct me if I get any of the technical or historical details
wrong here. Perhaps you should reply to all, even if there are no errors, saying "I agree".
*************** In the first edition of the book "Network Security" published in March 1995, on page 252, there is a protocol that although we claim in the book it is "Bellovin and Merritt's Second Scheme" was actually a protocol Charlie inadvertently invented, because he had misremembered augmented EKE.
The diagram in the book of Charlie's protocol does two things: it does mutual authentication, and also downloads Alice's credential (her private key).
For the sacred WG, we could do just the credential download portion of the protocol. That means removing messages 3 and 5 (the ones in which the client Alice authenticates to Bob), and we can certainly also remove the challenge field from message 2 (where Bob sends Alice a challenge to authenticate with).
We are left with a 2 message protocol that does no authentication by Alice to Bob. Bob has no idea, after the exchange, whether the true Alice, knowing the password, has successfully downloaded the credential. If it is an imposter, the imposter will obtain garbage. Bob can't tell the difference.
However, for the purpose of the sacred WG, we do not need an authentication protocol. All we need is a credential download protocol.
Anyway, the protocol I'm proposing is a 2-message protocol that looks like this:
Bob (the server) has the following two pieces of information:
. W=hash of Alice's password . Y=credential (which is Alice's private key encrypted with her password).
In the protocol, Alice and Bob do a Diffie-Hellman exchange, encrypted with W, and Bob sends Y encrypted with the resulting Diffie-Hellman key. So the protocol is:
Alice and Bob each choose a random number A, and B, respectively. The Diffie-Hellman parameters are g and p.
Alice to Bob: {g^A mod p}encrypted with W Bob to Alice: {g^B mod p} encrypted with W, {Y} encrypted with g^AB
********* The protocol in the book had an additional challenge, R, and was:
1: Alice to Bob: {g^A mod p}W 2: Bob to ALice: {g^B mod p}W, R 3: Alice to Bob: {R} encrypted with g^AB mod p 4: Bob to ALice: {Y} encrypted with g^AB 5: Alice to Bob: R signed by Alice's private key
So I'm proposing removing messages 3 and 5, combining messages 2 and 4, and removing the field "R" from message 2.