Microsoft.IdentityModel.JsonWebTokens Issue

[m33p]

It seems DuoUniversal has an issue with Microsoft.IdentityModel.JsonWebTokens 6.31.0

I upgraded Microsoft.Graph in my project to 5.13.0 DuoUniversal began to fail with this error message.

ArgumentOutOfRangeException: IDX10720: Unable to create KeyedHashAlgorithm for algorithm 'HS512', the key size must be greater than: '512' bits, key has '320' bits. (Parameter 'keyBytes')

It seems to fail when issuing the DuoHealthCheck

[AaronAtDuo]

Just making some notes to myself...

Looks like the error is coming from https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/5068c6eaf1c87cf3fac7fb7411bbaee7ded8baa4/src/Microsoft.IdentityModel.Tokens/CryptoProviderFactory.cs#LL481C49-L481C49
basically, enforcing that HS512 keys are 64 bytes. I wonder if this is a new enforcement....

[AaronAtDuo]

Yes, enforcement was added in AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet@008e2f7 on May 8

PR AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#2072

[m33p]

Would this be a simple fix? I believe the Client Secret is as the key which seems not to be long enough. I can hold off on upgrading this package for the time being. I can see this issue becoming a bigger problem for people as time goes on.

[AaronAtDuo]

@m33p I don't have a fix to suggest right this moment. You are correct that the key in question is the client secret provided by Duo.... unfortunately it's not a matter of simply providing a longer one, or encoding it differently so it consists of more bytes. I definitely see this being a more and more common problem, and I'm discussing it with some internal teams. I'll keep this issue posted with anything I find.

[AaronAtDuo]

So it turns out that the HMAC spec pads keys that are too short by appending null bytes to make a key of the correct size. So maybe pre-emptively doing that before we hand the key off to the library will work. I'll test it.

    (1) append zeros to the end of K to create a B byte string
        (e.g., if K is of length 20 bytes and B=64, then K will be
         appended with 44 zero bytes 0x00)

[m33p]

This is just a quick and dirty but appending the 44 zero bytes does appear to work in my initial testing. This could be written better but I do get a successful result.

    private static SecurityKey GenerateSecurityKey(string secret)
    {
        byte[] keyBytes = Encoding.UTF8.GetBytes(secret);
        byte[] zeros = new byte[44] { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
            0x00, 0x00, 0x00, 0x00, 0x00 };
        keyBytes = keyBytes.Concat(zeros).ToArray();
        return new SymmetricSecurityKey(keyBytes);
    }

[AaronAtDuo]

I've put up a PR to fix this

[AaronAtDuo]

@m33p The PR is landed. Is there any rush on a release to get this change out? It'd be ideal to solve #24 before I do a release but if this can't wait, let me know.

[m33p]

@AaronAtDuo I think it can wait until issue #24 is resolved. There isn't a dire need for me to update the effected libraries at this point. I think I'm good if the release happens in the next month or two. Worse case if needed I can fork a copy and built it.

[AaronAtDuo]

@m33p Someone else ran into this, so I went ahead with the release; I'm still trying to fit in the error reporting work for a future release.