Steve Holme wrote: >> sasl: implement EXTERNAL authentication mechanism.
> * 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. 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. > * Are there other EXTERNAL mechanisms that can be used rather than client > certificates? See above... and imagine :-) > * 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. To use sasl external with the current curl implementation you have to specify URL as scheme://[user];AUTH=EXTERNAL@host... Not using AUTH= or specifying a non-empty password disables EXTERNAL. Now I would like to implement SCRAM-SHA-1 ... :-)) Cheers, Patrick
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
