Bug: crate fails to parse NTLM authentication schemes (by design)

[xanathar]

Implementation notes say:

Doesn't allow token68, which as far as I know has never been and will
never be used in a challenge:

• RFC 2617 never
  allowed token68 for challenges.
• RFC 7235 Appendix
  A says
  token68 "was added for consistency with legacy authentication
  schemes such as Basic", but Basic only uses token68 in
  credential, not challenge.
• RFC 7235 section
  5.1.2
  says "new schemes ought to use the auth-param syntax instead
  [of token68], because otherwise future extensions will be
  impossible."
• No scheme in the registry
  uses token68 challenges as of 2021-10-19.

NTLM authentication headers are in the form:

Proxy-Authenticate: NTLM Q29udGVudCBoYXMgYmVlbiByZWRhY3RlZA==

(here as a Proxy-Authenticate because it's the sample that I have, but it's also sent as a WWW-Authenticate by IIS server on a domain intranet afaik).

Being in that form, they require token68 compliancy as per RFC-7235 because / and = are among the characters used by base-64 and allowed by token68 and disallowed by RFC 7230/3.2.6.

---

Now, I can try to contribute the change, but:

1 - before I jump to implementation, I want to know if the contribution will be welcome as it diverges from one design tenet (but closes some gap with RFC implementation)

2 - is there any part of the parser that relies on the missing support for token68 in order to work that I have to be aware of?

[scottlamb]

Where is NTLM specified? It's not listed in the registry.

1 - before I jump to implementation, I want to know if the contribution will be welcome as it diverges from one design tenet (but closes some gap with RFC implementation)

Yes, and thank you for offering! NTLM wasn't on my radar, so I didn't know its challenge scheme used token68. I could see demand for parsing credential stuff anyway for server implementations and maybe we could just use the same code for both; IIRC the only difference between them then is that challenge is a list.

2 - is there any part of the parser that relies on the missing support for token68 in order to work that I have to be aware of?

Don't recall. The parser is a bit messy; my trick to modify it without introducing bugs is to run the fuzz tests comparing it to the nom-based reference implementation.

If adding the token68 support is too hairy with the hand-rolled state machine, I might be open to switching to a zero-dep parser combinator approach like www-authenticate does, giving up the single-passedness for more straightforward code.

Making http_auth::ChallengeRef be like an enum with a token68 option will be a breaking API change but that's fine; we can go to 0.2.0, and there are a couple other minor things I've deferred for that anyway (see #1).

[xanathar]

Where is NTLM specified? It's not listed in the registry.

As far as I'm aware, there are no RFCs on it (thanks Microsoft!) and it's very proprietary and against the spirit of statelessness of http.

A pointer to it is, for example, this constant in Chromium and obviously all the source code that uses it.

Now, after thinking on the problem a little bit more, I'm not sure this is needed to use this crate to support NTLM, but for certain it might be required.

The NTLM protocol works as this:

• Client connects and sends to Server/Proxy an http request
• Server/proxy replies with 401/407, and www-authenticate/proxy-authenticate of NTLM along with possibly other authentication methods and closes the connection
• Client connects sending an authorization of NTLM <handshake-base64> where handshake-base64 contains versioning information
• Server/proxy replies with 401/407, and www-authenticate/proxy-authenticate of NTLM <base64-challenge> where base64-challenge is the infamous blob that requires token68
• Client replies with NTLM <token-base64> where token-base64 is some complicated hash of the password over the previous challenge

Given the above, the client sort of expects the moment where www-authenticate/proxy-authenticate contain the challenge, and I don't think it makes sense to list other authentication methods in that state.

So, in summary, even for the corner case of NTLM token68 is probably welcome but not absolutely needed.

Don't recall. The parser is a bit messy; my trick to modify it without introducing bugs is to run the fuzz tests comparing it to the nom-based reference implementation.

I'll try to figure out its flow then, I hope you don't mind if I ask some question if there are things I won't get.

Just to set the expectations, I'll try to work on it but it will not be immediately because I'm stuck with a couple of other OSS contributions 😅