Kerberos Authentication : Client authentication only

Question

I am currently implementing a way to authenticate using Kerberos mechanism. Then only explanation have is "SSO using Kerberos".

I know technically how works Kerberos (Keytab, SPNEGO, Token, KDC, SPN) and I already suceed to decipher some Kerberos token.

What interest me currently is the difference, between how I can technically handle this, and how It should be in the security fields.

To put it simply the workflow (which is in fact the bare minimum possible) :

• I receive a request from an unauthenticated user
• I answer "Negotiate"
• I receive a Negotiate token
• I decipher the user in (I handle authorization locally so I don't care about te reste).
• I store the information in the HTTP Session (which mean I have a classic SessionID Cookie), and the authentication is finished. I don't answer myself using WWW-Authenticate with a Kerberos token. (I saw it was possible but is it mandatory ? It's a part of the question).
• From now on user is authenticated and as long it's session is active he won't be reasked.

If we consider that we're in a HTTPS-only case it seems decent in my view of security (I'am a developer, I do look some stuff around security but no more) and it "technically work".

However the fact is that between all possibilities and what purpose they serve I'm a bit lost. For instance, take this example : Session Authentication vs Token Authentication

It is said that token authentication has beneficial advantages when using distributed system (I am not).

So is my way of doing Kerberos valid ? I don't think my application require high level security since it is within a private network (no Internet) and is not important enough to warrant high security but I'm still interested in the case I have implemented is against what Kerberos should be.

Answer 1

Removing the authentication component of this question for a moment you're asking "is X secure?" It's not a binary answer because you need to ask the question in the context of a particular attack or threat model, which is dictated by what the app is used for and who would use it.

That being said, this is a fairly common pattern and is often considered an acceptable off the type shelf solution. Web apps will not authenticate every HTTP request with a Kerberos ticket because each request would need to go through the WWW-Authenticate handshake, so the only way you can authenticate each request is by creating a session ticket.

Think of it this way... You're accepting a Kerberos ticket that can only be used once for a user from an authority you explicitly trust (the KDC) and exchanging that ticket for a session ticket you explicitly trust (because you issued it) that can be used multiple times. As long as your session ticket generation and validation is secure this is all probably fine.