Is a replay attack possible when using SSH2(or other protected service) as the kerberized service?

[Henning Horst]

Thanks a lot, Greg, for you swift response, my comments in your mail
(prefixed with [H1]) below:

On 07/22/2011 04:39 PM, Greg Hudson wrote:
> On Fri, 2011-07-22 at 05:18 -0400, Henning Horst wrote:
>> 1 - Authenticator is always generated on client and only send to
>> application server.
>>
>> 2 - If this connection is secured properly there should be no way of
>> stealing the authenticator
>>
>> 3 - If this connection is secured properly there should be no way of
>> stealing the service ticket
>>
>> 4 - The service ticket can also not be stolen from within the
>> KRB_TGS_REP because that packet is encrypted with the client's key
> An authenticator and service ticket could be stolen when it is used with
> another protocol using the host service.
[H1] Just to make sure - as long as the authenticator and the service
ticket are only transferred via SSH both cannot be stolen. How would
"using the host service with another protocol" look like? Could you be
so kind and outline a short example on how this would work?
> Also, people using gssapi-with-mic generally do not make strong
> assumptions about the quality of the channel protection provided by SSH
> host keys.  An attacker capable of mounting an MITM could in some cases
> defeat the leap-of-faith protection used in most host key deployments
> and observe the channel.
>
[H1] In this case they don't have to steal anything but can just do what
they want and authenticate on behalf of the client, couldn't they? Or
would Kerberos prevent successful user authentication even if the SSH
channel was captured?
>> From 1-4 and the assumption that the connection is secured properly,
>> there should be no way of doing a replay attack against the application
>> server. Please confirm or correct!
> Confirmed, but for different reasons.  An attacker who replays an
> authenticator can cause the krb5_rd_req() to succeed, but will not know
> the session key and will therefore be unable to correctly generate a MIC
> for the session identifier.
>
[H1] In which Kerberos packet can the authenticator and the service
ticket be stolen? - still assuming that the connection between client
and server are secured properly.
But in any case from what you say - the need to generate a MIC prevents
the attacker from a successful replay attack. So assuming the attacker
captured the authenticator because it was used with some other protocol
using that host service as you indicated above, the attacker would still
not be able to authenticate successfully due to the inability to
generate the MIC.
>> Last but not least  - what about if using SSH2 authentication method
>> gssapi-keyex (rfc 4462) ? In this method the Diffie-Hellman key exchange
>> (SSH2 layer 1 [SSH-TRANS]) is done based on GSS, with security service
>> Kerberos in this case. The actual user authentication (SSH2 layer 2
>> [SSH-AUTH]) is then based on that key exchange. How about a replay
>> attack in that scenario?
> In this case, replays are believed to be impossible because an attacker
> without knowledge of the session key will be unable to correctly
> generate a MIC for the DH secret.
>
> In both cases, it's important to note that the client cannot force the
> reuse of a session identifier or DH secret.
>
>
[H1:] Btw: The origin of this question is that we use multiple gssapi
authentication processes (using the same server credentials) that are
called from multiple SSH server processes. The SSH server processes are
all listening to the same port (using round robin dispatching).
Communication between the gssapi authentication processes (actually
accessing the Kerberos libs via the gssapi bindings) and the SSH server
processes is done via IPC. The reason for using multiple processes is
for loadbalancing. However writing from multiple processes to one replay
cache seems to leads to concurrency issues (apparently no locking? or
was this implemented in the latest Kerberos versions? ) The KRB5CACHEDIR
helps out but then - the replay attack prevention is gone partially
(when replaying the service ticket and authenticator that was used with
one gssapi authentication process to a different one with the same
server credentials)

Comments highly appreciated.

Best Regards and thanks again,

Henning

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20110722/071f62c6/attachment.bin