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

LDAP SHA512 Base64 ApacheDS #2174

Open
TobiasLogiline opened this Issue Feb 2, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@TobiasLogiline
Copy link

TobiasLogiline commented Feb 2, 2018

I am trying to connect FreeRADIUS Version 3.0.15 with ApacheDS LDAP Server. The Password is SHA512 encoded.

I get this error using TTLS/PAP:
pap: "known good" digest length (90) does not match output length of any SHA-2 digests

Before i can see this:

pap: Converted: &control:Password-With-Header = '{SHA512}+PnyObpTopB6TrrFEjUwz7w3GvM3GlK8aDmPcOowacgh9JFjJUtNCxoQBSNYPGmA92Y8iFWCFUh/ /qVJzhOKpA==' -> &control:SHA2-Password = '0x2b506e794f6270546f70423654727246456a55777a37773347764d33476c4b3861446d50634f6f7761636768394a466a4a55744e43786f5142534e5950476d4139325938694657434655682f0d0a2f71564a7a684f4b70413d3d'

The Password seems not to be Base64 decoded. The normalize option is set to yes. It seems like, if there are quotings in the Base64 string, the base64 detection fails, because of the length check.

@alandekok

This comment has been minimized.

Copy link
Member

alandekok commented Feb 2, 2018

'{SHA512}+PnyObpTopB6TrrFEjUwz7w3GvM3GlK8aDmPcOowacgh9JFjJUtNCxoQBSNYPGmA92Y8iFWCFUh/ /qVJzhOKpA==

What is that format? It's not hex. It does look to be base64 decoded.

How was it created? What tool did you use?

@arr2036

This comment has been minimized.

Copy link
Member

arr2036 commented Feb 28, 2018

Yeah except base64 doesn't include spaces Uh/ /qV

@arr2036

This comment has been minimized.

Copy link
Member

arr2036 commented Feb 28, 2018

So that's the issue, removing the space creates a valid base64 string which decodes to F8F9F239BA53A2907A4EBAC5123530CFBC371AF3371A52BC68398F70EA3069C821F49163254B4D0B1A100523583C6980F7663C88558215487FFEA549CE138AA4

...which is 64 bytes and correct.

The hex output from FreeRADIUS is the original Base64 string sans header.

What's happened is the base64/hex heuristic didn't mark the string up for decoding because it wasn't a valid base64 string, and just copied everything after the header into the SHA2-Password attribute.

@arr2036

This comment has been minimized.

Copy link
Member

arr2036 commented Feb 28, 2018

The question is whether the original string in the LDAP directory had that space, or whether it was added internally due to some misapplied escaping.

@TobiasLogiline

This comment has been minimized.

Copy link
Author

TobiasLogiline commented Feb 28, 2018

The spaces were not inside Apache Directory Studio. But possible that ApacheDS transfers the datas incorrect. ApacheDS is a little bit buggy ;) I not have the problem with any other LDAP user. So changing the password helps.

@arr2036

This comment has been minimized.

Copy link
Member

arr2036 commented Feb 28, 2018

Yeah right, you'd probably only see it with that specific base64 sequence sigh. If you can figure out whether the space was added by apache or not, then we could look into it, otherwise the vast majority of xlat string expansion issues will be fixed in v4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment