Subject: Re: DRAFT minutes, SACRED WG, Minneapolis IETF

From: "Yongge Wang" <[email-masked]>
Date: Mon, 26 Mar 2001 14:52:27 -0500

> Next, IPR issues were considered.  Magnus noted that an IPR statement for
> SRP has been posted on the IETF web page. Ted Ts'o commented that the SRP
> statement, authored by Thomas Wu, seems rather informal, and considered that
> it might be better to have something authoritative from Stanford.  Thomas Wu
> responded, indicating that the terms as posted can be documented as
> Stanford's policy.  Radia Perlman and Charlie Kaufman (Iris) have previously
> stated their goal and intent that PRM be unencumbered.  Steve Bellovin
> stated that EKE and DH-EKE are covered by a Lucent-controlled patent; he has
> no contact or influence with those responsible for licensing, but believes
> that licensing under some terms would probably be possible..  Steve also
> commented that SRP might arguably infringe on the EKE patent, and suggested
> that this should be investigated.  Ted Ts'o pointed out that the fact of IPR
> claims covering SPEKE is generally known

If none of the protocols is patent free, why we do not make the following
choice:
The requirement and standard do not specify any algorithm, leave it as a
black-box... And the standard should be general enough so that most of the
algorithms could be implemented (each algorithm should have a unique
identifier).

Regards,
Yongge

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Mar 2001 11:45:17 +0100

> algorithms could be implemented (each algorithm should have a unique

We MUST end up with an interoperable protocol. That means choosing one
of everything that can be chosen, including authentication schemes as
the mandatory-to-implement. We will ensure that implementations are
able to flag other options (and might even generate some WG documents
about them). 

One your second note, my interpretation would be that PDM doesn't
have to support multiple types of cryptography like ECC, since 
from the sacred perspective, PDM itself is an algorithm (i.e. if you
had an EC variant, it wouldn't be PDM, but PDM-EC or something).

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

---

From: Yongge Wang <[email-masked]>
Date: Tue, 27 Mar 2001 12:59:53 -0500 (EST)

> able to flag other options (and might even generate some WG documents

Then it might be a little hard. Since it will depend on the
main user of SACRED of future. That is, the client devices are mainly
desktop computers or handheld devices (generally power, bandwidth,
computation ability constraint)? That will be the crucial factors
for choosing the algorithms. I do not think one Palm-user would like
to wait there for three minutes to establish the connection with
the server (the authentication or key exchange is quite slow
for some algorithms) and then download his/her credentials
(e.g., private signature key).
 
> had an EC variant, it wouldn't be PDM, but PDM-EC or something).

Thanks! I agree with you.

Regards,
Yongge

-----------------------------------------
Yongge Wang --- Cryptologic Mathematician
http://cs.uwm.edu/~wang/    Certicom Corp.
-----------------------------------------

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Mar 2001 11:22:19 +0100

> (e.g., private signature key).

I'm agree we cannot specify a basic sacred protocol (selecting transport,
authentication scheme & cred format) that will work everywhere.
We do have to pick a combination to ensure basic interoperability.
That combination should be suitable for a wide range of use
cases, but should not (IMO) be driven by the "hardest" use 
cases. 

For devices where its just not possible (or sensible) to
conform to the basic sacred protocol, you can separately specify 
(i.e. in another RFC) some partial level of interopability. For
example, handling the basic credential format and transport,
but a different authentication scheme. Assuming you can find a 
credential server that supports both the basic sacred protocol and
the putative additional RFC, that would be enough to allow you
to move credentials between the typical and more limited devices.

Lastly, I'm not sure how much we should take today's handheld device 
limitations as constraining us, given that sacred implementations 
won't be deployed for a while and better devices come along all the
time (btw: anyone know the average lifetime of palms & similar?)

Stephen.