RE: Gen-ART Review of draft-ietf-manet-rfc6622-bis-02
Comments below, marked . 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. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Russ Housley Sent: 14 June 2013 21:24 To: IETF Cc: IETF Gen-ART; ma...@ietf.org Subject: Gen-ART Review of draft-ietf-manet-rfc6622-bis-02 --! WARNING ! -- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-manet-rfc6622-bis-02 Reviewer: Russ Housley Review Date: 2013-06-15 IETF LC End Date: 2013-06-27 IESG Telechat date: Unknown Summary: The document is almost ready for publication as a standards track RFC. I raise one major concern, and once it is resolved, the document will be ready. Major Concern: In Section 12.2.3, is there any difference in processing when the source IP address is IPv4 as opposed to IPv6? Obviously, the two have a different length. Off the top of my head I cannot find a way for an attacker to exploit one party using IPv4 in the ICV calculation and the other party using IPv6. Since the IPv6 address is 12 octets longer than the IPv4 address, there may be some opportunity for an attacker. Anyway, concerns like this are usually thwarted by including the length of the overall hash function input as the first octet or two of the value-to-be-hashed. Such a value does not need to be transmitted. Each party knows how many octets it passed to the hash function. As it happens, this value is present in the packet header, but not in the message header, and we do not want to introduce a difference between them. In addition, being after the address might not work. Like you, I can't see how to exploit and still maintain a legal structure following, but attackers can be very resourceful. and I don't see that this can be guaranteed. Thus, this appears a good suggestion, with minimal computational overhead and no over the air overhead. Minor Concerns: I find Section 1.1 a bit confusing. I think it should start by saying that RFC 6622 defined two ICV TLV extension types (0 and 1). This document repeats those definitions and adds a third ICV TLV extension type (2). OK. Section 5 says: An ICV TLV with type extension = 2 specifies a modified version of this definition. This is unclear. I believe that an ICV TLV with type extension = 2 is an update to ICV TLV with type extension = 1. It would be good to introduce the need for this update. I suggest: An ICV TLV with type extension = 2 is the same as an ICV TLV with type extension = 1, except that the integrity protection also covers the source address of the IP datagram carrying the packet, message, or address block. Might tweak that a little, but OK. If you accept this suggestion, the following paragraph should also be revised. I suggest: Specifically, with type extension = 1 or type extension = 2, the value field contains the result of combining a cryptographic function and a hash function. The value field contains multiple sub-fields indicating which hash function and cryptographic function have been used as specified in Section 12. Essentially moving detail from this paragraph to previous one. This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Re: Gen-art last call review: draft-ietf-mmusic-rfc2326bis-34
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: Document: draft-ietf-mmusic-rfc2326bis-34 Reviewer: Robert Sparks Review Date: 05-Jun-2013 IETF LC End Date: 04-Jun-2013 IESG Telechat date: not yet on a telechat The document is very long, and the structure is unusual - much of the definition of the protocol itself is in the appendices. You are missing an opportunity to make this document much shorter (thereby likely increasing its effectiveness). Much of the jump in from RFC2326 was importing the description of headers and responses from HTTP, tailoring them to RTSP. That was a good exercise in that it highlights some issues that would otherwise be non-obvious (and raises a few questions below). But you followed the style from HTTP perhaps too closely - much shorter descriptions without examples might have done the job better. Overall, separating exposition and examples from the protocol definition would make it much easier for an implementer to find the definition of the protocol, and use the document as a reference when diagnosing a failure to interoperate. 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. Major Issues I'm not seeing what instructs an RTSP element on how to find the server it would try to open a connection to given an rtsp or rtsps URI? Are you assuming it would be doing A or DNS lookups? Yes, using A or DNS records are assumed. No problem making that explicit. Should this protocol use NAPTR/SRV? 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 maybe I missed this), but where do you talk about what an element should check in the server's certificate when connecting over TLS? Are you assuming a common name match? Or are you expecting some SubjectAltName processing? This draft says in Section 19.2 the following regarding this: RTSP MUST follow the same guidelines with regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818]. Where section 3.1 (Server Identity) of RFC 2818 contains the following: If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Isn't that clear enough on that matter? The document should say more about when connection reuse is appropriate, particularly when the connections happened because of an rtsps uri. Two different names might resolve to the same IP address - reusing a connection formed when looking at the first name (and verifying the server's cert) is dangerous. A new connection needs to be formed (and verified) instead. I want to check my understanding of the issue you are seeing here. So a client looks ups foo.example.org, gets an ip address A and establishes an TCP/TLS connection and verifies that there are a SubjectAltName that matches foo.example.org works. Then client is going to open bar.example.com and looks up that address and gets the same IP address A. Client matches A against existing connections and simply sends a request to bar.example.com. Thus bypassing the certificate verification. If we clarify that in the process of opening rtsps://bar.example.com the client MUST verify that the server certificate for the TLS connection it considers re-using has an SubjectAltName of bar.example.com, does that resolve your concerns. If not, please explain the concern further. The text talks about the option to queue S-C requests if there isn't a connection to the client available. Ostensibly, this means the request can go down some future connection. It's not clear how the server can tell the right client connected. In particular, when using rtsps, how do you prevent a malicious client from getting such a queued message that wasn't meant for him? Okay, this security issue I have totally missed but it is clearly serious. I don't see any easy way of fixing this. Thus I would suggest that we simply make it clear that a server MUST NOT queue the S-C RTSP message, independent if they are requests PLAY_NOTIFY and TEARDOWN or responses to client requests. Given that the text talks about queuing S-C requests, it should explicitly call out whether a server can queue a response if the connection the associated request arrived on is no longer
RE: New non-WG malign list : Network Service Chaining (NSC)
I assume non-malign non-WG maillist would be appropriate in this case. Cheers, Mehmet -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Melinda Shore Sent: Monday, June 17, 2013 8:43 PM To: ietf@ietf.org Subject: Re: New non-WG malign list : Network Service Chaining (NSC) How about a new non-malign WG list? Melinda
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
Black, == Black, David david.bl...@emc.com writes: Black, The next to last paragraph on p.3 begins with this sentence: Black,For these reasons, channel binding MUST be implemented by Black, peers, EAP servers and AAA servers in environments where EAP Black, authentication is used to access application layer services. Black, It appear that this MUST requirement applies to all uses Black, of EAP, including network access authentication, not just Black, application layer access authentication. If so, that's not Black, immediately obvious from the text, and an additional Black, sentence should be added to make this clearer. If not, the Black, above sentence needs to exclude network access Black, authentication from that requirement. I know you're correct that AAA servers and EAP servers need to implement channel binding for network access in such environments. I'm not sure whether peers only doing network access SHOULD implement channel binding or MUST implement channel binding. Practically speaking, it will be a while before peers implement channel binding for network access. The sorts of attacks that result without channel binding are attacks where a peer thinks it is doing network access authentication but what it's really doing is helping an attacker access an application. If all the application access peers support channel binding, then you could potentially require the eap-lower-layer attribute or similar for application authentication and work securely in environments where peers for network access have not been updated yet. It's also kind of tempting to stick our head in the sand and just add the clarification that yes, we mean network access too. --Sam
Re: Gen-art last call review: draft-ietf-mmusic-rfc2326bis-34
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: 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: Document: draft-ietf-mmusic-rfc2326bis-34 Reviewer: Robert Sparks Review Date: 05-Jun-2013 IETF LC End Date: 04-Jun-2013 IESG Telechat date: not yet on a telechat The document is very long, and the structure is unusual - much of the definition of the protocol itself is in the appendices. You are missing an opportunity to make this document much shorter (thereby likely increasing its effectiveness). Much of the jump in from RFC2326 was importing the description of headers and responses from HTTP, tailoring them to RTSP. That was a good exercise in that it highlights some issues that would otherwise be non-obvious (and raises a few questions below). But you followed the style from HTTP perhaps too closely - much shorter descriptions without examples might have done the job better. Overall, separating exposition and examples from the protocol definition would make it much easier for an implementer to find the definition of the protocol, and use the document as a reference when diagnosing a failure to interoperate. 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. Major Issues I'm not seeing what instructs an RTSP element on how to find the server it would try to open a connection to given an rtsp or rtsps URI? Are you assuming it would be doing A or DNS lookups? Yes, using A or DNS records are assumed. No problem making that explicit. Should this protocol use NAPTR/SRV? 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 maybe I missed this), but where do you talk about what an element should check in the server's certificate when connecting over TLS? Are you assuming a common name match? Or are you expecting some SubjectAltName processing? This draft says in Section 19.2 the following regarding this: RTSP MUST follow the same guidelines with regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818]. Where section 3.1 (Server Identity) of RFC 2818 contains the following: If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Isn't that clear enough on that matter? Yes - I was worried that I might have missed it before. The document should say more about when connection reuse is appropriate, particularly when the connections happened because of an rtsps uri. Two different names might resolve to the same IP address - reusing a connection formed when looking at the first name (and verifying the server's cert) is dangerous. A new connection needs to be formed (and verified) instead. I want to check my understanding of the issue you are seeing here. So a client looks ups foo.example.org, gets an ip address A and establishes an TCP/TLS connection and verifies that there are a SubjectAltName that matches foo.example.org works. Then client is going to open bar.example.com and looks up that address and gets the same IP address A. Client matches A against existing connections and simply sends a request to bar.example.com. Thus bypassing the certificate verification. If we clarify that in the process of opening rtsps://bar.example.com the client MUST verify that the server certificate for the TLS connection it considers re-using has an SubjectAltName of bar.example.com, does that resolve your concerns. If not, please explain the concern further. You understood what I intended, and your resolution looks sufficient. The text talks about the option to queue S-C requests if there isn't a connection to the client available. Ostensibly, this means the request can go down some future connection. It's not clear how the server can tell the right client connected. In particular, when using rtsps, how do you prevent a malicious client from getting such a queued message that wasn't meant for him? Okay, this security issue I have totally missed but it is clearly serious. I don't see any easy way of fixing this. Thus I would suggest that we simply make it clear that a server
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
--On Tuesday, May 21, 2013 09:42 +0100 Steve Crocker st...@shinkuro.com wrote: Like the IETF, ICANN is also an open organization. ICANN meetings are free, and a veritable ocean of documents are published regularly, many in multiple languages to increase availability. ICANN is purposefully organized to include participation from a range of communities, e.g. business, civil society, governments, and the technical community. ... The roster of topics active within ICANN at any given time is fully documented and publicized, and I invite anyone who is interested to participate. We listen to everyone, and we publish tentative results, tentative policies, etc. for everyone to critique. --On Tuesday, May 21, 2013 12:25 +0200 Olivier MJ Crepin-Leblond o...@gih.com wrote: Quite frankly, I used to have the same feeling... until very recently. With Steve at the wheel, things have improved a lot. ... Today, it's still not perfect, but you cannot fix a bus by shooting it - work on it instead, to fix it. I believe it's fixable. Steve and Olivier, As I think you both know, I've made personal decisions to avoid saying what I'm about to say in places as public as the IETF list and have been largely successful in that for the last decade. I've been deliberating about the balance of advantages and disadvantages of responding to your notes; hence the delay in doing so. I've worked happily and successfully with both of you on various Internet issues and have no doubts about either your integrity or your commitment to a better Internet, with the latter more or less the way the IETF would understand. That shared background and assumptions combined with your very optimistic postings seem to call for comment. Olivier, certainly there has been change at ICANN over the last several years. You comment implies to me that you think things are monotonically improving; I don't believe that although I do believe that, if one starts from selected examples and times, huge improvements are easy to document. I'll address the issue of public input and what happens to it below. As a fairly trivial example, while issues are publicized (as Steve notes), they are publicized on a web site that seems much harder to find anything on, unless one is spending enough time working on ICANN issues for it to feel familiar with its organization, than it was a few years ago. I recommend trying the experiment of pretending you don't know the site and then trying to get quickly to information on the status, open issues, and decisions already made about any particular substantive issue in which you might be interested. Steve, participation in ICANN is certainly not free, any more than participation in the IETF is free. ICANN doesn't charge a meeting registration fee, but its meetings tend to be in more exotic places that are more costly to get to and/or stay at than IETF's choices (and some of us still whine about the IETF ones, especially when IAOC considers mid $200 range to be acceptable for hotels and when the combination of the IETF meeting schedule, associated meetings, and plane connections can easily require a six or seven day stay). My not entirely subjective impression is that participating in ICANN, f2f, is considerably more expensive in an average year than it is for IETF. More important, while I think the IETF's remote participation mechanisms could still use a lot of improvement, they do tend to work and our decisions on mailing lists rules and provisions for very public appeals and responses provide a lot of protection when they don't work. By contrast, ICANN's remote participation mechanisms for meetings often don't work (probably an unfortunate side-effect of some of the places ICANN chooses to meet) and a very large fraction of the key decision-making meetings and discussions don't even pretend to be publicly or remotely accessible. But the more important issue, at least from my perspective, is that two things keep reappearing and have either gotten worse or remained the same in recent years. They are: (1) While ICANN accepts input from anyone who is interested, there is very little evidence that any of that input has any influence on results unless it comes from a well-established constituency group. There is little evidence that either the Board or Staff actually consider any of the public input and considerable evidence (from examination of proposals before and after the public review) that they do not. It is also possible that they consider all such comments and justifiably conclude that all of them are completely bogus or uninformed, but I just can't believe that. That might be less of an issue were those established constituency groups really representative of the Internet community but, especially in the domain name space, the influential groups seems to be entirely those with a vested interest in the marketing and sales of domain names. Even in the address space, there is little
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Did this LC end? or stated differently: What's the status of this draft LC? I'm not such a fan of the draft, mostly because it appears to remove some principles that some RIR folk hold up in their policy discussions as important... while not having a backstop in said policies to replace the originals from 2050. That can be fixed though... provided those communities see fit to keep the principles in place. Mostly then my 'not such a fan' is a timing problem I suppose, which is what prompted this LC query. -chris On Tue, Jun 18, 2013 at 10:30 AM, John C Klensin john-i...@jck.com wrote: --On Tuesday, May 21, 2013 09:42 +0100 Steve Crocker st...@shinkuro.com wrote: Like the IETF, ICANN is also an open organization. ICANN meetings are free, and a veritable ocean of documents are published regularly, many in multiple languages to increase availability. ICANN is purposefully organized to include participation from a range of communities, e.g. business, civil society, governments, and the technical community. ... The roster of topics active within ICANN at any given time is fully documented and publicized, and I invite anyone who is interested to participate. We listen to everyone, and we publish tentative results, tentative policies, etc. for everyone to critique. --On Tuesday, May 21, 2013 12:25 +0200 Olivier MJ Crepin-Leblond o...@gih.com wrote: Quite frankly, I used to have the same feeling... until very recently. With Steve at the wheel, things have improved a lot. ... Today, it's still not perfect, but you cannot fix a bus by shooting it - work on it instead, to fix it. I believe it's fixable. Steve and Olivier, As I think you both know, I've made personal decisions to avoid saying what I'm about to say in places as public as the IETF list and have been largely successful in that for the last decade. I've been deliberating about the balance of advantages and disadvantages of responding to your notes; hence the delay in doing so. I've worked happily and successfully with both of you on various Internet issues and have no doubts about either your integrity or your commitment to a better Internet, with the latter more or less the way the IETF would understand. That shared background and assumptions combined with your very optimistic postings seem to call for comment. Olivier, certainly there has been change at ICANN over the last several years. You comment implies to me that you think things are monotonically improving; I don't believe that although I do believe that, if one starts from selected examples and times, huge improvements are easy to document. I'll address the issue of public input and what happens to it below. As a fairly trivial example, while issues are publicized (as Steve notes), they are publicized on a web site that seems much harder to find anything on, unless one is spending enough time working on ICANN issues for it to feel familiar with its organization, than it was a few years ago. I recommend trying the experiment of pretending you don't know the site and then trying to get quickly to information on the status, open issues, and decisions already made about any particular substantive issue in which you might be interested. Steve, participation in ICANN is certainly not free, any more than participation in the IETF is free. ICANN doesn't charge a meeting registration fee, but its meetings tend to be in more exotic places that are more costly to get to and/or stay at than IETF's choices (and some of us still whine about the IETF ones, especially when IAOC considers mid $200 range to be acceptable for hotels and when the combination of the IETF meeting schedule, associated meetings, and plane connections can easily require a six or seven day stay). My not entirely subjective impression is that participating in ICANN, f2f, is considerably more expensive in an average year than it is for IETF. More important, while I think the IETF's remote participation mechanisms could still use a lot of improvement, they do tend to work and our decisions on mailing lists rules and provisions for very public appeals and responses provide a lot of protection when they don't work. By contrast, ICANN's remote participation mechanisms for meetings often don't work (probably an unfortunate side-effect of some of the places ICANN chooses to meet) and a very large fraction of the key decision-making meetings and discussions don't even pretend to be publicly or remotely accessible. But the more important issue, at least from my perspective, is that two things keep reappearing and have either gotten worse or remained the same in recent years. They are: (1) While ICANN accepts input from anyone who is interested, there is very little evidence that any of that input has any influence on results unless it comes from a well-established constituency group. There is little evidence that either the Board or
Gen-ART review of draft-ietf-abfab-eapapplicability-03
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. 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 application layer services. It appear that this MUST requirement applies to all uses of EAP, including network access authentication, not just application layer access authentication. If so, that's not immediately obvious from the text, and an additional sentence should be added to make this clearer. If not, the above sentence needs to exclude network access authentication from that requirement. Nits/editorial comments: The same paragraph (p.3) continues with: In addition, channel binding MUST default to being required by peers for non-network authentication. If the EAP server is aware that authentication is for something other than a network service, it too MUST default to requiring channel binding. What is meant by non-network authentication and other than a network service? If those mean other than for network access authentication as the term network access authentication is used in section 1 and RFC 3748, that meaning should be clarified. idnits 2.12.17 generated this comment: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) idnits appears to be confused ;-). The -00 version of this draft is from 2012, and this draft does not contain sufficient material from RFC 3748 that would raise that concern, so this comment should be ok to ignore. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
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: Practically speaking, it will be a while before peers implement channel binding for network access. 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: If all the application access peers support channel binding, then you could potentially require the eap-lower-layer attribute or similar for application authentication and work securely in environments where peers for network access have not been updated yet. 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: I know you're correct that AAA servers and EAP servers need to implement channel binding for network access in such environments. Thanks, --David -Original Message- From: Sam Hartman [mailto:hartm...@painless-security.com] Sent: Tuesday, June 18, 2013 10:19 AM To: Black, David Cc: stefan.win...@restena.lu; jsalo...@cisco.com; General Area Review Team; ab...@ietf.org; ietf@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Black, == Black, David david.bl...@emc.com writes: Black, The next to last paragraph on p.3 begins with this sentence: Black,For these reasons, channel binding MUST be implemented by Black, peers, EAP servers and AAA servers in environments where EAP Black, authentication is used to access application layer services. Black, It appear that this MUST requirement applies to all uses Black, of EAP, including network access authentication, not just Black, application layer access authentication. If so, that's not Black, immediately obvious from the text, and an additional Black, sentence should be added to make this clearer. If not, the Black, above sentence needs to exclude network access Black, authentication from that requirement. I know you're correct that AAA servers and EAP servers need to implement channel binding for network access in such environments. I'm not sure whether peers only doing network access SHOULD implement channel binding or MUST implement channel binding. Practically speaking, it will be a while before peers implement channel binding for network access. The sorts of attacks that result without channel binding are attacks where a peer thinks it is doing network access authentication but what it's really doing is helping an attacker access an application. If all the application access peers support channel binding, then you could potentially require the eap-lower-layer attribute or similar for application authentication and work securely in environments where peers for network access have not been updated yet. It's also kind of tempting to stick our head in the sand and just add the clarification that yes, we mean network access too. --Sam
Re: [Back to] Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Chris, On Jun 18, 2013, at 8:57 AM, Christopher Morrow morrowc.li...@gmail.com wrote: I'm not such a fan of the draft, mostly because it appears to remove some principles that some RIR folk hold up in their policy discussions as important... while not having a backstop in said policies to replace the originals from 2050. Which principles are you referencing? Thanks, -drc
IETF Diversity
I am rather disappointed that there hasn't been any followup to the diversity discussion that took place at the plenary. I do applications and I do security and so having a diverse range of input is critical if the final product is going to be useful. There are no gender or cultural issues in packet routing that I am aware of. But once we get to the application layer they become central. We seem to have interminable discussions about how to help some hypothetical dissident in (pick your authoritarian state). But I can't remember the last time we discussed Internet stalking which has been an issue women have been complaining about since I started getting involved in IETF. This is just one security issues that has a big gender bias and it is a problem that I think can be usefully addressed in an open consensus seeking organization. It does not take 100 people to write a specification but it does take a large number of people to adequately gather requirements. Taking requirements from 100 people from almost the same background and perspective is not very productive. I am aware that I have a limited personal perspective which is why I actively seek out other perspectives. At the plenary I pointed out that there have been women involved in IETF ever since I started in IETF over 20 years ago now. Yet we have an IAB and an IESG with only one female member who is not ex-officio (according to their Web sites) That situation should be something that has the IETF management worried but I can't see much sign of that. The IETF is unlikely to die but it can lose influence beyond the IP and DNS core. Sooner or later someone is going to work out how to establish an applications standards process that is gender and culture inclusive. And we know from experience that in our environment there can be a remarkably small time between the idea and establishing an institution. Minecraft was launched in 2011 and they had 4,500 people at their first international conference that year, they are now about to have their third. So they went from having nothing to having a larger participant community than the IETF in a matter of months. The IETF is a community known for valuing consensus rather than seeking diverse views. I see a real risk that the consensus being built here is a false consensus built by excluding opposing views rather than a real consensus built on reconciling them. Bringing opposing views to this forum is invariably a thankless task. The assumption is that if you can't hack it here well that is your fault and your problem. Case in point, each time I get something wrong in RFC2HTML and I get the error message 'You Lose', my natural response is 'why the heck am I bothering wasting my time here'. I do not think that gender is the only diversity problem in IETF but it is one that can be measured and the IETF is conspicuously failing. We also have a rather severe age problem, twenty years ago EKR and myself were among the youngest participants in most discussions and setting aside the grad students the same is usually true today. The perspective is going to need to change. Rather than looking for ways to encourage a few token women to work their way up through the existing selection regime we need to look at what sort of selection and participation and representation structures will encourage diversity. -- Website: http://hallambaker.com/
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Chris: The last call on RFC 2050 bis has ended. The draft will be shortly on the IESG telechat, up for an approval decision and/or suggestion for changes. I personally think it is ready to move forward. That is not to say that we wouldn't take comments, if you have some. As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. And is not like there'd be nothing to improve on our side :-) Lets focus on IETF aspects here. For what it is worth, I have limited experience about ICANN, but it has all been very positive. Jari
Re: IETF Diversity
On 6/18/13 10:52 AM, Phillip Hallam-Baker wrote: I am rather disappointed that there hasn't been any followup to the diversity discussion that took place at the plenary. Speak for yourself. Some of us are taking concrete actions (e.g., recruiting people for document shepherd and WG chair roles) instead of pontificating at the mic. Peter -- Peter Saint-Andre https://stpeter.im/
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
--On Tuesday, June 18, 2013 19:54 +0300 Jari Arkko jari.ar...@piuha.net wrote: Chris: The last call on RFC 2050 bis has ended. The draft will be shortly on the IESG telechat, up for an approval decision and/or suggestion for changes. I personally think it is ready to move forward. That is not to say that we wouldn't take comments, if you have some. Jari, For the record, I still believe that 2050bis should be published. Regardless of what I think of some of the things it says, I think it is reasonably reflective of reality and that reality is always worth documenting. As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. And is not like there'd be nothing to improve on our side :-) Lets focus on IETF aspects here. For what it is worth, I have limited experience about ICANN, but it has all been very positive. As to my more general comments, they were not really addressed to 2050bis and I have no desire to start a discussion of them here. However, some assertions about how well ICANN is working were made on this list by people who do not usually participate actively in IETF's technical work. In part because some ICANN decisions and behaviors does affect the fate of IETF protocols and the state of the Internet generally, I concluded after a lot of consideration that those assertions should be responded to on this list. I would welcome a discussion (definitely somewhere else) about that difference in perceptions if it were possible that it would bring about either improved understanding or changes that would make the various decision-making processes that affect the Internet more open and/or more based on a general understanding of Internet technical reality. That would include an offlist discussion of why your perceptions and mine may differ should you find such a discussion useful. best, john
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
On Jun 18, 2013, at 7:18 AM, Sam Hartman hartm...@painless-security.com wrote: Black, == Black, David david.bl...@emc.com writes: Black, The next to last paragraph on p.3 begins with this sentence: Black,For these reasons, channel binding MUST be implemented by Black, peers, EAP servers and AAA servers in environments where EAP Black, authentication is used to access application layer services. Black, It appear that this MUST requirement applies to all uses Black, of EAP, including network access authentication, not just Black, application layer access authentication. If so, that's not Black, immediately obvious from the text, and an additional Black, sentence should be added to make this clearer. If not, the Black, above sentence needs to exclude network access Black, authentication from that requirement. I know you're correct that AAA servers and EAP servers need to implement channel binding for network access in such environments. I'm not sure whether peers only doing network access SHOULD implement channel binding or MUST implement channel binding. Practically speaking, it will be a while before peers implement channel binding for network access. The sorts of attacks that result without channel binding are attacks where a peer thinks it is doing network access authentication but what it's really doing is helping an attacker access an application. If all the application access peers support channel binding, then you could potentially require the eap-lower-layer attribute or similar for application authentication and work securely in environments where peers for network access have not been updated yet. [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 could state this a bit better as something like: In environments where EAP is used for applications authentication and network access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD support channel binding to explicitly identify the reason for authentication. Any new usage of EAP MUST support channel bindings to prevent confusion with network access usage. It's also kind of tempting to stick our head in the sand and just add the clarification that yes, we mean network access too. --Sam
Re: IETF Diversity
Phillip, For the record, there have been several ongoing efforts. First, there is a diversity design team. We expect some results from them before IETF-87, lets deal with those when they come. Second, the IAOC has looked hard at the possibilities for reaching further out in the geographical world - you must have seen the big discussion about South America a while ago. I expect some news from the IAOC on this front soon. Third, we have worked with ISOC and others to look at how we could expand outreach efforts, be it geography, new types of participants, or other factors. Fourth, I think many of us have had the topic in our minds in our daily work, e.g., when looking at competence profiles for tasks, etc. See Peter's mail. All in all, I'd of course be happier if we had made a big change and impact immediately. But the reality is that these types of changes are hard and take some time. But there is definitely efforts on the way. Those will have effects, long term. That being said, I don't think we've done enough. Do you have suggestions on what additional things we could do? (Or you, or others on the list?) Jari
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
John, For the record, I still believe that 2050bis should be published. Regardless of what I think of some of the things it says, I think it is reasonably reflective of reality and that reality is always worth documenting. Thanks. As to my more general comments, they were not really addressed to 2050bis and I have no desire to start a discussion of them here. However, some assertions about how well ICANN is working were made on this list by people who do not usually participate actively in IETF's technical work. In part because some ICANN decisions and behaviors does affect the fate of IETF protocols and the state of the Internet generally, Ok. Understood. I would welcome a discussion (definitely somewhere else) about that difference in perceptions … That would include an offlist discussion of why your perceptions and mine may differ should you find such a discussion useful. Fair enough. Hopefully some of that could be fed into ICANN as well. (I should probably have indicated that my experience is very limited. I didn't want to indicate that there are no challenges - I know there are.) Jari
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
I think we could state this a bit better as something like: In environments where EAP is used for applications authentication and network access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD support channel binding to explicitly identify the reason for authentication. Any new usage of EAP MUST support channel bindings to prevent confusion with network access usage. 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 network authentication - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an application binding, whatever that is? [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
Re: IETF Diversity
On 6/18/13, Phillip Hallam-Baker hal...@gmail.com wrote: I am rather disappointed that there hasn't been any followup to the diversity discussion that took place at the plenary. I thought there are some people following/working this up, and made some progress. However, I agree that I seen no progress written/reported to us, I do applications and I do security and so having a diverse range of input is critical if the final product is going to be useful. There are no gender or cultural issues in packet routing that I am aware of. But once we get to the application layer they become central. I agree that at that layer you will face the community. It does not take 100 people to write a specification but it does take a large number of people to adequately gather requirements. Taking requirements from 100 people from almost the same background and perspective is not very productive. I am aware that I have a limited personal perspective which is why I actively seek out other perspectives. I mentioned similar idea of that before, and I agree IETF needs diversity to progress. At the plenary I pointed out that there have been women involved in IETF ever since I started in IETF over 20 years ago now. Yet we have an IAB and an IESG with only one female member who is not ex-officio (according to their Web sites) That situation should be something that has the IETF management worried but I can't see much sign of that. I suggested also that we need more women in management, so I support that, however, majority men may not want that, so what can we do The IETF is unlikely to die but it can lose influence beyond the IP and DNS core. Sooner or later someone is going to work out how to establish an applications standards process that is gender and culture inclusive. And we know from experience that in our environment there can be a remarkably small time between the idea and establishing an institution. It is good if IETF realise that it can loose, so it will work harder. The IETF is mostly doing its meetings in North America so its culture is closer to North America culture. Minecraft was launched in 2011 and they had 4,500 people at their first international conference that year, they are now about to have their third. So they went from having nothing to having a larger participant community than the IETF in a matter of months. I think that is good news, and that IETF should realise how did that happen, and realise what is wrong in IETF. I suggested before that IETF encourages participants, and gave many responses but still I was feeling ignored. The IETF is a community known for valuing consensus rather than seeking diverse views. I see a real risk that the consensus being built here is a false consensus built by excluding opposing views rather than a real consensus built on reconciling them. I already mentioned that before, I found out that many say we want consensus when they don't have good engineering reason, and when there is no consensus they go back to technical reasons. Bringing opposing views to this forum is invariably a thankless task. The assumption is that if you can't hack it here well that is your fault and your problem. Case in point, each time I get something wrong in RFC2HTML and I get the error message 'You Lose', my natural response is 'why the heck am I bothering wasting my time here'. We waste time only if management don't listen to the minorities/diversed of the community. I do not think that gender is the only diversity problem in IETF but it is one that can be measured and the IETF is conspicuously failing. We also have a rather severe age problem, twenty years ago EKR and myself were among the youngest participants in most discussions and setting aside the grad students the same is usually true today. I agree, The perspective is going to need to change. Rather than looking for ways to encourage a few token women to work their way up through the existing selection regime we need to look at what sort of selection and participation and representation structures will encourage diversity. I think it is very easy to encourage people, and very easy to discourage people, the difficult part is to maintain people encouraged and liking to continue participating in the IETF. Many people in life hate CHANGE, so that is another difficulty, the IETF should get use to CHANGE. Thanks for your input it makes a greater impact than my inputs maybe because my english. AB
Re: IETF Diversity
When I make a statement at the microphone and then have multiple people come to thank me afterwards for making that point I don't consider it pontificating. I do however consider your own response to be an example of the type of exclusionary behavior that I was talking about. Dismissing those concerns as 'pontificating' does not help matters. And you have no idea what actions I have taken to attempt to recruit people to get involved. The issue was raised in the IETF plenary I would have expected mention of a followup mailing list to be made here on the ietf discussion list. On Tue, Jun 18, 2013 at 1:09 PM, Peter Saint-Andre stpe...@stpeter.imwrote: On 6/18/13 10:52 AM, Phillip Hallam-Baker wrote: I am rather disappointed that there hasn't been any followup to the diversity discussion that took place at the plenary. Speak for yourself. Some of us are taking concrete actions (e.g., recruiting people for document shepherd and WG chair roles) instead of pontificating at the mic. Peter -- Peter Saint-Andre https://stpeter.im/ -- Website: http://hallambaker.com/
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On Tue, Jun 18, 2013 at 12:54 PM, Jari Arkko jari.ar...@piuha.net wrote: Chris: The last call on RFC 2050 bis has ended. The draft will be shortly on the IESG telechat, up for an approval decision and/or suggestion for changes. I personally think it is ready to move forward. That is not to say that we wouldn't take comments, if you have some. ok, cool... my only comment was on the timing issue... which I doubt will get fixed before pub time, and isn't a show-stopper though ... will make the conversation at the RIR level a bit more challenging for some folks I imagine. -chris
Re: IETF Diversity
On 6/18/2013 10:17 AM, Jari Arkko wrote: Second, the IAOC has looked hard at the possibilities for reaching further out in the geographical world Jari, The only action that's been cited has been holding a meeting in that region. A number of us have posted comments suggesting that this is unlikely to be an effective recruiting technique; a few also offered thoughts of other approaches. I won't rehash the rationales that have been offered. If other avenues of recruiting are being explored by the IAOC, what are they? If the only avenue being considered is a meeting in the region, it would be helpful to see some response to the concerns raised about this as a recruiting tool. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [Back to] Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On Tue, Jun 18, 2013 at 12:15 PM, David Conrad d...@virtualized.org wrote: Chris, On Jun 18, 2013, at 8:57 AM, Christopher Morrow morrowc.li...@gmail.com wrote: I'm not such a fan of the draft, mostly because it appears to remove some principles that some RIR folk hold up in their policy discussions as important... while not having a backstop in said policies to replace the originals from 2050. Which principles are you referencing? at least needs-based allocations... So, I should be clear that I don't 'like' that 'the ietf has dictated' to the community some actions they must take with respect to allocation policy that the RIR communities are supposed to agree upon amongst their individual selves (perhaps coordinated, perhaps not). So I understand why these things (and actually agree with) the removal of these things. I think though there could be perceived a situation where 'oops, no more rules!!' because the RIRs (arin's community at least) hasn't pushed for these items explicitly in their policy manual. (arin has some of this via linkages to 2050 in their PDP.. but not in the community-built nrpm) It's worth noting, to me at least, that the 'no rules!' bit could be viewed as a good thing, and could be a method to pull back as a community and gather some data on how the system reacts. Additonally, it could be the case that the community really does not want this sort of restriction in place in the name of 'making the move to ipv6 happen more quickly and more completely' (a-la burning your ships upon landing in the 'new world'). as a summary: 1) happy to see the principles / restrictions imposed from 'above' on the RIR's removed 2) happy to see the doc move forward 3) interested to see how the communities at the RIR level deal with this 4) sad a bit that the ARIN community (at least) didn't move to put in place protections/restrictions/garter-belts/suspenders/etc before this doc is published. -chris Thanks, -drc
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
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
Re: IETF Diversity
On 6/18/13 12:08 PM, Phillip Hallam-Baker wrote: When I make a statement at the microphone and then have multiple people come to thank me afterwards for making that point I don't consider it pontificating. I do however consider your own response to be an example of the type of exclusionary behavior that I was talking about. Dismissing those concerns as 'pontificating' does not help matters. And you have no idea what actions I have taken to attempt to recruit people to get involved. No, I don't. I'm happy to hear that you're getting busy from the ground up, instead of waiting for official action. The issue was raised in the IETF plenary I would have expected mention of a followup mailing list to be made here on the ietf discussion list. Fair enough. Peter -- Peter Saint-Andre https://stpeter.im/
Re: IETF Diversity
On 06/18/2013 07:42 PM, Peter Saint-Andre wrote: On 6/18/13 12:08 PM, Phillip Hallam-Baker wrote: The issue was raised in the IETF plenary I would have expected mention of a followup mailing list to be made here on the ietf discussion list. Fair enough. Not quite. My local ietf@ietf.org folder has 392 messages that match a search for diversity all but of few of which are since this March, e.g. most recently before this thread [1]. There is a lot of noise on this list so I can understand that threads might be missed but its not true to say there's been nothing on here. S. [1] http://www.ietf.org/mail-archive/web/ietf/current/msg80076.html Peter
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. when that feedback is that the icann does not really listen to feedback, i think there is a problem with this approach. the examples of earwax are rife. randy
Re: IETF Diversity
The issue was raised in the IETF plenary I would have expected mention of a followup mailing list to be made here on the ietf discussion list. Fair enough. I'm probably misunderstanding something basic here, because I thought there already was/is a list established: Diversity open mailing list https://www.ietf.org/mailman/listinfo/diversity d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
On Jun 18, 2013, at 11:39 AM, Sam Hartman hartm...@painless-security.com wrote: 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. [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. --Sam
Re: IETF Diversity
Hi Phil, On 06/18/2013 02:08 PM, Phillip Hallam-Baker wrote: When I make a statement at the microphone and then have multiple people come to thank me afterwards for making that point I don't consider it pontificating. I do however consider your own response to be an example of the type of exclusionary behavior that I was talking about. Dismissing those concerns as 'pontificating' does not help matters. And you have no idea what actions I have taken to attempt to recruit people to get involved. The issue was raised in the IETF plenary I would have expected mention of a followup mailing list to be made here on the ietf discussion list. Apologies. The announcement of the diversity list was sent to the IETF announcement list and not the discussion list. The diversity list can be found here as Dave C. mentioned. https://www.ietf.org/mailman/listinfo/diversity Thanks Suresh
RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
[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. 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. 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 could state this a bit better as something like: In environments where EAP is used for applications authentication and network access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD support channel binding to explicitly identify the reason for authentication. Any new usage of EAP MUST support channel bindings to prevent confusion with network access usage. 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 network authentication - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an application binding, whatever that is? Thanks, --David -Original Message- From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] Sent: Tuesday, June 18, 2013 1:10 PM To: Sam Hartman Cc: Black, David; stefan.win...@restena.lu; General Area Review Team; ab...@ietf.org; ietf@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 On Jun 18, 2013, at 7:18 AM, Sam Hartman hartm...@painless-security.com wrote: Black, == Black, David david.bl...@emc.com writes: Black, The next to last paragraph on p.3 begins with this sentence: Black,For these reasons, channel binding MUST be implemented by Black, peers, EAP servers and AAA servers in environments where EAP Black, authentication is used to access application layer services. Black, It appear that this MUST requirement applies to all uses Black, of EAP, including network access authentication, not just Black, application layer access authentication. If so, that's not Black, immediately obvious from the text, and an additional Black, sentence should be added to make this clearer. If not, the Black, above sentence needs to exclude network access Black, authentication from that requirement. I know you're correct that AAA servers and EAP servers need to implement channel binding for network access in such environments. I'm not sure whether peers only doing network access SHOULD implement channel binding or MUST implement channel binding. Practically speaking, it will be a while before peers implement channel binding for network access. The sorts of attacks that result without channel binding are attacks where a peer thinks it is doing network access authentication but what it's really doing is helping an attacker access an application. If all the application access peers support channel binding, then you could potentially require the eap-lower-layer attribute or similar for application authentication and work securely in environments where peers for network access have not been updated yet. [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
RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
[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. 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 to explicitly identify the reason for authentication. o Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. Thanks, --David -Original Message- From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] Sent: Tuesday, June 18, 2013 1:47 PM To: Black, David Cc: stefan.win...@restena.lu; General Area Review Team; ab...@ietf.org; ietf@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 I think we could state this a bit better as something like: In environments where EAP is used for applications authentication and network access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD support channel binding to explicitly identify the reason for authentication. Any new usage of EAP MUST support channel bindings to prevent confusion with network access usage. 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 network authentication - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an application binding, whatever that is? [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
Re: IETF Diversity
I am getting my ietf@ietf.org on my gmail account. I have no filters that delete mail, no mails with 'ietf' in them in my spam folder and no copies of 80% of the mails to this list. On Tue, Jun 18, 2013 at 2:50 PM, Stephen Farrell stephen.farr...@cs.tcd.iewrote: On 06/18/2013 07:42 PM, Peter Saint-Andre wrote: On 6/18/13 12:08 PM, Phillip Hallam-Baker wrote: The issue was raised in the IETF plenary I would have expected mention of a followup mailing list to be made here on the ietf discussion list. Fair enough. Not quite. My local ietf@ietf.org folder has 392 messages that match a search for diversity all but of few of which are since this March, e.g. most recently before this thread [1]. There is a lot of noise on this list so I can understand that threads might be missed but its not true to say there's been nothing on here. S. [1] http://www.ietf.org/mail-archive/web/ietf/current/msg80076.html Peter -- Website: http://hallambaker.com/
Re: IETF Diversity
On Tue, 18 Jun 2013, Phillip Hallam-Baker wrote: I am getting my ietf@ietf.org on my gmail account. I have no filters that delete mail, no mails with 'ietf' in them in my spam folder and no copies of 80% of the mails to this list. That reads like you are missing 80% of the email distributed via this list? That somehow, you are missing many emails w/o your filters being responsible?
Re: IETF Diversity
Dave, We created an IETF-TF in LACNOG; as you we also think that only a meeting is not enough and along with ISOC, ccTLDs, LACNIC and other organizations we are trying to encourage and prepare more people to participate in the IETF by sending comments, reviewing documents and writing RFCs. There are some specific actions that we are doing to fulfill that goal (I can give more details if somebody is wanted to know). As Jari pointed out, the results are not immidiately but we are working on that. If interested, anybody can subscribe at: https://mail.lacnic.net/mailman/listinfo/ietf-lac Regards, as On 6/19/13 1:20 AM, Dave Crocker wrote: On 6/18/2013 10:17 AM, Jari Arkko wrote: Second, the IAOC has looked hard at the possibilities for reaching further out in the geographical world Jari, The only action that's been cited has been holding a meeting in that region. A number of us have posted comments suggesting that this is unlikely to be an effective recruiting technique; a few also offered thoughts of other approaches. I won't rehash the rationales that have been offered. If other avenues of recruiting are being explored by the IAOC, what are they? If the only avenue being considered is a meeting in the region, it would be helpful to see some response to the concerns raised about this as a recruiting tool. d/
Last Call: draft-ivov-xmpp-cusax-06.txt (CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)' draft-ivov-xmpp-cusax-06.txt as Informational RFC 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 i...@ietf.org mailing lists by 2013-07-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes suggested practices for combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). Such practices aim to provide a single fully featured real-time communication service by using complementary subsets of features from each of the protocols. Typically such subsets would include telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This specification does not define any new protocols or syntax for either SIP or XMPP. However, implementing the practices outlined in this document may require modifying or at least reconfiguring existing client and server-side software. Also, it is not the purpose of this document to make recommendations as to whether or not such combined use should be preferred to the mechanisms provided natively by each protocol (for example, SIP's SIMPLE or XMPP's Jingle). It merely aims to provide guidance to those who are interested in such a combined use. The file can be obtained via http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-yusef-dispatch-ccmp-indication-04.txt (Conference Focus Indicating CCMP Support) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Conference Focus Indicating CCMP Support' draft-yusef-dispatch-ccmp-indication-04.txt as Proposed Standard 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 i...@ietf.org mailing lists by 2013-07-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Centralized Conferencing Manipulation Protocol document defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for the XCON conference event package RFC 4575 [RFC4575] and take advantage of CCMP operations on the conference. This document describes a few options to address the above limitation with the pros and cons for each approach, and recommends two to be used depending on the need of the UA. The first approach uses the Call-Info header and as a result this document updates RFC 3261 [RFC3261]. The second approach defines a new value for the 'purpose' parameter in the 'service-uris' element in the SIP conferencing event package, and as a result this document updates RFC 4575 [RFC4575]. The file can be obtained via http://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-indication/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-indication/ballot/ No IPR declarations have been submitted directly on this I-D.
Document Action: 'Security Threats for NHDP' to Informational RFC (draft-ietf-manet-nhdp-sec-threats-06.txt)
The IESG has approved the following document: - 'Security Threats for NHDP' (draft-ietf-manet-nhdp-sec-threats-06.txt) as Informational RFC This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ Technical Summary This document analyzes common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. Working Group Summary The process for reaching working group consensus on this was smooth; no controversy existed. Working group consensus behind the document is solid. Document Quality This document does not specify a protocol, therefore no implementations are available. There are several NHDP implementations existing, and the WG has a thorough understanding of the protocol and its security considerations. Personnel Joseph Macker (joseph.mac...@nrl.navy.mil) is the document shepherd. Adrian Farrel (adr...@olddog.co.uk) is the responsible AD.
RFC 6934 on Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)
A new Request for Comments is now available in online RFC libraries. RFC 6934 Title: Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs) Author: N. Bitar, Ed., S. Wadhwa, Ed., T. Haag, H. Li Status: Informational Stream: IETF Date: June 2013 Mailbox:nabil.n.bi...@verizon.com, sanjay.wad...@alcatel-lucent.com, ha...@telekom.de, hongyu.lihon...@huawei.com Pages: 39 Characters: 104111 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ancp-pon-05.txt URL:http://www.rfc-editor.org/rfc/rfc6934.txt The purpose of this document is to provide applicability of the Access Node Control Mechanism to broadband access based on Passive Optical Networks (PONs). The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control Mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net. This allows for performing access-link-related operations within those network elements to meet performance objectives. This document is a product of the Access Node Control Protocol Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6967 on Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments
A new Request for Comments is now available in online RFC libraries. RFC 6967 Title: Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments Author: M. Boucadair, J. Touch, P. Levis, R. Penno Status: Informational Stream: IETF Date: June 2013 Mailbox:mohamed.boucad...@orange.com, to...@isi.edu, pierre.le...@orange.com, repe...@cisco.com Pages: 24 Characters: 53498 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-intarea-nat-reveal-analysis-10.txt URL:http://www.rfc-editor.org/rfc/rfc6967.txt This document is a collection of potential solutions for revealing a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches. This document is a product of the Internet Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
New Non-WG Mailing List: nsc -- Network Service Chaining
A new IETF non-working group email list has been created. List address: n...@ietf.org Archive: http://www.ietf.org/mail-archive/web/nsc To subscribe: https://www.ietf.org/mailman/listinfo/nsc Purpose: Network services are widely deployed and essential in many networks. The services provide a range of functions such as security, WAN acceleration, and server load balancing. Service functions that form part of the overall service may be physically located at different points in the network infrastructure such as the wide area network, data center, campus, and so forth. New data center network and Internet cloud architectures require more flexible network service deployment models. Additionally, the transition to virtual platforms requires an agile service insertion model that supports elastic service delivery, the movement of service functions and application workloads in the network and the ability to easily bind service policy to granular information such as per-subscriber state. Service chaining is a broad term used to describe a common model for delivering multiple services in a specific order. Service chaining de-couples service delivery from the underlying network topology and creates a dynamic services plane that addresses the requirements of cloud and virtual application delivery. Traffic that requires service chaining is classified, and context is shared between the network and the services. This list is for discussion of aspects of Network Service Chaining (NSC) that impact upon the IETF's work, the applicability of IETF protocols to NSC, as well as new protocols and changes to IETF protocols that might be required. A BoF has been proposed for NSC in Berlin. This list also serves to discuss that BoF proposal. For additional information, please contact the list administrators.
