Subject: New work for sacred working group?

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Jun 2005 17:19:34 +0100

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jun 2005 12:41:12 +0100

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:

>> From: Radia Perlman [mailto:[email-masked]] Sent: Wednesday, 
>> June 15, 2005 9:49 AM
>> a protocol Charlie inadvertently invented, because he had 
>> misremembered augmented EKE.
>>
>> So I'm proposing removing messages 3 and 5, combining messages 2 and 
>> 4, and removing the field "R"
>> from message 2.
>>
>>
>>
>>
> 
>

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 27 Jun 2005 23:49:55 +1200

Stephen Farrell <[email-masked]> writes:

>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?

I'm reading it, but purely in passive mode.  In theory I'd be strongly opposed
to the use of any crippled/patented technology in Sacred (particularly when
there are unencumbered alternatives available), but since I'm not an
implementor it's really just a personal opinion.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jun 2005 14:05:14 +0100

Hi Peter,

> implementor it's really just a personal opinion.

Well, ignoring Radia & Charlie's proposal for the moment, I'm
not sure that we really do have an unencumbered equivalent, at
least at the "mechanism" level (if you know what I mean), but
I do take your point about opposing encumbrances generally.

I guess when considering SPEKE, partly we're trying
to see whether the Phoenix folks end up with an IPR position
that would garner enough suppoor that we get WG consensus to
reactivate this WG...or not...and IMO if more people can
explicitly say what they'd find (un)acceptable on the
list, then that might well influence the outcome (or at
least speed things up somewhat:-)

Stephen.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Jun 2005 15:02:53 +0200

> implementor it's really just a personal opinion.

Which unencumbered alternatives are you thinking of?

It appears to me as if the security community in IETF can't offer a
good password based security protocol.

Anything beyond TLS+PLAIN seem to me be either surrounded with IPR
concerns (SPEKE, SRP); or incredible poorly designed and implemented
(DIGEST-MD5); or deprecated (CRAM-MD5); or too complex to allow a
reasonable implementations (X.509, CMS); or too experimental (TLS
PSK); or burdened by history (Kerberos), to be applicable.

Of course, this is merely another personal opinion as I don't have a
SACRED implementation either.  (I'd like to write one though... :))

Cheers,
Simon

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 28 Jun 2005 01:11:13 +1200

>Which unencumbered alternatives are you thinking of?

TLS-PSK.

>Anything beyond TLS+PLAIN seem to me be either surrounded with IPR concerns
>(SPEKE, SRP); or incredible poorly designed and implemented (DIGEST-MD5); or
>deprecated (CRAM-MD5); or too complex to allow a reasonable implementations
>(X.509, CMS); or too experimental (TLS PSK); or burdened by history
>(Kerberos), to be applicable.

Hmm, I'd hardly call a standards-track TLS RFC "experimental".  Given the
strong support there is for this from low-powered device vendors, and the fact
that it's a trivial mod to TLS, I'd hope there'd be good support for this in
the future.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jun 2005 14:38:35 +0100

Peter,

>>Which unencumbered alternatives are you thinking of?

Haven't read that (not yet an RFC btw) myself, but I now plan
to do so.

I guess I'd have to question the "equivalence" part here since
tls-psk-09 [1] says:

"  It is also possible to use the SRP (Secure Remote Password)
    ciphersuites for shared secret authentication [SRP].  SRP was
    designed to be used with passwords, and incorporates protection
    against dictionary attacks. "

So I would guess that for sacred, TLS-PSK isn't an unencumbered
equivalent since offline dictionary attacks are a high priority
here. Or am I misreading something?

Stephen.

[1] http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-09.txt

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jun 2005 17:01:38 +0100

Hi Simon,

 > concerns (SPEKE, SRP); [...]

Would it be fair to take that as meaning you'd be supportive
of new work being done here on things like SPEKE if it were
not "surrounded by IPR concerns"?

Stephen.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 28 Jun 2005 03:56:32 +1200

Stephen Farrell <[email-masked]> writes:

>So I would guess that for sacred, TLS-PSK isn't an unencumbered equivalent
>since offline dictionary attacks are a high priority here. Or am I misreading
>something?

Oh, that's only if you use the weakest (most lightweight) form of PSK, with
the entire shared secret being the PSK.  In this form it's assumed that you'd
be using a high-entropy key rather than just a password.  The stronger (but
more heavyweight) forms use a standard RSA or DH exchange (alongside the PSK
data), so this isn't an issue.  Note that even the most heavyweight form, DHE
+ PSK, only has the same overhead as the SPEKE/SRP/etc-type protcols.

Peter.

---

From: Jim Basney <[email-masked]>
Date: Mon, 27 Jun 2005 11:03:09 -0500

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-masked]> wrote:
> >> 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
> >> The diagram in the book of Charlie's protocol does two things: it
> >> does mutual authentication, and also
> >> 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
> >> We are left with a 2 message protocol that does no authentication
> >> by Alice to Bob. Bob has no idea, after
> >> If it is an imposter, the imposter will obtain garbage. Bob can't
> >> tell the difference.
> >>
> >> Anyway, the protocol I'm proposing is a 2-message protocol that
> >> looks like this:
> >>
> >> In the protocol, Alice and Bob do a Diffie-Hellman exchange,
> >> encrypted with W, and Bob sends
> >> Alice and Bob each choose a random number A, and B,
> >> respectively. The Diffie-Hellman parameters
> >> are g and p.
> >>
> >> So I'm proposing removing messages 3 and 5, combining messages 2
> >> and 4, and removing the field "R"
> >> from message 2.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Jun 2005 18:05:58 +0200

