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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 8 Dec 2003 00:37:15 -0800

Where are we at on this thread? 

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Wednesday, December 03, 2003 10:07 AM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: Last call comments on draft-ietf-krb-wg-gssapi-cfx

On Wed, Dec 03, 2003 at 12:30:07PM -0500, Sam Hartman wrote:
> >>>>> "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.
>     >> 
>     >> 
>     >> 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.
> 
>     Nicolas> This is, er, unfortunate.  
> 
> I disagree this is unfortunate.  I believe it is common practice in
> 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.

>     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?

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
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 8 Dec 2003 15:26:33 -0800

Re-posting, apparently this is the right thread.

======================================
Here is the new text for the security consideration section, based on
comments in this thread. Larry

=========================================
7. Security Considerations

Channel bindings are validated by the acceptor.  The acceptor can ignore
the channel bindings restriction supplied by the initiator and carried
in the authenticator checksum, if channel bindings are not used by
GSS_Accept_sec_context [RFC-2743], and the acceptor does not prove to
the initiator that it has the same channel bindings as the initiator,
even if the client requested mutual authentication.     This limitation
should be taken into consideration by designers of applications that
would use channel bindings, whether to limit the use of GSS-API contexts
to nodes with specific network addresses, to authenticate other
established, secure channels using Kerberos V, or for any other purpose.

Session key types are selected by the KDC.  Under the current mechanism,
no negotiation of algorithm types occurs, so server-side (acceptor)
implementations cannot request that clients not use algorithm types not
understood by the server.  However, administrators can control what
enctypes can be used for session keys for this mechanism by controlling
the set of the ticket session key enctypes which the KDC is willing to
use in tickets for a given acceptor principal.  The KDC could therefore
be given the task of limiting session keys for a given service to types
actually supported by the Kerberos and GSSAPI software on the server.
This does have a drawback for cases where a service principal name is
used both for GSSAPI-based and non-GSSAPI-based communication (most
notably the "host" service key), if the GSSAPI implementation does not
understand (for example) AES [AES-KRB5] but the Kerberos implementation
does.  It means that AES session keys cannot be issued for that service
principal, which keeps the protection of non-GSSAPI services weaker than
necessary.  KDC administrators desiring to limit the session key types
to support interoperability with such GSSAPI implementations should
carefully weigh the reduction in protection offered by such mechanisms
against the benefits of interoperability.

-----Original Message-----

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 15 Dec 2003 10:55:27 -0800

Nicolas William wrote:

> What matters is that the initiator MUST NOT expect a
> non-error reply to mean that the acceptor provided matching channel
> bindings.  

> Sam  Hartman wrote:
> > My preference is for SHOULD or MUST, not for MAY in the above
> > sentence.
> So I say "MAY" rather than SHOULD or MUST.

I would prefer that the acceptor always checks for channel bindings if
the initiator provides one, so I would go "MAY" as well.

Larry  

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Tuesday, December 02, 2003 11:46 PM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: Last call comments on draft-ietf-krb-wg-gssapi-cfx

On Tue, Dec 02, 2003 at 10:11:41AM -0500, Sam Hartman wrote:
> 
> 
> 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.
> implementations as we migrate away from the use of IP-based channel
> bindings.

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
> sentence.

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.

> 
> 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.

See above.

Cheers,

Nico
--