Subject: Last call comments on draft-ietf-krb-wg-gssapi-cfx

From: [email-masked] (Sam Hartman)
Date: Tue, 2 Dec 2003 10:11:41 -0500 (EST)

Hi.  I have read draft-ietf-gssapi-cfx and believe this draft should
be published as a proposed standard.

I would like to suggest the following clarifications to the text.

Consider adding the following just before the beginning of section 4.2:

If the caller to gss_accept_sec_context passes in GSS_C_NO_BINDINGS as
the channel bindings then the acceptor {MAY|SHOULD|MUST} ignore any
channel bindings supplied by the initiator, returning success even if the initiator did pass in channel bindings.

I believe this reflects current practice in several Kerberos
implementations as we migrate away from the use of IP-based channel
bindings.

My preference is for SHOULD or MUST, not for MAY in the above
sentence.

Section 4.2.6.1 still has the old token format, implying that the
to_be_signed data comes after the header in the checksum.

I think section 7 (security considerations) is probably the weakest
section of the document.  AT this time, I don't have additional things
to suggest adding to that section.  I believe the security
considerations against this GSSAPI mechanism are no different than
those for Kerberos and kcrypto.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Dec 2003 23:45:54 -0800

> implementations as we migrate away from the use of IP-based channel

This is, er, unfortunate.  I believe this is in reference to the MIT
FTPD behaviour wrt channel bindings.  I.e., users of an application are
relying on an implementation-specific behaviour that is against the
spirit, if not the letter of the relevant specs (rfcs 2743, 2744 and
1964).  (We could argue about what rfc2744 really says on this, what
"different" means where GSS_S_BAD_BINDINGS is described, but let's not -
we can agree to allow this behaviour and leave it at that.)

But even ignoring this it is clear that with RFC1964 and CFX the
acceptor does nothing to prove to the initiator that it provided the
same channel bindings as the initiator (if the initiator provided any).
This too is unfortunate.  A fix for this would be simple, but if none is
provided (and we've agreed that none will be) then this limitation must
be described in the security considerations section.

> My preference is for SHOULD or MUST, not for MAY in the above

Doesn't matter.  What matters is that the initiator MUST NOT expect a
non-error reply to mean that the acceptor provided matching channel
bindings.  Note that this might be ok if the initiator explicitly
selected the Kerberos V mechanism, but likely 

So I say "MAY" rather than SHOULD or MUST.

> those for Kerberos and kcrypto.

See above.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Dec 2003 17:44:53 +0100 (MET)

Nicolas Williams wrote:
> > channel bindings supplied by the initiator, returning success even if
> > the initiator did pass in channel bindings.
> > 

The problem of the channel bindings is with the FTP GSS-API extensions
spec, since it doesn't sufficiently say what to do.

GSS-API channel bindings have always been at the discretion
of the calling application, but it appears that several gssapi implementors
took the liberty of not implementing channel bindings in their mechanisms,
including Microsoft's W2K Kerberos SSP.

Applications that can traverse (multiple) firewalls or are usable in
environments with NATs present are never going to use channel bindings.
But in those environments one will be using non-Kerberos gssapi mechanisms
anyway, since Kerberos has a serious problem with Firewalls and
no direct IP connectivity between the peers and KDCs.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Dec 2003 12:30:07 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Dec 02, 2003 at 10:11:41AM -0500, Sam Hartman
    Nicolas> wrote:
    >> 
    >> 
    >> Hi.  I have read draft-ietf-gssapi-cfx and believe this draft
    >> should be published as a proposed standard.
    >> 
    >> 
    >> If the caller to gss_accept_sec_context passes in
    >> GSS_C_NO_BINDINGS as the channel bindings then the acceptor
    >> {MAY|SHOULD|MUST} ignore any channel bindings supplied by the
    >> initiator, returning success even if the initiator did pass in
    >> channel bindings.
    >> 
    >> implementations as we migrate away from the use of IP-based
    >> channel bindings.

    Nicolas> This is, er, unfortunate.  

I disagree this is unfortunate.  I believe it is common practice in
implementations and is a desirable feature.

    Nicolas> I believe this is in reference
    Nicolas> to the MIT FTPD behaviour wrt channel bindings.  I.e.,
    Nicolas> users of an application are relying on an
    Nicolas> implementation-specific behaviour that is against the
    Nicolas> spirit, if not the letter of the relevant specs (rfcs
    Nicolas> 2743, 2744 and 1964).  (We could argue about what rfc2744
    Nicolas> really says on this, what "different" means where
    Nicolas> GSS_S_BAD_BINDINGS is described, but let's not - we can
    Nicolas> agree to allow this behaviour and leave it at that.)

    Nicolas> But even ignoring this it is clear that with RFC1964 and
    Nicolas> CFX the acceptor does nothing to prove to the initiator
    Nicolas> that it provided the same channel bindings as the
    Nicolas> initiator (if the initiator provided any).  This too is
    Nicolas> unfortunate.  

You continue to assert that this is a bug or is unfortunate.  I
continue to not understand why it is a problem at all.

The acceptor has all the information it needs to decide whether it
consider the initiator's channel bindings acceptable.  Why do you need
more?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Dec 2003 10:06:35 -0800

> implementations and is a desirable feature.

We disagree on this but this disagreement is irrelevant, so I shan't
continue on this aspect.

We already have an agreement on how to proceed.  I made substantive
comments on your post, and I also stated this opinion.

So let's just discuss the necessary security considerations text.

> consider the initiator's channel bindings acceptable.  Why do you need

I find it useful for the acceptor to prove to the initiator that it has
the same channel bindings as the initiator [if the client requested
mutual auth].  Specifically, when using channel bindings data other than
network addresses ("transformed representations of encryption keys...")
with the goal of delegating some or all session protection from the
application layer to a secure channel at a lower layer it is important
to have the acceptor prove to the initiator that at least it did
validate the initiator's channel bindings.

Nico
--