Subject: Re: Last Call: draft-williams-on-channel-binding (On the Use of Channel Bindings to Secure Channels) to Proposed Standard

From: "Tom.Petch" <[email-masked]>
Date: Wed, 11 Apr 2007 19:43:37 +0200

I think this a significant I-D which could be, in a few years, be the way in
which security is done in the Internet.

But I also think it understates its achievements in the Abstract and that it may
be inaccessible to those who would use it, those who are not also security
experts.

The Abstract refers to an approach 'which has various performance benefits'.
Rather, I think that is solves a - the? - problem of Internet security, that
encryption is easy and authentication is difficult and the mantra of security is
that sound authentication must come first.  This approach offers a way out of
that impasse.

But it is not clear that this is the case.  I think that to get the benefits of
this idea the I-D should have a non-normative section showing how it can be
applied to some well understood application, using a well-understood lower
secure layer (ie TLS or SSH, not IPsec) showing the outline protocol flow and
infrastructure dependencies.

Otherwise those who would benefit from it - isms, netconf, syslog, ... ? - will
not understand what they might do.  I appreciate that something of this ilk has
been around for a while (eg as when Ira McDonald pointed the isms list at
draft-puthenkulam-eap-binding-04.txt) but I think that it got no traction
because of its impenetrability.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Sent: Wednesday, March 14, 2007 4:44 PM
Subject: Last Call: draft-williams-on-channel-binding (On the Use of Channel
Bindings to Secure Channels) to Proposed Standard

> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'On the Use of Channel Bindings to Secure Channels '
>    <draft-williams-on-channel-binding-01.txt> as a Proposed Standard
>
>    The introduction of this draft implies that the facility being
>   discussed applies only to GSS-API.  That is not the case and the rest
>    of the draft is clear on this point; this draft proposes to generalize
>    and clarify a facility that exists today in GSS-API both for GSS-API
>    use and for other authentication frameworks.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2007-04-11. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-williams-on-channel-binding-01.txt
>
>
> IESG discussion can be tracked via
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15078&rf
c_flag=0
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 11 Apr 2007 12:09:24 -0700

Hi -

> From: "Tom.Petch" <[email-masked]>
> To: "ietf" <[email-masked]>
> Sent: Wednesday, April 11, 2007 10:43 AM
> Subject: Re: Last Call: draft-williams-on-channel-binding (On the Use ofChannel Bindings to Secure Channels) to Proposed Standard
...
> because of its impenetrability.
...

In the isms WG, we were told that we could not use EAP.
http://www1.ietf.org/mail-archive/web/isms/current/msg00464.html

Randy

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 11 Apr 2007 15:19:10 -0400

On Wednesday, April 11, 2007 12:09:24 PM -0700 Randy Presuhn 
<[email-masked]> wrote:

>> Subject: Re: Last Call: draft-williams-on-channel-binding (On the Use
>> ofChannel Bindings to Secure Channels) to Proposed Standard
> ...
>> Otherwise those who would benefit from it - isms, netconf, syslog, ... ?
>> - will not understand what they might do.  I appreciate that something
>> of this ilk has been around for a while (eg as when Ira McDonald pointed
>> the isms list at draft-puthenkulam-eap-binding-04.txt) but I think that
>> it got no traction because of its impenetrability.
> ...
>

That's right; isms is outside of EAP's field of applicability.  But 
draft-williams-on-channel-bindings is not specifically about EAP, but 
rather about a general class of problems that arises when protected 
communications channels are established independently of authentication, 
and an approach and method for solving those problems, particularly within 
the context of various authentication frameworks.

As it turns out, ISMS doesn't need to work about this class of problems 
because the approach we chose uses SSH, which provides both authentication 
and a protected channel in an integrated manner.  Now, if SSH for some 
reason wanted to make use of a protected channel provided by TLS or, more 
likely, IPsec, then it would need to worry about this class of problems, 
and the solutions might well involve exposing new interfaces to ISMS and 
other applications built on SSH.  But for the moment, that's not really an 
issue.

-- Jeff

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 11 Apr 2007 22:40:00 -0700

I think this draft is not ready for publication (I will respond 
separately on the applicability of this work to EAP channel binding): it 
is too abstract to the extent that it is confusing.  It is hard to keep 
track of the words channel binding and channel bindings, difficult to 
associate them with the descriptions, definitions and requirements, and 
finally map them to the variety of cases where the lower layer security 
channel is authenticated, partially authenticated or unauthenticated.

Some of the text is vague, for instance, in various places the goal is 
stated as "to avoid man-in-the-middle vulnerabilities."  I think it is 
important to be more precise than that.  Elsewhere in the document the 
motivation is clearer.

Some of the observations such as "For example, while IPsec [RFC4301] 
[RFC4303]
    [RFC4302] is amenable to being accelerated in hardware to handle very
    high link speeds, but IPsec key exchange protocols and the IPsec
    architecture are not as amenable to use as a security mechanism
    within applications, particularly applications that have users as
    clients. " don't belong in the document.  We can get into a debate 
on the correctness of that statement, but there's simply no point to 
that debate in the context of this document.

Other motivating factors such as better leveraging hardware 
implementations of crypto protocols are not universally applicable.

In Section 2.1, a requirement is stated as "MUST NOT leak secret 
information about the channel."  What is the secret information about 
the channel?

I didn't understand the "SHOULD" in "Applications SHOULD use mutual 
authentication at the application layer ..."   Is the premise that 
clients authenticate at the application layer and the other parties 
(servers, IPsec responders etc) authenticate at the network layer?

On "End-point channel bindings where the end-points are meaningful
       names SHOULD NOT be used when the channel does not provide
       confidentiality protection and privacy protection is desired." 
Does privacy refer to identity protection?  If so, "SHOULD provide for 
the use of a digest" doesn't seem appropriate.  Various mechanisms for 
identity privacy exist and there is no reason to RECOMMEND one mechanism.

In Section 8.1, I didn't understand the notion of mitigating 
impersonation by requiring confidentiality protection of secure 
channels.  Surely I am misunderstanding.  Please clarify.

Publication track:  Why is this document in "Proposed Standard" track? 
Perhaps a BCP might be more appropriate?

Editorial nits:

There are a bunch of dangling pointers that need to be fixed (Sec 2 and 
Sec 2.1); some typos (Page 7 in item 4) as well.

Overall, if the scope is limited to what's in the current version, 
perhaps the document will be ready after a revision and a re-review.

thanks,
Lakshminath

The IESG wrote:
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15078&rfc_flag=0
> 
>

---

From: "Tom.Petch" <[email-masked]>
Date: Thu, 12 Apr 2007 20:23:04 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "Randy Presuhn" <[email-masked]>; "ietf" <[email-masked]>
Cc: "Jeffrey Hutzelman" <[email-masked]>
Sent: Wednesday, April 11, 2007 9:19 PM
Subject: Re: Last Call: draft-williams-on-channel-binding (On the Use ofChannel

> other applications built on SSH.  But for the moment, that's not really an
Jeff

I agree that SSH does provide authentication but authentication of what and how
strong authentication?  I recall concern being expressed that the authentication
was of a low level engine when the application required authentication of a
higher layer entity; my recollection is of seeing this on several lists.

So I think that compound authentication may still be of value to isms, in the
future.

Tom Petch