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
