-----Original Message-----
From: Kathleen Moriarty
[mailto:kathleen(_dot_)moriarty(_dot_)ietf(_at_)gmail(_dot_)com]
Sent: Wednesday, February 04, 2015 12:05 AM
To: Michael Richardson
Cc: Hosnieh Rafiee; IETF
Subject: Re: SDNAuth - Secure SDN authentication and authorization -
Interested?
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(_at_)sandelman(_dot_)ca> wrote:
Hosnieh Rafiee <ietf(_at_)rozanak(_dot_)com> 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(_at_)sandelman(_dot_)ca>, Sandelman Software
Works
-= IPv6 IoT consulting =-
--
Best regards,
Kathleen