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

[Henning Horst]

Greg,

Thanks a lot for your help and your quick responses. Thanks, too, for
developing such great stuff and providing it for the community!!

Best Regards and have a very nice weekend :)

Henning

On 07/22/2011 06:32 PM, Greg Hudson wrote:
> On Fri, 2011-07-22 at 11:55 -0400, Henning Horst wrote:
>> [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?
> I authenticate to a service using Kerberized rlogin or telnet.  You
> observe the exchange and pull out the authenticator and service ticket.
> You then use those to attempt to authenticate to sshd.
>
>> [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?
> An attacker who subverts the ssh DH channel would be unable to
> authenticate because the client's MIC would be over a different session
> ID than the one seen by the server.  But the attacker would be able to
> grab an authenticator and service ticket in the process of failing.
>
>> 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.
> Correct.
>
>> [H1:] Btw: The origin of this question is [...]
> I believe you should be able to safely disable the replay cache for
> sshd.  The caveat would be if your sshd is old enough to still support
> the insecure "gssapi" userauth mechanism, then the replay cache affords
> some level of protection against the weaknesses of that mechanism.
>
>


-------------- 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/9a470e84/attachment.bin