Subject: detecting reflection of protected message

From: Martin Rex <[email-masked]>
Date: Mon, 08 Dec 1997 23:15:22 -0500

For the CAT session this afternoon at the Washington IETF
I brought up the issue of how to handle the detection of
a reflected protected message.  That means if the initiator
(or the acceptor respectively) protects a message for output
with either gss_wrap() or gss_getmic() and sends the message
on the network, an attacker might pick the protected message
from the network and insert it into the message stream back
to the original sender.

The Kerberos gssapi mechanism and the Simple Public Key mechanism
do both put in a direction indicator into the message, so they
should in fact be able to detect this situation.  The current
spec doesn't expilicitly specify which error to return in this
situation, and from what I know, at least the MIT's Beta 6 didn't
notify the application of such an event.  One of the interesting
questions is: how did this affect seqence protection on the
security context ...

Personally, I think this sort of attack should be detected and
reported to the application, at least for the situations where
a security context claims to offer replay protection.  In the
event that someone would define a gssapi mechanism that used
different session keys in each direction, or in the SPKM case
with digital signatures, I would argue that it always MUST result
in an error.

My proposal would be to document and define that 
GSS_S_DUPLICATE_TOKEN should be returned for this case, and
personally I think this should be a requirement when the
security context claims to offer replay detection.

-Martin