headers
David Taylor | 2 Aug 2002 12:55
Picon

Reviving the SRP internet draft

Hi all,

I am writing to ask the list's opinion on the idea of using SRP
authentication in TLS. The draft went through a couple of revisions and
caused some active discussion when it appeared but then it seemed to die
off.

I believe the idea of a safe username and password based authentication
scheme for TLS is ideal for a lot of applications TLS is being put into
(TELNET, POP, IMAP, etc). It also fits nicely with a lot of web based
applications, most of which require usernames and passwords after
establishing a TLS connection.

The draft was certainly implementable - Nikos put it in GNU TLS and I
implemented it in two different Java TLS libraries (neither of which I can
release yet).

So, does the group believe the draft would make TLS more usable? What are
the arguments for not adding the handshake extensions and cipher suites
defined by the draft?

If I submit a new version of the draft that adheres to the latest extensions
ideas (hopefully RFC by the time I have updated the SRP draft) would it get
the support of the group to advance to an RFC?

Regards,
David Taylor.

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Taylor | 2 Aug 2002 13:07
Picon

SPEKE and TLS/SRP

Hmmm, I've just been reading the ietf-sacred list archives and see various
people are worried about patents do to with SRP.

The one good idea I've ever had and now this! Tom - how is this affecting
SRP in other products?

Any comments on this patent business? Is it just too much hassle to deal
with a company even threatening to sue over a patent violation?

If you are responsible for a TLS implementation, would you be willing to put
SRP into your next version?

Regards,
David.

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com
Permalink | Reply | 0 comments |
headers
Tom Wu | 2 Aug 2002 21:08
Favicon

Re: Reviving the SRP internet draft

David Taylor wrote:
> Hi all,
> 
> I am writing to ask the list's opinion on the idea of using SRP
> authentication in TLS. The draft went through a couple of revisions and
> caused some active discussion when it appeared but then it seemed to die
> off.

IIRC, rough consensus on the major issues was reached and interest 
drifted to other topics.  This would be a good opportunity to move 
forward from there, and see if there are any new issues anyone might have.

> I believe the idea of a safe username and password based authentication
> scheme for TLS is ideal for a lot of applications TLS is being put into
> (TELNET, POP, IMAP, etc). It also fits nicely with a lot of web based
> applications, most of which require usernames and passwords after
> establishing a TLS connection.

Yes, don't forget HTTP - this would be a good alternative to basic HTTP 
auth and passwords in Web forms, and would fit in a lot of places where 
client-authenticated SSL certs would be impractical.

> The draft was certainly implementable - Nikos put it in GNU TLS and I
> implemented it in two different Java TLS libraries (neither of which I can
> release yet).
> 
> So, does the group believe the draft would make TLS more usable? 

In general, SRP-in-TLS would be a compelling solution for new 
products/protocols that needed strong password authentication and
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Taylor | 3 Aug 2002 02:34
Picon

SRP patents - sorry for bringing it up

Hi all,

I apologise for trying to discuss the SRP patent on the list, given it has
been discussed elsewhere already.

I will leave the topic alone until both the consequences of using SRP-3 and
SRP-4 are clear to me. It seems other workgroups have already had to deal
with this, so I will ask their advice.

Regards,
David Taylor.

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 3 Aug 2002 09:09
Picon
Picon
Picon
Favicon

Re: Reviving the SRP internet draft

"David Taylor" <dtaylo11 <at> bigpond.net.au> writes:

>I believe the idea of a safe username and password based authentication scheme
>for TLS is ideal for a lot of applications TLS is being put into (TELNET, POP,
>IMAP, etc). It also fits nicely with a lot of web based applications, most of
>which require usernames and passwords after establishing a TLS connection.

I've had a few requests for this as well, but the problem is that you run into
patents whichever way you try and go.  AFAIK the scheme done by the IBM
Research guys in Zurich seemed to be the cleanest, but that was also subject to
possible patent problems.

>If I submit a new version of the draft that adheres to the latest extensions
>ideas (hopefully RFC by the time I have updated the SRP draft) would it get
>the support of the group to advance to an RFC?

I'd certainly support a password+DH mechanism as a TLS cipher suite, whatever
form it takes.

Peter.

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com
Permalink | Reply | 0 comments |
headers
David Taylor | 3 Aug 2002 10:15
Picon

Re: Reviving the SRP internet draft

Hi Peter,

> I've had a few requests for this as well, but the problem is that you run
into
> patents whichever way you try and go.  AFAIK the scheme done by the IBM
> Research guys in Zurich seemed to be the cleanest, but that was also
subject to
> possible patent problems.

I have learned this over the past couple of days. I have written to Pheonix
and Lucent to ask their license terms, but have essentially given up. If
they don't give a free license for anyone who asks I can't see the IETF
being interested.

I guess the IP store people still have SRP in their specs, but who is going
to bother implementing it with these clouds over it?

