Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Whitespace in base64 encoded responses & mutual authentication #13

Open
mkomitee opened this issue Apr 6, 2013 · 1 comment
Open

Whitespace in base64 encoded responses & mutual authentication #13

mkomitee opened this issue Apr 6, 2013 · 1 comment

Comments

@mkomitee
Copy link
Collaborator

mkomitee commented Apr 6, 2013

In RFC 4648 which defines Base16, Base32, and Base64 encodings it says:

3.3. Interpretation of Non-Alphabet Characters in Encoded Data
Base encodings use a specific, reduced alphabet to encode binary data. Non-alphabet characters could exist within base-encoded data, caused by data corruption or by design. Non-alphabet characters may be exploited as a "covert channel", where non-protocol data can be sent for nefarious purposes. Non-alphabet characters might also be sent in order to exploit implementation errors leading to, e.g., buffer overflow attacks.
Implementations MUST reject the encoded data if it contains characters outside the base alphabet when interpreting base-encoded data, unless the specification referring to this document explicitly states otherwise. Such specifications may instead state, as MIME does, that characters outside the base encoding alphabet should simply be ignored when interpreting data ("be liberal in what you accept"). Note that this means that any adjacent carriage return/ line feed (CRLF) characters constitute "non-alphabet characters" and are ignored. Furthermore, such specifications MAY ignore the pad character, "=", treating it as non-alphabet data, if it is present before the end of the encoded data. If more than the allowed number of pad characters is found at the end of the string (e.g., a base 64 string terminated with "==="), the excess pad characters MAY also be ignored

Of particular interest is:

Implementations MUST reject the encoded data if it contains characters outside the base alphabet when interpreting base-encoded data, unless the specification referring to this document explicitly states otherwise.

Unfortunately, I cannot find any explicit reference to this RFC in any of the RFC's that are related to GSSAPI/Kerberos authentication. They all refer to an ephemeral idea of base64 encoding without any explicit reference to an implementation.

There are, however, some other RFC's which loosely define base64 encoding as well which explicitly state that whitespace should be ignored. Most notably of these is the RFC for MIME which is derived from the RFC for PEM.

Right now, the kerberos library we use handles the base64 decoding (why that is, I don't know) for us and will consider a token incorrect if it includes whitespace.

I have run into one server which was sending mutual authentication tokens which were not valid because of whitespace. I suspect this was a home-grown implementation of mutual authentication, so the implementation is suspect.

My reading of the relevant RFC's indicates that this is the correct thing to do, but I wanted to make sure everyone was aware of this and agreed before we decide that our implementation is acceptable.

FYI, urllib2_kerberos implements mutual authentication and also considers whitespace relevant and will cause mutual authentication failures if it runs into a token which includes it, but at work we have several perl based http clients which implement kerberos which didn't choke on the whitespace -- though I'm not familiar with them and it could be that they're not actually performing mutual authentication at all.

@sigmavirus24
Copy link
Contributor

I'm ok with us failing like we are realistically expected to. We should just note this in the documentation as well. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants