Re: gss userauth

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Tue, Aug 26, 2003 at 05:02:58PM -0400, Sam Hartman wrote:
> >>>>> "Love" == Love  <lha%stacken.kth.se@localhost> writes:
> 
>     Love> Sam Hartman <hartmans%mit.edu@localhost> writes:
> 
>     >> The mechanism does as good of a job as it can for such cases.
>     >> In such cases, GSSAPI tokens are like one-time passwords.  We
>     >> know that if an attacker manages to tunnel them or otherwise
>     >> get ahold of the token before the token reaches the server (and
>     >> the server's replay cache), then the token can be used by the
>     >> attacker.
> 
>     Love> It could do better if it did channel bindings with session
>     Love> identifier in application data using GSS_C_AF_NULLADDRs.
> 
>     Love> Then gss mechs without integrity support but with (in gss
>     Love> spec optional) channel binding support would not be
>     Love> vulnerable to tunneling.
> 
> It could do that.  I wonder if it would work.  I am sufficiently
> uncomfortable with GSS channel bindings to refrain from recommending
> their use until CCM becomes much more mature.

Why are you uncomfortable with GSS channel bindings?  We know that they
work, from experience, where they are supported.  The lack of support
for channel bindings across the board is definitely one good reason to
be uncomfortable with using that facility to tackle this problem.

> Right now, I think that depending on channel bindings would delay our
> solution.  If we believe we want to break backward compatability, I'd
> rather choose one of the other approaches.

On the argument that support for channel bindings is not pervasive I
agree.  But I'm not sure that we have to solve this problem since, after
all, gss keyex does not have this problem and it is more useful that gss
userauth anyways (for mechs that provide integrity protection services).

We could just say that gss keyex is for mechs that provide mutual
authentication and integrity services and gss userauth is for mechs
that do not provide either or both of those.

Cheers,

Nico
--