Re: New work for sacred working group?

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.

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.

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.  We're addressing this
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,
Jim

Stephen Farrell <[email protected]> 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:[email protected]] Sent: Wednesday,
> >> June 15, 2005 9:49 AM
> >> To: [email protected]; [email protected]
> >> 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.