Re: New work for sacred working group?

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