You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
In RFC 4648 which defines Base16, Base32, and Base64 encodings it says:
Of particular interest is:
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 thebase64
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.The text was updated successfully, but these errors were encountered: