Subject: [Gen-art] Gen-ART Last Call Review of draft-williams-on-channel-binding-01.txt

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Wed, 11 Apr 2007 15:59:16 -0500

Nicolas,

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: 
		On the Use of Channel Bindings to Secure Channels
                draft-williams-on-channel-binding-01.txt

Reviewer: Eric Gray

Review Date:  04/11/2007

IETF LC End Date: 04/11/2007

IESG Telechat date: unknown

Summary:
This draft may be nearly ready to be published as a Proposed 
Standard RFC.  My review is a generalist review since I have
nearly no expertise in the area of this draft's concerns.

Comments:

I have the following minor comments and/or NITs.

Comments:
========

How did the following note (top of section 2.1, bottom of page 6) 
survive until last call?

   [NOTE: This section needs more work, I'm sure I've missed
   somethings...]
___________________________________________________________________

In the same section are "must" and "should" not intended to be
capitalized (1st para after the above note)?
___________________________________________________________________

In the last sentence of the 7th bullet on page 7, is this because
information about the end-points of a channel is not considered
secure?  If that is the case, would the statement change if that
information was considered secure?

Is the second recommendation bullet on page 8, intended to answer
this question?  If so, shouldn't it be a requirement?
___________________________________________________________________

In the 1st bullet under "Options" on page 8, I don't see how this 
is an "option" - but it is likely I am missing something.  From 
what it seems to me to be saying, channel binding is either a
requirement for establishing authentication in mechanisms that 
support channel binding, or they are not.

>From the way I read it, it seems to me that requiring channel 
binding to work in order to establish authentication in a
mechanism that supports channel binding might be getting the
cart before the horse.  But - if this is not the case - I don't
see why authentication would not be required to fail (to be 
established) in any such mechanism.
___________________________________________________________________

NITs:
====

In the 2nd para of the Introduction, the construction "..., while
..., but ..." is unusual and may be confusing - especially given
the length of th sentence.  One word (while or but) should be used
and the other discarded.
____________________________________________________________________

I am reasonably sure that "assymetric" is an incorrect spelling. 
If you mean "not symmetric" the word is "asymmetric" - but you
might mean something more interesting.  See top of page 6.
____________________________________________________________________

Next para, 3rd sentence, "ptoection" looks like it's supposed to
be "protection".
____________________________________________________________________

I don't know if you are aware of the fact that you (consistently)
used a misspelled reference tag for "Lampson, B., Abadi, M., Burrows, 
M., and E. Wobber, 'Authentication in Distributed Systems: Theory and
Practive', October 1991."  The tag is Lapmson91 (there's a swapped
pair of letters "pm" verses "mp").
____________________________________________________________________

4th bullet on page 7, "initinial"?
____________________________________________________________________

7th bullet, same page, "a secure channels"?
____________________________________________________________________

The last sentence in the first para on page 14 is hard to parse.

I suggest something like:

                                        "It is thought to be simpler to
   push the cryptographic session protection down the network stack (to
   IPsec), and yet be able to produce NICs that offload other operations
   (i.e. - TCP/IP, ESP/AH, and DDP), than it would be to add support in 
   the NIC for the many session cryptographic protection protocols in 
   use in common applications at the application layer."
____________________________________________________________________

I suggest changing section 7.  It currently reads:

	"There are no IANA considerations in this document."

Given that this is in the IANA considerations section of this
document, that statement might be slightly more confusing than:

	"There is no IANA action associated with this document."
_____________________________________________________________________

I think the word "hostbased" is supposed to be hyphenated (bottom of
page 17).
_____________________________________________________________________

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Apr 2007 18:40:01 -0500

>    [NOTE: This section needs more work, I'm sure I've missed

That is an _embarrassing_ editing error :(  That had been in -00 and
should have been removed in -01.

Since the list of requirements and recommendations that follows uses
RFC2119 terms I didn't think that the 'must' and 'should' in that
paragraph should also be capitalized.  If you think that can lead to
confusion (that the requirements are optional, say), then I am more than
willing to capitalize those two words in that paragraph.

A channels' channel bindings should not leak secret information, that's
what this bullet point says.  And it says that in this document we don't
consider the names of a channel's end-points to be secret.

Some users might, however, consider the names of a channel's end-points
to be secret (e.g., if the channel provided privacy protection for one
end-point's name).

The only way to get disclosure of channel bindings to passive attackers
would be to: a) use a channel that does not provide confidentiality
protection, _and_ b) use an application-layer authentication mechanism
whose channel binding facility exchanges channel binding data without
confidentiality protection.

Active attackers acting as the peer at the channel layer already know
the channel bindings of the channel, thus there's no disclosure risks
w.r.t. such attackers.

> this question?  If so, shouldn't it be a requirement?

addresses the issue, effectively.

I don't think this should be a requirement because if you'd use a
channel that doesn't provide confidentiality protection then you
probably don't care about privacy protection (one would think).

Should this rationale be made more explicit?

See SASL/GS2 (draft-ietf-sasl-gs2-08.txt).  SASL/GS2 takes channel
binding success into consideration in its negotiation of SASL security
layers.

In other words: a SASL/GS2 app can say "I want integrity protection" and
if channel binding succeeds, no SASL security layer will be used
(meaning the app will rely on the underlying channel for integrity
protection), else the SASL/GS2 security layer will be used.

That's why this is an option.

The last bullet point under requirements (i.e., the last one on pg. 7)
makes the corollary requirement: that applications MUST know if channel
binding failed.  For GSS-API mechanisms channel binding failure
generally* results in authentication failure.  For SASL/GS2 the channel
binding status merely affects the negotiation of SASL security layers.

* Though one could construct a GSS mechanism whose per-message
  protection services are "fake" when channel binding succeeds; no such
  mechanisms exist, but if they did they would be the GSS equivalent of
  the SASL/GS2 feature described above.

Oh, good catch!  I would remove the "while."

Heh.  No, that's just typo.  Thanks.

Indeed.

Thanks.  I typoed in the anchor attribute of the <referecence> in
question.

"initial," another typo.

s/channels/channel/

OK.

Alas, this is no longer true, as we have agreed to add a registry (see
discussion on the list).

Indeed.

Thanks!

Nico
--

---

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Thu, 12 Apr 2007 19:01:59 -0500

Nico,

	Please see in-line below.  Short answer, you've answered my
questions, and I doubt there are any related issues that need to
be addressed.

	Since you're planning to add meat to the IANA section, I will
likely be asked to look at this again.  No big deal...

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Thursday, April 12, 2007 7:40 PM
> To: Eric Gray (LO/EUS)
> Cc: Sam Hartman; [email-masked]
> Subject: Re: Gen-ART Last Call Review of 
> Importance: High
> confusion (that the requirements are optional, say), then I am more 
> than willing to capitalize those two words in that paragraph.

Your call.  I tend to agree that it is not likely to be confusing, 
but some people are sticklers for consistency.  I just pointed it
out in case you had missed it...

> Should this rationale be made more explicit?

Probably not necessary.  This was more in the nature of a question
than a comment, as I am not an expert in the subject.

I think your explanation is clear and it is not obvious to me that
such an explanation would be needed for someone with experience in
the area.

> In other words: a SASL/GS2 app can say "I want integrity protection"
> and if channel binding succeeds, no SASL security layer will be used

I was not sure that this was consistent, but I see now that it is.

Thanks for the clarification.