GSSAPIDelegateCredentials only works for REQUIRES_PRE_AUTH principals?

[Adam Megacz]

I find that OpenSSH (5.1p1 on both sides) will silently refuse to
delegate credentials if the principal being delegated lacks the
REQUIRES_PRE_AUTH attribute. Adding that attribute at the KDC and
re-issuing the principal's tickets causes everything to work perfectly.

Is this behavior intentional? If so, I will petition the OpenSSH folks
to include some sort of warning explaining why the delegation failed.

Is this something I should bring up on the OpenSSH list instead?

Thanks,

- a

[Russ Allbery]

Post by Adam Megacz
I find that OpenSSH (5.1p1 on both sides) will silently refuse to
delegate credentials if the principal being delegated lacks the
REQUIRES_PRE_AUTH attribute. Adding that attribute at the KDC and
re-issuing the principal's tickets causes everything to work perfectly.
Is this behavior intentional?

Check the host/* principal on the system to which you were authenticating.
I bet that the REQUIRES_PRE_AUTH flag was set for it, which means that
only tickets that are pre-authenticated can authenticate to that service
principal.

[Adam Megacz]

Post by Russ Allbery
Check the host/* principal on the system to which you were authenticating.
I bet that the REQUIRES_PRE_AUTH flag was set for it, which means that
only tickets that are pre-authenticated can authenticate to that service
principal.

Indeed, that was it! Russ saves the day again.

Curious: I assume that the failure mode here is some variation on the
sshd machine asking the KDC for a delegation and the KDC refusing. Does
the refusal include enough information to produce an error message
(either in the sshd log or elsewhere) mentioning this as the reason for
the failure?

In general I find that sshd really does a very poor job explaining the
reason why things went wrong when it comes to Kerberos/GSSAPI. I've got
some free cycles this summer that I can put towards fixing that if it's
something that can be fixed.

- a

[Russ Allbery]

Post by Adam Megacz

Post by Russ Allbery
Check the host/* principal on the system to which you were
authenticating. I bet that the REQUIRES_PRE_AUTH flag was set for it,
which means that only tickets that are pre-authenticated can
authenticate to that service principal.

Indeed, that was it! Russ saves the day again.

The behavior caused by setting REQUIRES_PRE_AUTH on principals to which
one authenticates rather than principals one authenticates as always
strikes me as surprising, unexpected, and unintuitive.

Post by Adam Megacz
Curious: I assume that the failure mode here is some variation on the
sshd machine asking the KDC for a delegation and the KDC refusing.

I believe it fails even if you're not doing delegation. I believe the KDC
refuses to issue you a service ticket for a principal with
REQUIRES_PRE_AUTH set if your TGT is not tagged as preauthenticated. But
I don't remember the details of the research that I did when I ran into
this. (We just cleared that flag from principals like host/* principals
and moved on with our lives; given that they're randomly generated keys,
hopefully brute force attacks are difficult anyway.)

Post by Adam Megacz
Does the refusal include enough information to produce an error message
(either in the sshd log or elsewhere) mentioning this as the reason for
the failure?

ssh (well, OpenSSH) never reports useful error messages by default for
anything related to GSSAPI.

Post by Adam Megacz
In general I find that sshd really does a very poor job explaining the
reason why things went wrong when it comes to Kerberos/GSSAPI. I've got
some free cycles this summer that I can put towards fixing that if it's
something that can be fixed.

I haven't looked at the code personally, but what I recall from what other
people have said is that the code is structured so that doing proper error
reporting is fairly difficult. It can also quite hard to get OpenSSH
upstream to take GSSAPI-related patches, depending on how those patches
strike them.

[Simon Wilkinson]

Post by Russ Allbery

Post by Adam Megacz
In general I find that sshd really does a very poor job explaining the
reason why things went wrong when it comes to Kerberos/GSSAPI. I've got
some free cycles this summer that I can put towards fixing that if it's
something that can be fixed.

I haven't looked at the code personally, but what I recall from what other
people have said is that the code is structured so that doing proper error
reporting is fairly difficult.

There's a few factors at play here.

Firstly, the client only reports GSSAPI errors if it's run with the -v flag. This was a requirement when the code was originally pulled into OpenSSH, as they wanted to avoid alarming users who knew nothing about Kerberos/GSSAPI with the opaque error messages produced by GSSAPI at the time. Fixing this would be fairly straightforwards - getting those fixes into OpenSSH, less so.

Secondly, GSSAPI libraries have historically produced pretty poor error messages "See etext for details" being a great example of this. The only way to solve this is to improve the information that comes out of your library. I think MIT have done some recent work on this.

Thirdly, there's no communication of server errors back to the client. This is partly deliberate, as telling the client why an operation failed can, in some environments, be an information leak. My original GSSAPI patch had support for sending this information, based on configuration settings. When I was trying to get the GSSAPI code into OpenSSH, this was one of the things that got dropped in order to reduce code complexity.

Post by Russ Allbery
It can also quite hard to get OpenSSH upstream to take GSSAPI-related patches, depending on how those patches strike them.

Unless you have the patience and perseverance of Sisyphus, I wouldn't even consider trying to get GSSAPI code into OpenSSH. Success in getting even small, platform compatibility based changes into the upstream distribution has been geologically slow at best.

Cheers,

Simon.

[Tom Yu]

Post by Russ Allbery

Post by Adam Megacz

Post by Russ Allbery
Check the host/* principal on the system to which you were
authenticating. I bet that the REQUIRES_PRE_AUTH flag was set for it,
which means that only tickets that are pre-authenticated can
authenticate to that service principal.

Indeed, that was it! Russ saves the day again.

The behavior caused by setting REQUIRES_PRE_AUTH on principals to which
one authenticates rather than principals one authenticates as always
strikes me as surprising, unexpected, and unintuitive.

We are open to suggestions about how to remedy this behavior. I think
it stems from the KDB flag REQUIRES_PRE_AUTH being overloaded with two
mostly unrelated meanings: (1) require preauthentication when the
specified client obtains initial tickets; (2) require that any
client's service ticket have the "preauthenticated" flag set when
presented to a specified service.

How many people have a security policy that requires behavior (2)
above? If so, is it necessary to conflate that behavior with behavior
(1)?

Post by Russ Allbery

Post by Adam Megacz
Curious: I assume that the failure mode here is some variation on the
sshd machine asking the KDC for a delegation and the KDC refusing.

I believe it fails even if you're not doing delegation. I believe the KDC
refuses to issue you a service ticket for a principal with
REQUIRES_PRE_AUTH set if your TGT is not tagged as preauthenticated. But
I don't remember the details of the research that I did when I ran into
this. (We just cleared that flag from principals like host/* principals
and moved on with our lives; given that they're randomly generated keys,
hopefully brute force attacks are difficult anyway.)

That matches my recollection, but I haven't examined the relevant code
recently.

[Adam Megacz]

Post by Russ Allbery
I haven't looked at the code personally, but what I recall from what other
people have said is that the code is structured so that doing proper error
reporting is fairly difficult.

I can see how it might be difficult to get a message back to the client,
but it can't be all that hard to syslog it at the server... I don't find
that too discouraging.

Post by Russ Allbery
It can also quite hard to get OpenSSH upstream to take GSSAPI-related
patches, depending on how those patches strike them.

This, on the other hand, is very discouraging.

Thanks for the heads-up.

- a