Digest md5: Use hostname to generate spn instead of realm

[kop316]

Fixes #11369

In https://www.rfc-editor.org/rfc/rfc2831#section-2.1.2

digest-uri-value should be serv-type "/" host , where host is

  The DNS host name or IP address for the service requested.  The
  DNS host name must be the fully-qualified canonical name of the
  host. The DNS host name is the preferred form; see notes on server
  processing of the digest-uri.

Realm may not be the host, so we must specify the host explicitly.

This fixes an issue I have seen where DIGEST-MD5 does not work for the Visual Voicemail Server (and presumably fixes the other one references in the issue).

[kop316]

I added the response auth in the modified tests that should be included per https://www.rfc-editor.org/rfc/rfc2831#section-2.1.3 . It looks like curl does not check that response auth.

[bagder]

According to feedback in #11369, this does not solve the issue...

[kop316]

According to feedback in #11369, this does not solve the issue...

Yeah I unfortunately saw that. What I can say is this PR does fix DIGEST-MD5 login for me, so I have no further way of trying to diagnose/fix it for @MonkeybreadSoftware . I gave a couple of ideas of how to fix it in #11369 (comment) , maybe those will wok.

I also saw this is identical to what is in digest-sspi.c https://github.com/curl/curl/blob/master/lib/vauth/digest_sspi.c#L140 (though I am admittedly not sure what the difference is between digest_sspi.c and digest.c. This also looks to be more correct versus what is there now (as I referred to here: #11395 (comment) ).

I welcome any other thoughts on what you think should/can be done.

[jay]

though I am admittedly not sure what the difference is between digest_sspi.c and digest.c

digest_sspi.c uses the Windows SSPI API that is enabled in some Windows builds. Both digest.c and digest_sspi.c should format the spn as "service/host" if passed service and host strings.

git blame puts it at 9feb267 (check its comments) when, prior to that, to build spn there was only one parameter for host and realm called 'instance'. You can see since then for some calls the host is passed as the realm, but in this one case here the realm is passed as the host. I still don't know why that is. Essentially, that commit changed the format. (edit:actually format looks the same, it would have been service/realm) @captain-caveman2k

[kop316]

@jay If I am reading https://www.rfc-editor.org/rfc/rfc2831#section-2.1.2 correctly, realm is not the same as host, and realm goes into realm-value when calculating A1. the digest-uri-value = serv-type "/" host [ "/" serv-name ] (here it is the spn) should be the host instead (which is what my PR here was attempting to correct). That was why I was confused about digest_sspi.c and digest.c being different, digest_sspi.c looks to correctly calculate the spn value.

Actually when looking at 9feb267 , almost every other one looks to use host as well. (EDIT: Sorry I think you noticed that as well in your comment.) I tried looking back, but it looks like it was always realm for this calculation, and I don't know why either.

Perhaps I am reading the RFC wrong?

[kop316]

So for a different IMAP server for visual voicemail, they are able to successfully login with the current DIGEST-MD5.
the URL is imaps://vvm.mobile.att.net/INBOX?ALL, realm is bothwaacds03.attwireless.net, digest-uri imap/bothwaacds03.attwireless.net .

However, in Android's actual code, They appear to use the host for the digest-uri : https://cs.android.com/android/platform/superproject/+/master:packages/apps/Dialer/java/com/android/voicemail/impl/mail/store/imap/DigestMd5Utils.java;l=81

And as I annotated here: #11369 (comment) the different realm is not functional for me in DIGEST-MD5.

So perhaps the realm is used some of the time for DIGEST-MD5, but I am just not sure?

[jay]

My best guess as to what happened here is the dev assumed that the realm would be a more formal host (like maybe they assumed with a hostname of p012384093214.mail.test.com and a realm of mail.test.com that it would make more sense to send the latter, and did not consider a realm format of group@host, because as far as I can tell the RFC doesn't allow an spn of imap/group@host. I haven't found any discussion about it.

You said in the other thread you had a realm of imap/realm@mavenir.com and I'd be interested if imap/mavenir.com works for you instead. Regardless I think your change here is correct because it follows the RFC so I plan to commit it. If this breaks something for somebody possibly we'd have to change it to imap/<host>/<realmhost> if I'm reading it right...

So for a different IMAP server for visual voicemail, they are able to successfully login with the current DIGEST-MD5.
the URL is imaps://vvm.mobile.att.net/INBOX?ALL, realm is bothwaacds03.attwireless.net, digest-uri imap/bothwaacds03.attwireless.net .

In that case what happens if you send spn imap/vvm.mobile.att.net does it work?

[kop316]

You said in the other thread you had a realm of imap/realm@mavenir.com and I'd be interested if imap/mavenir.com works for you instead.

I tried imap/mavenir.com as the digest-uri, that does not work.

Regardless I think your change here is correct because it follows the RFC so I plan to commit it. If this breaks something for somebody possibly we'd have to change it to imap/<host>/<realmhost> if I'm reading it right...

I also tried this, and make the digest-uri imap/e5.vvm.mstore.msg.t-mobile.com/mavenir.com, that does not work as well

So for a different IMAP server for visual voicemail, they are able to successfully login with the current DIGEST-MD5.
the URL is imaps://vvm.mobile.att.net/INBOX?ALL, realm is bothwaacds03.attwireless.net, digest-uri imap/bothwaacds03.attwireless.net .

In that case what happens if you send spn imap/vvm.mobile.att.net does it work?

I actually worked with someone to try this out. I will see if I can get them to try it out and see if it works.

[kop316]

@jay The user was successfully able to log into the IMAP server with spn imap/vvm.mobile.att.net, so this patch works for both cases I know of.

As an aside, AT&T built their own proprietary app for accessing their IMAP server in Android. I sort of wonder if they use curl as a backend and just worked around this issue?

[jay]

Thanks

As an aside, AT&T built their own proprietary app for accessing their IMAP server in Android. I sort of wonder if they use curl as a backend and just worked around this issue?

If it's proprietary it's hard to say...