Subject: RE: Reflected tokens [Was: RE: draft-ietf-cat-rfc2078bis-02.txt e nroute]

From: "Linn, John" <[email-masked]>
Date: Fri, 13 Feb 1998 15:40:19 -0500

Ted writes:

>    I think the harder sub-issue is that of whether or not reflection
>    detection should be specifically required, which would represent a
>    change to the defined semantics of the replay and sequence services
> (an
>    area which has been stable for some time, and which could be
>    destabilizing to reopen and reconverge at this point).  Considering
> also
>    that duplicate detection is conditional in any case (e.g., it can't
> be
>    guaranteed for tokens which are too old), my inclination is to stay
> with
>    the status quo here.  What do others think?
> 
> One could argue that the exisiting semantics already require that
> reflection be detected; RFC-1508 and RFC-2078 both state that
> per-message calls provide "data origin authentication".  If an
> application can't be sure whether a message which was successfully
> processed by gss_unseal() came from its communications partner, or
> from
> itself, can we truthfully state that data origin authentication
> services
> has been provided to the application?
> 
Hm...  Given a mechanism within which a shared symmetric session key is
used to protect a context between A and B and apply per-message MICs,
nothing at the cryptographic level prevents B from generating and
sending A a message which appears to be from A (i.e., which would look
to A like a reflection).  Absent a requirement that MICs be computed
only with digital signatures unforgeable by the context's peer,
reflection detection (e.g., based on direction indicator flags within
the mechanism's protocol) is therefore being assured less strongly than
the assurance that the message wasn't an "out-of-context message" coming
from neither A nor B; the truthfulness provided to the application for
this distinct aspect of service is further from absolute. Pragmatically,
though, malicious injection of reflection replicas by
otherwise-cooperating context peers may not be a critical concern in
many or most cases; GSS reflection detection could also be usefully
defensive against "benign" error cases at lower layers in the stack or
network, though in some cases this might be redundant with detection
already occurring with comparable assurance outside the security
mechanism.  How does the following compromise sound: cite reflection
explicitly as one of the circumstances that DUPLICATE_TOKEN may be used
to indicate, and recommend that mechanism designers consider
incorporating reflection detection facilities into their protocols?

--jl

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Fri, 13 Feb 1998 20:09:44 -0500

From: "Linn, John" <[email-masked]>
   Date: Fri, 13 Feb 1998 15:40:19 -0500

   to A like a reflection).  

I suppose this depends on the definition of "data origin authentication"
that one uses.  B can always construct a messages, in any number of
ways, which A will reject as not being valid.  One of the ways B could
do this is by sending A a message which appears to be from A, but which
really isn't.  A would reject such a message as being invalid, though,
so no harm is done.  As long as A is playing the game correctly, A knows
that any message with a MIC computed with the shared symmetric session
must have come from B.  It is true that A cannot prove this to a 3rd
party, but we never guaranteed to provide non-repudiation.

   Pragmatically, though, malicious injection of reflection replicas by
   otherwise-cooperating context peers may not be a critical concern in
   many or most cases; 

It is true that an application protocol can have the property (either
accidentally or by design) such that maliciously injection of reflected
packets will not do any harm.  However, absent such a guanratee from the
security services layer, it forces the application programmer to take
steps to guarantee that reflections will not a concern, or at least be
able to demonstrate/prove that reflections will not cause a problem.

   How does the following compromise sound: cite reflection explicitly
   as one of the circumstances that DUPLICATE_TOKEN may be used to
   indicate, and recommend that mechanism designers consider
   incorporating reflection detection facilities into their protocols?

As a compromise, this seems reasonable to me.

						- Ted

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Feb 1998 00:04:01 +0100 (MET)

Theodore Y. Ts'o wrote:
> John Linn wrote:

Ok with me.

-Martin