Subject: [I2nsf] inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side

From: Linda Dunbar <[email-masked]>
Date: Fri, 10 Apr 2015 16:39:21 +0000

Kathleen,
I2NSF has two layers of interfaces:

-          Security policies interface towards client side (between clients and security service providers)

-          Security policies at functional layer (between Security Controller and individual functions).
I noticed that IETF had work on Generic Security Service APIs (RFC2078, RFC2743, RFC2744, RFC 4752, RFC5554). Is it an active working group? We are investigating the feasibility of using GSSAPIs for the I2NSF Interface towards client Layer. But need to study the pros-cons of GSSAPI.
Do you know much of GSSAPIs? If not, can you recommend someone else who know more?
Thank you very much.
Linda Dunbar

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 10 Apr 2015 14:28:17 -0400

Hi Linda,

I'm pretty sure ABFab uses the GSS-API as does Kitten, so Sam may be a good person to ask.

John Linn has a different email address.  If you have a question for him that Sam can't help with, I can reach out to John and see if I can add him to the thread with an email he's okay using on list.

Thanks,
Kathleen 

Sent from my iPhone

> On Apr 10, 2015, at 12:39 PM, Linda Dunbar <[email-masked]> wrote:
> 
> Kathleen,

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Apr 2015 14:08:56 -0400

How do the security requirements of the interface between the client and
I2SF differ from typical client-server applications?
That is, how do your security requirements differ from LDAP, ssh, and
IMAP?

--Sam

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 16 Apr 2015 03:57:01 +0000

The ultimate goal of I2NSF is to enable enterprises to utilize security functions not hosted on their own premise but instead hosted in service provider domain, to establish how to communicate desired security policies to NSF and how to get performance data or report out of NSF.

Past:
      customers own security devices, manage them directly, all security policies are supported by single device. Features are locked in

Future (and now):
      security functions are distributed across networks, some are at customer premises, some are hosted in service provider premises, some are accomplished by a collection of security functions. Not all functions are equal

The Problems:
      Customers don't own actual security devices anymore
      Customers need to have their security policies supported by a collection of security functions in both their own and security service providers' premises.
      Customers need assurance of their specified security policies are properly enforced by the security functions in the provider domain.
      Without standard interfaces to Security Functions, Service Providers can't build proper  management system to manage many types of security functions from different vendors.

Linda

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: Wednesday, April 15, 2015 1:09 PM
To: Kathleen Moriarty
Cc: Linda Dunbar; [email-masked]
Subject: Re: inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side

How do the security requirements of the interface between the client and I2SF differ from typical client-server applications?
That is, how do your security requirements differ from LDAP, ssh, and IMAP?

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Apr 2015 09:26:33 -0400

Linda, I'm confused and frustrated when I read your message because I
don't understand how it was responsive to the question I asked.
I would like to understand how the communications security of your
protocol will work, and to that end I'd like to understand how your
requirements are similar to requirements for protocols we've already
worked on.
I was not able to learn anything about the communications security of
your protocol from your message.

--Sam

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 16 Apr 2015 15:18:11 +0000

Sam,

I2NSF is more about security functions management, i.e. how customers can request & monitor their desired security policies from service providers.

There are two aspects of I2NSF:
1)  the security policy information exchange between enterprises and the service provider that offers the hosted security functions
2) the secure channel for the information exchange. (I think this is what you call "communication security" )

I2NSF's first step will focus on 1) above. The "communication security" (2) above is secondary.

draft-lopez-i2nsf-packet-00 suggests that the 1) above can be characterized by:

*       Subject - match values based on packet data
            Packet header - Can be standardized
            Packet payload - Provided by NSF capabilities
*       Object - match values based on context
            Ex.: State, time, geo-location, etc.
            Many can (and should) be standardized, but many also from NSF capabilities
*       Function - invoked security function
            Defined by NSF capabilities
            Function:Instance (ex. IPS:<signature base> which can be provided by vendors)
*       Action - egress processing
            Invoke signaling
            Packet forwarding and/or transformation
            Possibility for SDN/NFV integration

We have done some study of GSS-API, and assessed that GSS-API might be useful for the 2) above.
But for 1), we think the NETCONF or Restful API is more appropriate.

Do you agree? Any other suggestions?

Linda

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: Thursday, April 16, 2015 8:27 AM
To: Linda Dunbar
Cc: Kathleen Moriarty; [email-masked]
Subject: Re: inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side

Linda, I'm confused and frustrated when I read your message because I don't understand how it was responsive to the question I asked.
I would like to understand how the communications security of your protocol will work, and to that end I'd like to understand how your requirements are similar to requirements for protocols we've already worked on.
I was not able to learn anything about the communications security of your protocol from your message.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Apr 2015 11:24:27 -0400

OK.
Well, GSS-API is a communications security layer.
If you aren't ready to discuss your communications security then you
aren't ready to think about whether GSS-API is a good fit for your work.

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 16 Apr 2015 15:57:34 +0000

Sam, 

Thank you very much for the feedback. 
TLS is another way to secure the communication channel. 

For the purpose of exchanging security policies between clients and provider and reporting data for clients to monitor their desired security policies enforced by security functions hosted in a different domain, what is your opinion of pros/cons of using GSS-API vs. TLS? 

Thanks, Linda

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Thursday, April 16, 2015 10:24 AM
To: Linda Dunbar
Cc: Kathleen Moriarty; [email-masked]
Subject: Re: inquiry pros/cons of using IETF's GSSAPIs for I2NSF policy Interface towards client side

OK.
Well, GSS-API is a communications security layer.
If you aren't ready to discuss your communications security then you aren't ready to think about whether GSS-API is a good fit for your work.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Apr 2015 11:59:09 -0400

>>>>> "Linda" == Linda Dunbar <[email-masked]> writes:

    Linda> For the purpose of exchanging security policies between
    Linda> clients and provider and reporting data for clients to
    Linda> monitor their desired security policies enforced by security
    Linda> functions hosted in a different domain, what is your opinion
    Linda> of pros/cons of using GSS-API vs. TLS?

I'd need to have an answer to the question of how your requirements
differ from things like we've done before.
For many application protocols the combination of TLS + SASL has worked
very well.
I'd recommend that combination  to you if it works for your needs.
TLS + SASL will also happen to meet the needs of anyone who wants
GSS-API for security.

--Sam