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

From: "Linn, John" <[email-masked]>
Date: Thu, 12 Feb 1998 11:25:18 -0500

Ted writes, excerpting: 

>    [From DC minutes] "It was recognized that current GSS-API
> specifications
>    do not prescribe the error which should be returned if a reflected
> token
>    (a token received by the endpoint which generated it) is detected.
> Many
>    existing mechanisms' protocols include provisions for detecting
> such
>    tokens, and it seems reasonable that a major_status code should be
>    selected to indicate this situation."  Martin Rex posted a comment
> about
>    this issue to the list on 8 December, proposing use of
>    GSS_S_DUPLICATE_TOKEN if a per-message call detects a reflected
> token
>    and recommending that such detection be mandated when the replay
>    detection service is provided, but I don't believe that follow-up
>    discussion ensued.  
> 
> I agree that use of GSS_S_DUPLICATE_TOKEN seems appropriate.
> 
Exploring this point somewhat further, I believe this usage of
DUPLICATE_TOKEN is consistent with the text as it stands, though
arguably less than obviously. The current text (in 2078bis, sec. 1.2.3)
describing DUPLICATE_TOKEN states, "... that the integrity check value
on the received message was correct, but that the message was recognized
as a duplicate of a previously-processed message."   A qualifying
reflected token would have been previously processed against the context
(though in its opposite direction), so this description seems to fit as
a means to report a detected reflection.  

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?

--jl

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 12 Feb 1998 20:30:37 -0500

From: "Linn, John" <[email-masked]>
   Date: Thu, 12 Feb 1998 11:25:18 -0500

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?

							- Ted