http://permalink.gmane.org/gmane.ietf.gen-art hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.gen-art/8547 <pre> On Jun 18, 2013, at 11:39 AM, Sam Hartman &lt;hartmans&lt; at &gt;painless-security.com&gt; wrote: [Joe] Ah yes, I remember this. It would be simpler to just use eap lower-layer attribute. I think we could massage the text to say something like "eap lower-layer layer attribute or equivalent attribute indicating the EAP lower layer in use" . Let me see what I can do with the text David provided. </pre> Joseph Salowey (jsalowey 2013-06-18T20:00:17 http://permalink.gmane.org/gmane.ietf.gen-art/8546 <pre> This is looking good, modulo Sam's comment on EAP lower-layer vs. something else that I'll leave to you and he to sort out. I have a suggested rewrite, mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and to reformat into a structured bullet list of requirements (this is not intended to change any requirements from what you wrote): "In environments where EAP is used for purposes other than network access authentication: o All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings. o Channel binding MUST be used for all application authentication. The EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data for application authentication. o Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute </pre> Black, David 2013-06-18T19:34:44 http://permalink.gmane.org/gmane.ietf.gen-art/8545 <pre>Joe, eap-lower-layer is not required for application authentication if there's some other attribute that's specific to the lower layer. For example Moonshot sends gss-acceptor-service-name but does not currently send eap-lower-layer, and doing that seems consistent with the requirements of the channel binding spec. Adding a requirement for eap-lower-layer all the time would be new, but might be reasonable. --Sam </pre> Sam Hartman 2013-06-18T18:39:05 http://permalink.gmane.org/gmane.ietf.gen-art/8544 <pre> [Joe] Good points, the text can be more specific: "In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For application authentication, the EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All network access EAP peer implementations SHOULD use channel bindings including the EAP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. " Does this help? Thanks, Joe </pre> Joseph Salowey (jsalowey 2013-06-18T17:47:03 http://permalink.gmane.org/gmane.ietf.gen-art/8543 <pre> While both cases appear to be relevant, my concern started from the reverse case - here's the draft's text describing the attack: One potentially serious attack exists when channel binding is not required and EAP authentication is introduced into an existing non- network service. A device can be created that impersonates a Network Access Service to peers, but actually proxies the authentication to the new application service that accepts EAP authentications. This may decrease the security of this service even for users who previously used non-EAP means of authentication to the service. That text is an improvement, and it's headed in the same direction as Sam's comment - "application bindings MUST be present in application authentication" is a "MUST use" requirement, not just a "MUST implement" requirement. OTOH, I'm not clear on what "application bindings" means, as that term's not in the current draft. Specifically, I'm a bit unclear on "application bindings MUST be absent in</pre> Black, David 2013-06-18T17:28:17 http://permalink.gmane.org/gmane.ietf.gen-art/8542 <pre> On Jun 18, 2013, at 7:18 AM, Sam Hartman &lt;hartmans&lt; at &gt;painless-security.com&gt; wrote: [Joe] I'm trying to get a handle on the attack mechanism here. In this attack a valid network service is trying to spoof an application service? Since it knows the MSK it can do this if the channel-binding of the lower-layer into the EAP conversation is not enforced. If the AAA server always enforces channel bindings for applications then it will catch the spoofing attempt. The reverse case may also be an issue where an application service is trying to spoof a network service. In this case, if the AAA server validates that the application channel binding is not present then it can prevent the spoofing. However the server MUST understand channel bindings even if the peers do not. I think the document did try to capture this in the following sentence: "If the EAP server is aware that authentication is for something other than a network service, it too MUST default to requiring channel binding." I think we c</pre> Joseph Salowey (jsalowey 2013-06-18T17:10:19 http://permalink.gmane.org/gmane.ietf.gen-art/8541 <pre>Sam, I was concerned that something along these lines was lurking in here :-(. I think this is the crucial "running code" consideration to start from: Assuming that network access does not use channel binding, how does one avoid the proxy attack on network access authentication via application access authentication when the latter is introduced? For environments where EAP is used for network access authentication, the suggestion of a "MUST use" requirement for channel binding with application access authentication sounds like the right approach: Is that plausible and reasonable in practice? This would be in addition to the "MUST implement" requirements for AAA servers, EAP serves and peers doing application access: Thanks, --David </pre> Black, David 2013-06-18T14:43:03 http://permalink.gmane.org/gmane.ietf.gen-art/8540 <pre>Hi Magnus - Thanks for your careful treatment of these comments - I think you're on a good path with all the suggestions below. Responses to questions and a few comments inline: On 6/18/13 6:42 AM, Magnus Westerlund wrote: Yes - I was worried that I might have missed it before. You understood what I intended, and your resolution looks sufficient. Works for me. Does this mean you are removing cross-connection queueing altogether? That seems like it might work - exploring the idea should get some WG cycles. If you build one of these, please be sure to highlight the impact of the other sessions already established, and call out the potential for problems if you forward one as a Proxy, as opposed to generating your own based on the situation. Makes my head swim, but maybe it's must me. fwiw - I'm still worried that there are information in Appendix B that's not captured in the main text, but I can't find easy things to point to. Elwyn seems more comfortable that everything is covered. I think it would be </pre> Robert Sparks 2013-06-18T14:21:16 http://permalink.gmane.org/gmane.ietf.gen-art/8538 <pre>Hi Robert, Thanks for the massive review. A number of really good comments in here. Below you will find my answers, comments, questions and in most cases clarifications what I see us doing with your comment. These covers your major and minor comments. The nits we will simply implement as we see fit, if we have questions we will comeback with those. WG, there are a number of issues in here that would be greatly helped by your input! On 2013-06-05 23:56, Robert Sparks wrote: Agree, it would be differently structure if we wrote it from scratch today. But it is an document that is 10 years in the making with dual heritage in RFC 2326 and RFC 2068. Yes, using A or AAAA DNS records are assumed. No problem making that explicit. Should this protocol Potentially, but as everyone have been using A records for all these years, I think it is not worth defining it at this stage. The document should be explicit. On a related note, (and This draft says in Section 19.2 the following regarding this: RTSP MUST f</pre> Magnus Westerlund 2013-06-18T11:42:52 http://permalink.gmane.org/gmane.ietf.gen-art/8537 <pre>Comments below, marked &gt;&gt;&gt;. I think (though I need my co-authors to agree of course) that a draft with these revisions (and any others we need) will be appropriate following any other IETF LC comments. </pre> Dearlove, Christopher (UK 2013-06-18T09:15:54 http://permalink.gmane.org/gmane.ietf.gen-art/8536 <pre>I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at &lt;http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&gt;. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-abfab-eapapplicability-03 Reviewer: David L. Black Review Date: June 17, 2003 IETF LC End Date: June 17, 2003 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the applicability statement for EAP to include usage for application layer access via EAP over GSSAPI. Additional security requirements are introduced for environments in which EAP is used for that purpose. I found one open issue, which is minor, and may be editorial Major issues: None Minor issues: One The next to last paragraph on p.3 begins with this sentence: For these reasons, channel binding MUST be implemented by peers, EAP servers and AAA servers in environments where EAP authentication is used to access a</pre> Black, David 2013-06-18T02:39:28 http://permalink.gmane.org/gmane.ietf.gen-art/8535 <pre>I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at &lt; http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&gt;. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ipfix-protocol-rfc5101bis-08 Reviewer: Kathleen Moriarty Review Date: June 15, 2013 IETF LC End Date: IESG Telechat date: (if known) Summary: The draft is well written and ready for publication. There is at least one idnit that should be corrected, but should be fine for the Auth48 process. Major issues: Minor issues: Nits/editorial comments: From idnits, the first 2 should be fine: (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'RFC5102bis' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPFIX-IANA' == Outdated reference: A later version (-04) exists of draft-ietf</pre> Moriarty, Kathleen 2013-06-15T07:46:04 http://permalink.gmane.org/gmane.ietf.gen-art/8533 <pre>Hi all, The following reviewers have assignments: Reviewer LC end Draft --------------------------------------------------------------------- Alexey Melnikov 2013-06-28 draft-ietf-ipfix-protocol-rfc5101bis-08 Suresh Krishnan 2013-06-21 draft-ietf-ipsecme-ad-vpn-problem-07 * Wassim Haddad 2013-06-27 draft-ietf-l2vpn-pbb-vpls-pe-model-07 * On the June 27th telechat I have made the assignments in the review tool: http://art.tools.ietf.org/tools/art/genart/ And the assignments are captured in the spreadsheets: http://wiki.tools.ietf.org/dav/genart/gen-art.html http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html The standard template is included below. Thanks, Jean ------------------------------------------------------------------- I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at &lt;http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&gt;. Please resolve these comments along with any other Last Call comments </pre> A. Jean Mahoney 2013-06-14T15:18:47 http://permalink.gmane.org/gmane.ietf.gen-art/8532 <pre>Hi Suresh, I reply again to your mail after having new rev 09 submitted: 2013/4/16 Suresh Krishnan &lt;suresh.krishnan&lt; at &gt;ericsson.com&gt;: Addressed in rev 09: - Improved section "Handshake" (under "The WebSocket SIP Sub-Protocol") by mentioning the error handling when establishing a WebSocket connection. This has been explained within current mail thread. I expect then that using the incremental style is appropriate. Addressed in rev 09: - Mention to RFC 4168 (SIP SCTP) removed from the "SIP URI Transport Parameter" section. Addressed by rev 09: - "SIP transport implementation requirements" section clarified by removing the "MAY" keyword and exact section from RFC 3261 section 18 amended. Hope those actions address all the issues you reported. Thanks a lot for your help and comments. -- Iñaki Baz Castillo &lt;ibc&lt; at &gt;aliax.net&gt; _______________________________________________ Gen-art mailing list Gen-art&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/gen-art </pre> Iñaki Baz Castillo 2013-06-14T07:49:27 http://permalink.gmane.org/gmane.ietf.gen-art/8531 <pre>Hi all, The following reviewers have assignments: Reviewer LC end Draft --------------------------------------------------------------------- Kathleen Moriarty 2013-06-21 draft-ietf-ipsecme-ad-vpn-problem-07 * Peter Yee 2013-06-27 draft-ietf-appsawg-rfc5451bis-07 Russ Housley 2013-06-27 draft-ietf-manet-rfc6622-bis-02 Roni Even 2013-06-24 draft-ietf-pkix-est-07 * * On the June 27th telechat I have made the assignments in the review tool: http://art.tools.ietf.org/tools/art/genart/ And the assignments are captured in the spreadsheets: http://wiki.tools.ietf.org/dav/genart/gen-art.html http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html The standard template is included below. Thanks, Jean ------------------------------------------------------------------- I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at &lt;http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&gt;. Please resolve these commen</pre> A. Jean Mahoney 2013-06-13T21:31:56 http://permalink.gmane.org/gmane.ietf.gen-art/8530 <pre> Thanks your review, David. The Gen-ART reviews are important for me in helping decide if the documents may have issues where I need to dig in deeper. In this case I agree with the issue you raise and think it is a mistake that should be corrected. I see that Barry has already raised a discuss about that, however. I am balloting a No-Objection based on your review. Jari </pre> Jari Arkko 2013-06-13T16:07:19 http://permalink.gmane.org/gmane.ietf.gen-art/8529 <pre>Correct. There are a number of DISCUSS positions that will be resolved by -08. I haven't read all the DISCUSS material yet, but I expect that there will need to be a few more edits to catch the rest of them. I'll have to coordinate with Richard to determine when to ship -08. I don't want to interfere with AD reviews. </pre> Martin Thomson 2013-06-12T16:23:19 http://permalink.gmane.org/gmane.ietf.gen-art/8528 <pre>Suresh: Many thanks for the review. Iñaki: thank you for agreeing to accommodate the suggested changes. Will we see a -09 soon? I think we should wait for the all updates to be posted before the final approval of the document… Jari On Jun 11, 2013, at 2:47 AM, Iñaki Baz Castillo &lt;ibc&lt; at &gt;aliax.net&gt; wrote: </pre> Jari Arkko 2013-06-12T06:08:34 http://permalink.gmane.org/gmane.ietf.gen-art/8527 <pre>Thank you very much for the review, Suresh. I followed your discussion with Martin, and the conclusions seem correct to me. But I don't think we should approve the draft until the -08 appears. Martin? Jari On Jun 10, 2013, at 2:15 PM, Suresh Krishnan &lt;suresh.krishnan&lt; at &gt;ericsson.com&gt; wrote: </pre> Jari Arkko 2013-06-12T05:44:57 http://permalink.gmane.org/gmane.ietf.gen-art/8526 <pre>Alexey, Thank you very much for this review. I'm balloting a Yes based on your review and my own review. Thanks all, Jari On May 3, 2013, at 9:08 AM, Alexey Melnikov &lt;alexey.melnikov&lt; at &gt;isode.com&gt; wrote: </pre> Jari Arkko 2013-06-11T21:24:26 http://permalink.gmane.org/gmane.ietf.gen-art/8525 <pre> -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca&lt; at &gt;avaya.com] Sent: maandag 10 juni 2013 19:00 To: Brandenburg, R. (Ray) van Cc: avt&lt; at &gt;ietf.org; General Area Review Team; Roni Even (ron.even.tlv&lt; at &gt;gmail.com); draft-ietf-avtcore-idms.all&lt; at &gt;tools.ietf.org Subject: RE: Gen-ART review of draft-ietf-avtcore-idms-09 [[DR]] The open issue is not about this case but about the case when no receiver reported. You say one MSAS implementation may treat this as null information setting the field to 0 (which would seem to me like the obvious thing to do), but other MSAS implementation may include a timestamp anyway (which one?). My question 'Is this a problem' was about this case? [Ray] I don't see a difference between the two cases: in both cases the MSAS can decide to send 'some' timestamp. I'm not saying this is recommended, but I also don't see any interop issues. In any synchronization group there will be a maximum of 1 MSAS, so all receivers will receive the same presentation timestamp. Wha</pre> Brandenburg, R. (Ray) van 2013-06-11T10:29:55 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.gen-art