>
> > I see a small problem in the user friendliness of the interface to curl: If
> > -u is used for both basic auth and srp auth, this may result in a srp
> > password transferred in clear if the user forgets to specify --srp, etc.
> >
> > I tend to prefer simply --srpuser user --srppass password
>
> I agree with this.

It could also be --tlscredential user:password -tlsauth srp
or --tlsident user -tlssecret password -tlsauthtype srp

following you comments below.

>
> I assume we then enable SRP authentication if the CURLOPT_SRP_USERNAME is set?

Yes. It also requires that in the lib somehow one has to provide the
'secret'/password. Since an application can also use the general ssl
initialisation call back to register a password callback, etc...
 

> Is there any other authentication method possible to add in a (distant) future
> OpenSSL? I mean, would it make sense to instead use CURLOPT_TLS_USERNAME and a
> CURLOPT_TLS_AUTH to set to SRP etc?

That is a good question. The current state in the ietf-tls group is that
the releveant text is in draft status, and there may be some problems
with patent issues. There may thus be some other algorithmns which would
more or less fit into TLS in the same exchange of message but with other
cryptographic algorithm. these are my personal guesses.

It is indeed be more "open-ended" to have options as you describe above.

What I see is that there is no urgent hurry to have an integration into
the curl main stream. The modification is rather simple, and I will
maintain it against curl releases as long as necessary ...
 
> Also, what is the status of the SRP OpenSSL patch? Is gonna be applied into
> the head and get included in an actual release anytime soon? It seems we don't
> have any hurry to support this in the main code until that happens... (I'm
> thinking in terms of postponing the SRP patch for the next release.)

...and, in fact, I was somewhat surprised/pleased (any word is bad here)
that you proposed to integrate the patch into the next release. :-)

So far, I have not had much feedback from the openssl team, I am not
urging them, they are volunteers as well. The problem here is much more
difficult, since it covers some thousands of lines of code, and it may be
that some internal apis etc need to be changed.

It seems that we could be able to get agreement that our patch is
currently in an experimental status, and that we should wait at least
one round. Since curl versions appear often enough, our patch
doesn't get too much outdated, anyway.

regards
Peter
Received on 2004-10-05