7

Bear with me, I know this is sloppy, but here is the back story:

We have a partner that uses Jira and is using spnego with a custom auth back-end that expects certain group membership in the token. Assuming the presented token meets the requirements, the user is granted SSO access to Jira.

We have a two way non-transitive external trust from one of our child domains with this partner. Since this is an old and crusty external trust and not a selective forest trust, AD does not maintain the information necessary for Kerberos to work for anything other than interactive logons between the domains.

There is an SPN registered on their side for this service, but clients on my side cannot locate this SPN, because a Kerberos referral is not possible. This is, obviously, a problem since it causes the clients to fall back to NTLM and they don't SSO.

The proposed workaround is to make a service account on our end as well and register a SPN on our side for the same service identical to theirs. The passwords will have to be identical on each side. This will negate the need for a referral to find the appropriate SPN since we're effectively mirroring it on our side and "tricking" the clients in our child into using it rather than the proper one on their side. They are also proposing that we lower the encryption algorithm for these mirrored accounts to RC4 rather than AES.

This is where my knowledge starts to falter, I don't know why the step of lowering the encryption algorithm to RC4 is necessary. I also don't know what the security implications of it may be.

What are the implications and why can't we just stick with AES to make this work?

MDMarra
  • 325
  • 3
  • 13

2 Answers2

4

The biggest reason I can think of as to why they might want to use RC4 is because of compatibility with Jira (and or this custom auth backend that we cannot vet.)

AES128 support was introduced along with Server 2008 and Vista, and AES256 with 2008 R2 and Win7. However, the KDC will automatically negotiate down to (for instance) RC4 when talking to, say, a Windows 2000 client, during pre-authentication. So there should be no need to force it.

Of course, you can also configure user and computer accounts to support or not support DES, AES128, AES256, etc.

The implications are simply that it's not as strong of an encryption type as the newer AES ones. But it's not awful either.

I would certainly be interested in hearing their reasoning for why they want to use RC4. The trick that you're proposing with mirrored SPNs is a whole other can of worms, but the encryption type used between clients and KDCs should have essentially nothing to do with whether it'll work.

Ryan Ries
  • 949
  • 1
  • 10
  • 14
2

You (or they, the ones who propose the change) do not give a reason for switching to RC4, do you? RC4 is a stream cipher, which is vulnerable in some particular cases:

RC4 has weaknesses that argue against its use in new systems. It is especially vulnerable when the beginning of the output keystream is not discarded, or when nonrandom or related keys are used. (Wikipedia)

So the implications of using RC4 are vulnerability to (at least) the above. I can't see why AES wouldn't hold, without a reason for the change..

Henning Klevjer
  • 1,815
  • 15
  • 20
  • 1
    @MDMarra RC4 has weaknesses that make it hard to use correctly. But if used correctly its security is fine. So the real question is whether it is used correctly in this protocol. I don't know the answer. – Gilles 'SO- stop being evil' Jan 17 '13 at 10:08