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.