Hello Hosnieh, I don't see any responses to the points/questions raised by Ted and Michael. When SecAuth was closed, I and others provided feedback to help you narrow the scope of work so that this could turn into something successful. If you are working to reduce the number of problem you solve at one time, that should help. Your plan to implement code along with OpenStack could help a lot to solidify your ideas and that is a good next next step. To Ted's point on the NoteWell and your plan to progress to a BoF and eventual working group, I'd like to suggest a set of steps that should help you to be successful: 1. Pick a few people that were helpful in the SecAuth list to collaborate with directly. Email is fine, a list is not necessary. 2. The team should understand the goal is to develop work that will get moved to the IETF. This means they understand that the NoteWell will apply once that work is contributed. 3. Choose one of the 3 problems that were in discussion on SecAuth and only focus on that one problem. 4. Document the focused problem statement. 5. Document one or more use cases that directly align with the problem statement. 6. Document any requirements, especially unique ones to the problem. 7. Determine if existing protocols can be used for that solution. Document why related protocols may or me not be a fit for the problem space. 8. Identify overlap with existing working groups. Document why or why not there is a connection between this proposed work and each of the related working groups. 9. Define a narrow scope of work that might evolve to a charter. 10. Begin to collaborate on a draft. 11. Develop the draft enough to ensure the problem statement, requirements, and use case is clearly articulated. Perhaps have the draft reviewed by another peer. 12. Develop open source code to demonstrate your proposal. This would be extremely helpful. 13. Contact Sec ADs again to discuss progress and next steps. I wish you lots of luck in your work and ask that you consider these steps to guide your work. Best regards, Kathleen On Fri, Jan 23, 2015 at 10:44 AM, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote: > > Hosnieh Rafiee <ietf@xxxxxxxxxxx> wrote: > > The name of this group is: SDNAuth > > > This group focuses on the following scope: > > - Authentication and authorization of application to the network > > control - SDNAuth only provides the place where a network control can find > > policy but applying policy is out of the scope of SDN auth > > - Authentication and authorization of two controllers (exchanging > > policy is out of the scope) > > - Optimization of authentication and authorization of network elements > > + user at the same time > > All of this seems very much internal-to-Autonomous-System. There are a bunch > of solutions which exist already, many of which are aimed at tty/CLI-style > logins. (Radius, tacacs and kerberos come to mind). Some many inappropriate > for the m2m-type communication you envision; or may require some profiling to > make work. > > > > - Authentication and authorization of an app to a security function > > service such as a firewall (applying any rules on the firewall is out of > > scope but authentication and showing the place of policies are in scope) : > > SDN/NFV authentication > > I don't know what the scope of "app" here is, but I think that perhaps it > means that my mobile phone can ask some firewall that is (perhaps) not within > my enterprise for access. Such as when I'm roaming at your office. > But, even if it turns out that I'm at my office, the firewall is not *my* > firewall (I'm not the admin), it's my enterprises' firewall. > As such, this relates to such things as the "authenticated-firewall-traversal > (AFT)" problem (and WG) of 2 decades ago > <http://datatracker.ietf.org/wg/aft/charter/>, and also to much more modern > things like PCP, RSVP, uPNP and the like. It would be wonderful if we could > solve the problems of being able to scalably authenticate to network elements > for the purpose of either reserving bandwith (in a positive, I care about > this traffic way), and also for deflecting traffic (in a negative, please > filter this DDoS traffic out further away from my constrainted pipe). > > On this, you seem to have a totally different set of requirements different > From the SDN space, and I don't see how it matters that SDN is involved at > all. > > I think that you should remove this item from your SDNauth scope; we've been > through this dicussion multiple times now. It's not that it isn't important; > its really really really important, but it has a very different set of > constraints. > > > > You can find more information about this group on the info page. > > > If you are interested on the scope of this group, please feel free to join > > clicking on the following address: > > > < https://mail.rozanak.com/mailman/listinfo/sdnauth > > > > --------------------------------------------------------------- > > > We had some discussions on "secauth" at IETF and would like to continue the > > discussion with interested folks in an external group. The goal is to > > prepare the final draft of charter for possible BoF. > > > This group also plans to have an implementation by using Openstack as a > > based. Later, I will update the info page of the group with the link to a > > project repository. > > > Thanks, > > Best, > > Hosnieh > > > P.S. Please note that the group is public including its archive. > > > > -- > Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- Best regards, Kathleen