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 PROTECTED]
> Sent: Thursday, April 12, 2007 7:40 PM
> To: Eric Gray (LO/EUS)
> Cc: Sam Hartman; [EMAIL PROTECTED]
> Subject: Re: Gen-ART Last Call Review of
> draft-williams-on-channel-binding-01.txt
> Importance: High
>
> On Wed, Apr 11, 2007 at 03:59:16PM -0500, Eric Gray (LO/EUS) wrote:
> > 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...]
>
> That is an _embarrassing_ editing error :( That had been in -00 and
> should have been removed in -01.
>
> > ___________________________________________________________________
> >
> > In the same section are "must" and "should" not intended to be
> > capitalized (1st para after the above note)?
>
> 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.
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...
>
> > ___________________________________________________________________
> >
> > 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?
>
> 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:
>
> > Is the second recommendation bullet on page 8, intended to answer
> > 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?
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 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.
>
> 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.
I was not sure that this was consistent, but I see now that it is.
Thanks for the clarification.
>
> > ___________________________________________________________________
> >
> > 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.
>
> Oh, good catch! I would remove the "while."
>
> > ____________________________________________________________________
> >
> > 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.
>
> Heh. No, that's just typo. Thanks.
>
> > ____________________________________________________________________
> >
> > Next para, 3rd sentence, "ptoection" looks like it's supposed to
> > be "protection".
>
> Indeed.
>
> > ____________________________________________________________________
> >
> > 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").
>
> Thanks. I typoed in the anchor attribute of the <referecence> in
> question.
>
> > ____________________________________________________________________
> >
> > 4th bullet on page 7, "initinial"?
>
> "initial," another typo.
>
> > ____________________________________________________________________
> >
> > 7th bullet, same page, "a secure channels"?
>
> s/channels/channel/
>
> > ____________________________________________________________________
> >
> > 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."
>
> OK.
>
> > ____________________________________________________________________
> >
> > 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."
>
> Alas, this is no longer true, as we have agreed to add a registry (see
> discussion on the list).
>
> >
> _____________________________________________________________________
> >
> > I think the word "hostbased" is supposed to be hyphenated (bottom of
> > page 17).
>
> Indeed.
>
> >
> _____________________________________________________________________
>
>
> Thanks!
>
> Nico
> --
>
_______________________________________________
Gen-art mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/gen-art
