Subject: rfc2078bis: per-msg sequencing

From: Martin Rex <[email-masked]>
Date: Tue, 10 Feb 1998 23:30:55 +0100 (MET)

What is the general feeling about replay detection and sequencing;
how robust should they be implemented?
 
I think we reached consensus on these two (policy) issues (at least
for the C-bindings, where pairing with COMPLETE/FAILURE is possible):
 
1) advisory/informational return codes from gss_unwrap()/gss_verifymic():

       either one of GSS_S_OLD_TOKEN, GSS_S_DUPLICATE_TOKEN,
       GSS_S_UNSEQ_TOKEN, GSS_S_GAP_TOKEN paired with GSS_S_COMPLETE
       and the output message will be returned from gss_unwrap()
 
2) fatal return codes from gss_unwrap()/gss_verifymic():

       either one of GSS_S_OLD_TOKEN, GSS_S_DUPLICATE_TOKEN,
       GSS_S_UNSEQ_TOKEN, GSS_S_GAP_TOKEN paired with GSS_S_FAILURE
       and *no* output message will be returned from gss_unwrap()

Now what about the context state after such an operation?
Is the mechanism allowed to invalidate the security context in case (2)?

I personally would like to see at least a strong recommendation for

"A mechanism should NOT invalidate the security context when
 gss_unwrap(), gss_verifymic() fails with a fatal error"

although I realize that (1) many applications (including mine) will
probably drop the connection and delete the security context themselves
when they encounter such an error, and (2) it may be impossible in
a few situations for the application and/or gss-api mechanism
to get back into sync for successful processing of future messages.

-Martin