On Wed, 28 Jan 2015, Patrick Monnerat wrote:

> > * Do we need to limit this to TLS upgraded sessions - the examples
> > in the RFC seem to use this as the EXTERNAL authentication
> > mechanism?
>
> No, we should not: the spec tells this is not limited to TLS.

I must have missed that :(

> Some other external auth may be based, for example, on connecting
> IP address (i.e.: via a radius server or else). May be you may think of
> other identification ways. In practice, i've never seen EXTERNAL in
> non-TLS cases.

Cheers - that's useful to know.

> > * Should we implement support for an empty authentication identifier
> > (via an empty username) as I believe is allowed in the RFC or do your
> > modifications already cater for this?
>
> Yes, and it's currently done this way. In TLS cases, empty username tells
to
> use id from cert. Using a non-empty username can only be used if the
server
> allows to delegate authorizations, such as an administrator acting for a
normal
> user. I've never seen such an implementation, but curl supports it.

That's what I thought. In the SASL code is it the
Curl_sasl_can_authenticate() that allows this?

> Now I would like to implement SCRAM-SHA-1 ... :-))

Cool - I've got GSS-SPNEGO on my list which I hope to add over the coming
months ;-)

Kind Regards

Steve
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-01-29