What is really frustrating is the attitude of Lucent and Pheonix, who won't
even give a straight submission to the IETF. The wording is very obtuse but
seems to mean "we'll see what we can get away with in each case and charge
that". This leaves open source people high and dry, and it is even too much
trouble for commercial closed source products. I remember trying to get
licensing terms out of RSA a couple of years ago and it turned into a
coversation whereby they said "drop your product and sell ours"!

Time to go find some other area to work in. Patents and export laws - this
crypto business is a bad joke :(
Regards,
David.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 3 Aug 2002 10:46
Picon
Picon
Picon
Favicon

Re: Re: Reviving the SRP internet draft

"David Taylor" <dtaylo11 <at> bigpond.net.au> writes:

>I have learned this over the past couple of days. I have written to Pheonix
>and Lucent to ask their license terms, but have essentially given up. If they
>don't give a free license for anyone who asks I can't see the IETF being
>interested.

I've talked to someone at Phoenix and had more or less the response you had -
they're happy to see it languish in obscurity rather than risk having a single
person actually (shock, horror) use it without paying them (they have a tiny
number of commercial licensees which they're using to justify this stance).  As
far as I'm concerned if they want their algorithm ignored (except as an
academic exercise) they're quite welcome to do so, but the annoying thing is
that the patent is broad enough, and they're large enough, that they can use it
to intimidate anyone else wanting to do something similar.  It's frustrating to
think they there may be no way we can get a password-based cipher suite until
about 2015 or so because of this.

Peter.

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com
Permalink | Reply | 0 comments |
headers
David Taylor | 3 Aug 2002 10:47
Picon

Re: Reviving the SRP internet draft

Hmmm, I must check my reply addresses - apologies to all.

Regards,
David.

----- Original Message -----
From: "David Taylor" <dtaylo11 <at> bigpond.net.au>
To: "IETF Transport Layer Security WG" <ietf-tls <at> lists.certicom.com>
Sent: Saturday, August 03, 2002 6:15 PM
Subject: [ietf-tls] Re: Reviving the SRP internet draft

> Hi Peter,
>
> > I've had a few requests for this as well, but the problem is that you
run
> into
> > patents whichever way you try and go.  AFAIK the scheme done by the IBM
> > Research guys in Zurich seemed to be the cleanest, but that was also
> subject to
> > possible patent problems.
>
> I have learned this over the past couple of days. I have written to
Pheonix
> and Lucent to ask their license terms, but have essentially given up. If
> they don't give a free license for anyone who asks I can't see the IETF
> being interested.
>
> I guess the IP store people still have SRP in their specs, but who is
going
> to bother implementing it with these clouds over it?
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Hopwood | 3 Aug 2002 18:08
Picon

Re: CBC Fix Round 2: Explicit IVs


Eric Rescorla wrote:
> After going over the discussion of CBC in June, I propose we
> make the following change for TLS 1.1.
> 
> (1) BlockCipher becomes:
> 
>     block-ciphered struct {
>         opaque iv[block size];
>         opaque content[TLSCompressed.length];
>         opaque MAC[CipherSpec.hash_size];
>         uint8 padding[GenericBlockCipher.padding_length];
>         uint8 padding_length;
>     } GenericBlockCipher;

A minor problem with this is that it doesn't guarantee that no
information is leaked about the padding length (modifying the padding
does not change the MAC). OTOH, changing that would probably break the
compatibility with existing hardware.

> (2) The IV must be pseudorandomly generated. We suggest but do
> not require that you use one of the following methods.
> 
>     (a) Pseudo-randomly generate the IV.

In this case the IV must not be predictable (i.e. distinguishable
from a uniform distribution).

>     (b) Pseudo-randomly generate a dummy plaintext block and
>         encrypt it as the first plaintext block. (This has
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 3 Aug 2002 20:41

Re: CBC Fix Round 2: Explicit IVs

David Hopwood <david.hopwood <at> zetnet.co.uk> writes:
> Eric Rescorla wrote:
> > After going over the discussion of CBC in June, I propose we
> > make the following change for TLS 1.1.
> > 
> > (1) BlockCipher becomes:
> > 
> >     block-ciphered struct {
> >         opaque iv[block size];
> >         opaque content[TLSCompressed.length];
> >         opaque MAC[CipherSpec.hash_size];
> >         uint8 padding[GenericBlockCipher.padding_length];
> >         uint8 padding_length;
> >     } GenericBlockCipher;
> 
> A minor problem with this is that it doesn't guarantee that no
> information is leaked about the padding length (modifying the padding
> does not change the MAC).
As long as you change it in block size increments, right?

> OTOH, changing that would probably break the
> compatibility with existing hardware.
Yeah.

> > (2) The IV must be pseudorandomly generated. We suggest but do
> > not require that you use one of the following methods.
> > 
> >     (a) Pseudo-randomly generate the IV.
> 
> In this case the IV must not be predictable (i.e. distinguishable
(Continue reading)

Permalink | Reply | 0 comments |

Gmane