Re: New work for sacred working group?

Hi Jim,

Jim Basney wrote:

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

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

I'd be very interested in seeing that.

Regards,
Stephen.


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