Subject: [abfab] GSS-EAP-05

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Mar 2012 21:39:14 -0700

Yeah!!! The list is getting shorter.

Jim

Section 5.6.1 - Which mutual authentication has the initiator successfully
performed?

Section 5.6.2 - It says that one must send 4 octets of flags, but the flags
field is descried as one octet in length.  I suggest adding in the other 24
its as reserved

Section 5.6.2 - I am having a problem understanding why this token is sent
from the initiator to the acceptor.  If one assumes that the problem is
going to at the acceptor end rather than at the initiator end, then allowing
the acceptor to do the check would appear to be problematic.  Additionally,
it appears that the check is "optional" for the acceptor to do, but not
doing it is not reflected back to the initiator. 

Section 5.8 - If one is using a tunnel method, is the rule about dictionary
attack resistance still true?  Or do we say that is provided by the tunnel
itself?  I don't know that any change needs to be made for this.

Minor:

s/referrs/refers/

---

From: Sam Hartman <[email-masked]>
Date: Sun, 25 Mar 2012 09:55:17 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> Yeah!!! The list is getting shorter.  Jim

    Jim> Section 5.6.1 - Which mutual authentication has the initiator
    Jim> successfully performed?

initiator confirms identity of acceptor.
That's what the mutual authentication service in RFC 2743 means.
GSS is another protocol like EAP where mutual authentication is a
synonym for server authentication.

I've clarified in text and explained why the acceptor cares.

    Jim> Section 5.6.2 - It says that one must send 4 octets of flags,
    Jim> but the flags field is descried as one octet in length.  I
    Jim> suggest adding in the other 24 its as reserved

I'm confused because I tried to find a reference in 5.6.1 and 5..2 to
one octet and couldn't find it.
Would you be willing to more clearly indicate what text you're referring
to?

    Jim> Section 5.6.2 - I am having a problem understanding why this
    Jim> token is sent from the initiator to the acceptor.  If one
    Jim> assumes that the problem is going to at the acceptor end rather
    Jim> than at the initiator end, then allowing the acceptor to do the
    Jim> check would appear to be problematic.  

GSS channel bindings assume trust in both endpoints to verify that the
channel containing the GSS context is the same at both endpoints.
So, both the acceptor and initiator need to do the check.
I haven't found a reason to believe one should be more trusted, but my
track record on this sort of analysis is not great.
However if you have found a problem here it's much bigger than GSS-EAP.

    Jim> Additionally, it appears
    Jim> that the check is "optional" for the acceptor to do, but not
    Jim> doing it is not reflected back to the initiator.

True.
That's how existing GSS mechanisms work.
I don't particularly mind having a protocol level facility to reflect
this back, but I wouldn't be able to do anything with the information in
a GSS implementation.

    Jim> Section 5.8 - If one is using a tunnel method, is the rule
    Jim> about dictionary attack resistance still true?  Or do we say
    Jim> that is provided by the tunnel itself?  I don't know that any
    Jim> change needs to be made for this.

The composition provides this protection if the tunnel is any good.