> not "surrounded by IPR concerns"?

Hello Stephen.  Yes, if it means that SPEKE is eventually made
available for use in free implementations, that alone would justify
going through some additional work here, in my opinion.  I'm thinking
of this issue in general, and not specifically in connection with
SACRED, though.  But it has to start somewhere...

Regards,
Simon

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jun 2005 17:30:20 +0100

Hi Peter,

So you're saying that TLS_DHE_PSK_WITH_AES_128_CBC_SHA is
a ciphersuite that can meet the requirements for use in
a sacred protocol, and does better than what we've got now.
(I also presume that you're not arguing that we should
do work here just because that's true, but do correct me
if I'm wrong there:-)

As I read it, that works by basically appending a (hashed?)
password to a D-H derived key (with some length fields)
and using the resulting value as the TLS pre-master key.
Presumably the handshake falls over at the finished message
if the wrong password was used.

I'll have to read that I-D again and think about whether it
really is better than the current sacred scheme, (and whether
in that case, it means new work here would be more or less
interesting...)

Has anyone else an opinion on this as a basis for credential
download? (And how it'd compare with SPEKE and/or the
newly-proposed/10-year-old Radia/Charlie variation?)

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jun 2005 17:42:32 +0100

Hi Jim,

> 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.

> another password verifier database to manage or another password to

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.

> 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.)

 > We're addressing this

I'd be very interested in seeing that.

Regards,
Stephen.

---

From: Radia Perlman <[email-masked]>
Date: Mon, 27 Jun 2005 10:01:32 -0700

Can you give a URL for "that I-D"? From Stephen's description, it sounds 
like an active attacker
would have an opportunity for a dictionary attack. Also, using TLS might 
be more
heavyweight than necessary. A pure credentials download protocol with no 
dictionary attack
can be done with two messages, and small enough messages that it could 
be done on top of UDP
without fragmentation.

Radia

Stephen Farrell wrote:

>>> equivalent

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jun 2005 18:13:55 +0100

Hi Radia,

Sorry, I should have included the URL [1] before.

Stephen.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 28 Jun 2005 16:46:39 +1200

Stephen Farrell <[email-masked]> writes:

>As I read it, that works by basically appending a (hashed?) password to a D-H
>derived key (with some length fields) and using the resulting value as the
>TLS pre-master key. Presumably the handshake falls over at the finished
>message if the wrong password was used.

Yup.  Or you can use RSA (without the heavyweight DH on the client-side), or
just a plain shared key.

>I'll have to read that I-D again and think about whether it really is better
>than the current sacred scheme

Well, I don't know about technically better, but it does more or less the same
job, it's unencumbered, and it's tuneable for low-powered devices.  It's most
importantly property however is that it's a TLS standards-track mechanism,
which means that it actually exists (i.e. it's implemented and eventually,
it's hoped, widely deployed).

Peter.

---

From: Magnus Nystrom <[email-masked]>
Date: Tue, 28 Jun 2005 12:07:15 +0200 (W. Europe Daylight Time)

From the surface, though, it seems as if the SPEKE scheme and/or Radia & 
Charlie's new scheme (if at least one of these schemes can be used as 
"unencumbered," i.e. without requiring a license from somewhere) would be 
better suited for SACRED than TLS-PSK since (and correct me if I am wrong 
here):

a) It would make SACRED more independent on its transport, perhaps even
    allowing it to work on top of UDP or other connection-less transports.
    It would be nice, I think, not to have to rely on transport-provided
    security services.

b) The number of roundtrips would be smaller.

c) We would get protection against active attackers (admittedly,
    throttling or similar protection mechanisms could perhaps be used
    in the case of PSK-TLS) as well as passive ones (TLS-PSK basic mode).

d) TLS-PSK with server-side RSA-based authentication obviously requires a
    PKI, whereas the alternatives would not.

e) As I understand it, TLS-PSK with D-H where the PSK is a password or
    derived from one allows an active attacker (posing as the server) to
    learn information that will allow for a later, off-line dictionary
    attack, whereas the alternatives would not.

Don't you think it would be useful, also for the IETF as a whole, if we 
could determine whether at least one of the mentioned schemes are usable 
for SACRED ("usable" in the sense discussed here)?

-- Magnus

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 28 Jun 2005 22:18:04 +1200

Magnus Nystrom <[email-masked]> writes:

>Don't you think it would be useful, also for the IETF as a whole, if we could
>determine whether at least one of the mentioned schemes are usable for SACRED
>("usable" in the sense discussed here)?

I see it as more a pragmatic tradeoff.  Uhh, not to put too fine a point on
it, but SACRED hasn't really taken the world by storm (this is why I started
with the disclaimer saying that I hadn't actually implemented it myself).
TLS-PSK is a trivial mod to existing TLS implementations, which seem to be
almost everywhere (I saw a report of an implementation on a smart card
recently).  Piggybacking on top of that, rather than requiring a completely
new implementation for what's already a seldom-used protocol, seems to be an
easy way to solve the problem.

Peter.