Ability to specify SASL authorization identity #feature-request

[Savageman]

I request this

In the RFC 4616 the Plain SASL Mechanism defines 3 parts:

• authzid: the authorization identity (identity to act as)
• authcid: the authentication identity (identity whose password will be used)
• passwd: the clear-text password

The authzid is optional and the server should derive it from authcid if not provided (The client is also free to re-use the same value as authcid when building the authentication string).

Right now it looks like CURLOPT_USERPWD (user:pwd) will use authzid=user authcid=user and passwd=pwd when building the authentication string (or maybe it omits the authzid, I'm not sure since I didn't find the code associated with that feature).

It looks like cURL has no way of using an authorization identity (to act as) different than the authentication identity. This is sometimes required, for example to connect to an O365 shared inbox (the inbox is the identity to act as, but is access using the identity of a real user account).

Possible implementations (suggestions)

1. Add a new option to set this authzid / act_as thing
2. Extend the existing CURLOPT_USERPWD to allow specifying the identity to act as in addition to the user/password (e.g. act_as:user:password).

[jay]

Ref: https://curl.haxx.se/mail/lib-2019-02/0127.html

[captain-caveman2k]

I've updated the function signature of the PLAIN message creation function to allow us to pass authorisation identity separately to the authentication identify - in PR #3757.

The calling code simply passes the connection's username into both the authzid and authcid parameters to maintain current functionality at present.

To add this feature, I believe we need to somehow pass the two identies separately now...

The questions I have:

1. How do we pass the authorisation identity to libcurl. We could:

• Extend user/pass though that would break existing behaviour if we use a separator that current users are using in their passwords.
• Add a new option as we currently have CURLOPT_USERNAME, CURLOPT_PASSWORD and various options for GSS-API, OAuth, etc...

2. What should libcurl do if the authzid is not specified:

• Use the username as it currently does?
• Derive authzid as the RFC indicates?

3. If it derives the authzid, how does the calling application obtain it back?

Note: As this operation is performed in the main SASL authentication code it will affect other protocols such as SMTP and POP3 and not just IMAP.

[bagder]

Thanks, but this description sounds as if you're asking for a new feature/change. We use this tracker for bugs and issues only, we put ideas to work on in the future in the TODO document. We basically drown in good ideas so they don't do much use in our tracker.

So, this issue will be closed soon.

[Savageman]

Would it still be possible to be updated here once it's implemented? Thanks a lot @captain-caveman2k for making progress :)

(I flagged as feature request since the label exists, which is strange if you don't accept them here. But we could argue that non-respect to RFC is a bug.)

[bagder]

We have the label here since we can't prevent people from submitting feature-requests even if we wanted to, and when we do get them, we flag them accordingly.

Would it still be possible to be updated here once it's implemented

It depends. We auto-lock closed issues after N days (which prevents users from commenting further in them) so it will depend on when/if such an implementation is done. But presumably if this is worked on further, it will be done with new pull-requests and it will even appear in a changelog down the line if it lands in master...

[captain-caveman2k]

I'm happy to work on the implementation of this - as I've already worked on the email protocols quite a bit since 2011 (not so much over the last 2 years though - so here I am trying to get back into curl://development as I still enjoy developing as a pass time).

Does anyone have any views/input on my questions above?

[Savageman]

I'm not a member, so forgive me for exposing my POV if it's not appropriate.

I would stay BC as much as possible so:

1. I would use a new option (you definitely convinced me when you mentioned you already have a few of them for other auth options).
2. My understanding is that it's not the client that derives the identity, but the server. The client can "ask" the server to derive it by not providing it. So the default to providing it with the same value as the username seems good, but the new option should support being "empty" to let that happen.

As with other SASL mechanisms, the client does not provide an authorization identity when it wishes the server to derive an identity from the credentials and use that as the authorization identity.

[captain-caveman2k]

Ah yes - I had missed the fact that it was optional :(

I now see from the RFC that we would, in that case, simply specify the following:

UTF8NUL authcid UTF8NUL passwd

Then the server will derives the authorization id. From what I can see, there doesn't appear to be a way of the server telling the client what that derived id is - so in that respect we don't need an API to extract it from libcurl.

So in summary I think a new string option such as CURLOPT_SASL_AUTHZID in lib curl (and an appropriate command line option in curl) to be able to specify this. At present I can't see any existing options that we can hijack but if anyone has any suggestions for an alternative/more generic name please feel free to make them.

[captain-caveman2k]

I've added my first patch set in PR #3790.

Please note it is not yet complete - but it gives you an idea of what I think we need.