Re: [Secauth] secauth use case - What is next?

[Alan DeKok <[e-mail]>]

On Dec 3, 2014, at 4:11 PM, Hosnieh Rafiee <[e-mail]> wrote:
>  In other
> words, It is so much administrative works if only everything should be done
> either by operators or by interfaces between end users and operators (such
> as hotels, etc.) but  with SDN scenario the capability are added to the
> infrastructure and manageable by operators.

  That works in certain narrowly defined scenarios.

> Therefore, via management
> interfaces, operators need only enable/disable this feature based on the
> request of their customers. So, In one hand, it appears that the overhead is
> on industries who wants to offer this service or develop such protocols for
> communications on data centers, etc. 

  I’m not clear on what that means.

> 
>> The operators tend to not be involved in the IETF.  I spend a fair amount
> of
>> time talking to them, though.
> 
> I am not quite sure about what you said since I saw some of them active in
> other groups and I think a few of them are a member of this group too.

  I just joined this list.  My experience has been that the *operational* side of operators are too busy keeping systems running to have much IETF involvement.

> Maybe I also should highlight the trust between two controllers especially
> when a user wants to receive the same service in target network under the
> control of different industries. In other words, user a used voip in first
> network and wants to continue using it in second network. Maybe by default
> this service is not enable on firewall in the second network. So there might
> be a need to enable this service based on policy for this user (this is of
> course an example).

  That works if the policies can be described in an inter-operable way.  Doing that is hard.

> In one hand that we talk about this trust, in other
> hand, we have to consider a shield controller. This is why, I am also not
> sure RADIUS or other approaches will be considered in SDN architecture.

  Maybe.  If you want to to inter-domain authentication using EAP… your #1 choice is RADIUS.

> There might be new requirements that is not supported by RADIUS or not
> easily handled. Like the example scenario I have explained.

  I’m not clear how those situations can’t be easily handled with RADIUS.  People are largely doing similar things today.

> I agree that in mobile network, such scenario was implemented but mostly it
> is only for one Operator. I saw some exceptional cases where, for example, a
> user moves from one country to another and operator in source country does
> not have coverage, then this user might be registered with a new operator
> that has SLA with his operator in source country. But how this SLA
> exchanged? How many administrative work it was needed that this happened?

  Diameter.  There are hundreds of specifications in 3G, each of which are hundreds of pages long, all defining exchange of SLAs for users.  These exchanges happen *millions* of times a day, every way.  They’ve been deployed for many years.  There are billions of dollars in equipment sold every year to do exactly this.

  It’s a solved problem in the 3G world.

> This is maybe the demotivation for operators. Now, how we can simplify this
> use case  (of course this time only for internet) ? I do not think  Abfab or
> other groups covered this scenario.

  Abfab is about roaming inside of a consortium.  It’s a light version of the 3G specs.

>> Eduroam is widely used.  IETF WGs like Abfab are standardizing
> cross-domain
>> authentication, where the domains require no previous coordination to
>> communicate.  They only require a common CA, which shows that both
>> domains are part of the same roaming consortium.
> 
> So, is the assumption the existence of a public CA? In other word, any
> network who wants to use this service needs to have a valid certificate? or
> it is like trusted anchor?

  It’s a trusted anchor for eduroam.  the certificate indicates that the system is a trusted member of a consortium.

> I do want to skip the use of CA in secauth and find different solution to
> provide this trust because of privacy and perhaps security reasons.

  Eduroam uses a CA.  A CA is not *required* in order to build a consortium of trusted partners.  It’s just the easiest way to do it.

  One reason to use a CA is to control membership.  The consortium *cannot* rely on a public CA such as is done by web browsers.  The reason is that the problem is different.

  Web browsers want to know that “ietf.org” is really the IETF.  They do this by verifying that the certificate on https://ietf.org is signed by a CA which the web browser trusts.

  Consortium members want to know that other entities are members of the same consortium.  A CA specific to the consortium does this.  A top-level CA such as with a web browser doesn’t do that.

> True, however, I think, it supports a limited scope because
> pre-configuration needed for such scenarios. Can you move this sensor
> devices to unknown networks that it never supposed to move to that network?

  Can the sensor be moved to another network?  No.  Because the networks aren’t configured to allow the sensors to roam.  The sensors aren’t configured with the knowledge of multiple networks.

> How much efforts is needed to make this happened?

  Very little.  Sensors can have a list of known networks.  Cell phones do this today.  Networks can be configured to allow sensors to roam.  They do this will cell phones today.

> Now what if we consider an automated process that is infrastructural based
> and not by the agreements of each single players with each other in this
> scenario but the agreements are in higher level?

  It’s something I’ve been working towards for a decade.  My experience has been that the authentication interconnect is simple.  RADIUS, Diameter, IPSec, whatever.  It’s all trivial.  The hard part is the policy exchanges.  How do you describe the policies?  Firewall rules?  SAML?  Something else?

  Alan DeKok.