Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt

[Nico Williams <[e-mail]>]

On Mon, Apr 06, 2020 at 10:43:27AM -0500, Nico Williams wrote:
> On Mon, Apr 06, 2020 at 11:24:31AM +1000, Luke Howard wrote:
> > > - Section 6.1.2
> > > 
> > >   The acceptor should also send a MIC along with the key, thus proving
> > >   it has possession of the shared secret.  This is important, otherwise
> > >   reply tokens could be replayed, and though it wouldn't be much of an
> > >   attack, it's worth doing.
> > 
> > Happy to add this, but is it much of an attack? Both parties are
> > anonymous, so (as we discovered with GS2) this mechanism is completely
> > superfluous unless you intend to use a message protection service (or
> > PRF), which will fail in a replay attack.
> 
> For pure GSS/SAnon apps it probably makes no difference, but it might
> for future stacks combining SAnon with other things.

Well, one nice thing about the MIC is that it allows the initiator to
detect CB failure earlier.  Heck, if the application protocol were to
only have per-message tokens flowing from the initiator to the acceptor,
then the initiator would never find out about CB failures.  So we want
the MIC.

(Not that CB is terribly useful in a mechanism that provides no
authentication, but let's ignore that for this purpose.)