Subject: full-duplex message protection services

From: Martin Rex <[email-masked]>
Date: Thu, 5 Mar 1998 23:04:56 +0100 (MET)

I was recently surprised when I tried to use protect a full duplex
communication between to peers with gssapi message protection services
and the gssapi mechanism constantly returned verification errors from the
message unprotection calls.

There is no explicit "full-duplex requirement" in any of the gssapi
documents, HOWEVER, there is also NO side effect or restriction mentioned
for the message protection calls (gss_wrap,gss_get_mic) that would
require an application to limit itself to half-duplex communication.
Therefore I consider a gssapi mechanism that is limited to half-duplex
message protection services incompliant with both specs (v1/v2).

The two pitfalls for a hasty gssapi mechanism designer that come
to my mind are (1) using a single sequence number for both directions
and (2) using a stream cipher (like RC4) and a single keystream
for both directions.  (OTOH, using another instance of the same
keystream could likely support full-duplex, but would open
a severe vulnerability...)

Although I think the full-duplex message protection is implied by
the specification of the message protection calls, a short explicit
notice in rfc2078bis, either "Section 1.1.3 Security Contexts", par 2 or 3
and/or Section 1.2.2/1.2.3.  Comments?  Proposals? (1or2 sentences)

If I read the spec correctly, TLS avoids this problem by using
different keys for both directions -- independent of the cryptographic
algorithms that are used.

rfc2078bis is currently in WG last call, and I really want to see
the document advance, so if the sense of the WG is that the implicit
requirement is sufficient -- oh well, then I will accept it.

Checking for full-duplex is rather easy:
establish a security context with yourself and first call
gss_wrap() once for each (acceptor, initiator) context with
a different(!) message and after that gss_unwrap() for each
of the two tokens on the respective peer context.

-Martin

---

From: "Linn, John" <[email-masked]>
Date: Tue, 17 Mar 1998 15:22:57 -0500

Ted wrote, replying to Martin:

>    From: Martin Rex <[email-masked]>
>    Date: Thu, 12 Mar 1998 11:11:53 +0100 (MET)
> 
>    Since I personally think (1) has always been there implicitly,
>    I mainly wanted to find out if there is actually a significant
> installed
>    base of half-duplex restricted mechanisms that is actively used and
> can
>    not be fixed/migrated.
> 
> I agree with Martin.  The requirement for concurrent processing has
> always been in the draft, however implicitly.  My impression is that
> there isn't an installed base of half-duplex restricted mechanisms, so
> my preference would be to make this requirement explicit instead of
> implicit.
> 
I've now heard three commentators preferring a requirement for
concurrent protection in both directions (Martin, Ted, and my own
comment (wearing personal hat as individual, not as document editor)
earlier on the thread); it has also been asserted that such a
requirement has been assumed implicitly.  Before Martin's and Ted's
messages (at least in the order they arrived at my desktop), Graham
Bland had also suggested upgrading the statement, but to the level of
recommendation rather than requirement, also stating that mechanism
definitions should specify whether or not concurrent protection is
provided.  Given this discussion, I'll now revise my proposed approach
towards closure.  Absent further debate, I suggest that we adopt the
requirement.  If anyone comments to the list that this appears too
strong, we'll step to Graham's intermediate recommendation instead.
Discussion?

--jl