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