SRP Patch Integration?

[Tom Wu]

Dan Kaminsky wrote:
> 
> > Are you referring to the distinction between SRP and SRP-Z?  The SRP
> > userauth mechansim is specifically based on RFC2945, which is
> > royalty-free, and does not use SRP-Z in any way.  Or were there some
> > other "restrictions" you were concerned about?
> 
> This is an uncomfortable situation for me, as I was one of the major
> champions of getting SRP in.
> 
> My concern is that we have a "license" for integrating SRP in one specific
> way, but the more we do to use it in new and interesting ways, the more we
> leave the purview of what Stanford will allow us to do.

Perhaps I can clarify.  The royalty-free license isn't quite that
narrow.  I decided to make the SRP/SRP-Z distinction because I felt that
the distiction was fairly fundamental, with differing fields of use.  By
drawing the line where I did, my intention was to make it trivial to
determine what is free and what isn't without having to consult experts.

Again, remember that this has always been the case with public-key
crypto.  If OpenSSH were to explore, for example, ECC, you'd be likely
to find an even more tangled web of IP issues; at some point, reasonable
decisions have to be made in good faith for any progress to occur.

> I'd like to use SRP to authenticate unknown host keys, for instance.  Is
> that a new use?  Is it arguable?

It clearly and unarguably falls under the royalty-free terms.

> Tom, I know the bar has been raised on you repeatedly, and every time you
> manage to overcome one hurdle, another one pops up.  And that sucks, alot,
> because SRP has a gynormous amount of potential.  (If there wasn't such a

Yes, that's exactly what I'm objecting to.  I'm a pretty staunch OSS
advocate - I put together the SRP distribution under a BSD license - so
it bothers me to see others on the same team, as it were, seeming to
prefer stagnation instead of making reasonable judgements about new
technology.  I object to the obvious double-standards at work here,
though it seems that at least some of them stem from one developer's
personal experiences instead of from the community as a whole, so I
guess I don't feel so bad about being singled out for unwarranted
criticism.

> feeding frenzy for the vaporware profits of certificate management, your
> system would be *the* standard).  But I see Theo's worry:  The moment we
> start using the SRP protocol a tiny bit outside the expected uses mentioned
> in the RFC, we *might* fall out of compliance.

Remember, although the license mentions the RFC, it does so only as a
concrete, absolute example of what is free, and does not attempt to
limit coverage to the RFC.  If there is ever a question about the
license, however, I have expressed my commitment to answering all such
questions in good faith, since I'd rather see design decisions made by
engineers, not lawyers.

> Yours Truly,
> 
>     Dan Kaminsky
>     DoxPara Research
>     http://www.doxpara.com

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