Subject: comments on minutes

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Thu, 29 Mar 2001 13:03:33 -0500 (EST)

Stephen pointed out I didn't manage to CC the list, so I'll
forward the mail I sent to him.

Radia

------------- Begin Forwarded Message -------------

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Subject: Re: DRAFT minutes, SACRED WG, Minneapolis IETF
To: [email-masked]
Mime-Version: 1.0
Content-MD5: UeoEfh/i4m0N0n1+e6zOTg==

>PDM was considered
> weaker in terms of client CPU requirements and ease of implementation, but
> stronger in terms of number of communications roundtrips. 

Not quite, since it certainly isn't a problem for "ease of
implementation". Perhaps you're saying it hasn't been implemented
yet? But it wouldn't be harder to implement. Eric Rescorla implemented
the prime generation, and the rest of it is just a Diffie-Hellman
exchange using that prime. How about:

PDM was considered weaker in terms of client CPU requirements,
but better in terms of server CPU requirements than any of
the other schemes. EKE, SPEKE, and PDM can be done in one
round trip with stateless server operation, whereas SRP and
the versions of EKE and SPEKE augmented not to require storing
a password-equivalent at the server (which Radia argued is not
an important property for a credentials download protocol) requires
a 4-message exchange.

------------- End Forwarded Message -------------

---

From: Tom Wu <[email-masked]>
Date: Thu, 29 Mar 2001 12:24:13 -0800

> exchange using that prime. How about:

I think the difficulty of implementation arises partially from the lack
of (currently available) specifications.  Where do you start looking for
safe primes?  How big is the range?  How is the hint implemented?  How
do you thwart timing attacks?  Is there reference-quality code out
there?  As it stands today, a developer would have no idea how to begin
to make a PDM-compliant client, and it's not completely clear that all
the issues will go away eventually.  The issue is more easily tackled
once an apples-to-apples comparison to other technologies is available.

> but better in terms of server CPU requirements than any of

The server CPU benefit is derived entirely from the use of a shorter
modulus, so that should be considered as more of a conditional benefit
for those willing to take the tradeoff.

> an important property for a credentials download protocol) requires

It may be important if you want a unified authentication framework that
powers both a credential server and secure remote access.  I don't know
how important that is for SACRED, though.

> ------------- End Forwarded Message -------------

Tom
-- 
Tom Wu
Principal Software Engineer
Arcot Systems
(408) 969-6124
"The Borg?  Sounds Swedish..."

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Mar 2001 11:58:42 +0100

Hi Radia,

> EKE, SPEKE, and PDM can be done in one

Assuming I've interpreted the clauses correctly, can you elaborate 
on why "not storing a password-equivalent at the server...is not 
an important property for a credentials download protocol"?

If true, this is a fairly interesting difference!

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com