Subject: [Sigtran] FW: some comments on security for sigtran

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 30 May 2002 10:24:30 -0700

Hi Folks,

I would like to fill you in on the discussion of security that
has been holding up approval of SUA.  We have had comments come
in from Eric Rescorla on the IAB requesting that we provide more
detail about security for Sigtran applications in general (we 
may have had other comments, but these are the ones I am aware
of).  I believe that the renewed interest in security is part
of a more general shift in the security area away from IPsec
as the do-it-all solution and also a general desire to have
groups provide stronger and more detailed requirements for
security.

The solution appears to be to put together some additional text
on security requirements for Sigtran, esp. discussing keying
requirements and use of TLS vs. IPsec.

I have attached below
(1) a message from John Loughney, who has volunteered to put
together some appropriate text (thanks John!)
(2) my response to Scott and Eric on the security comments
(3) Eric's original comments to Scott (Eric has volunteered
to help with this issue as well)

You should ideally read the messages from bottom to top...

Comments welcome.

Cheers,

L. Ong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 30, 2002 12:08 AM
To: Ong, Lyndon; [email-masked]
Subject: RE: some comments on security for sigtran

Hi all,

For my 2 cents.  I could prepare text on TLS vs IPsec.  The main issues
is that for intradomain signaling, IPsec is a good solution.  For 
Intradomain signaling, TLS is probably better.  

Scott, my general feeling is that SIGTRAN protocols probably have
similar requirements as do Diameter, so perhaps I can 'steal'
some of the text I have written for Diameter and apply it for
SIGTRAN (M2UA, M3UA, SUA).  Does this sound like reasonable way
forward?  

Of course, after I produce the text, I can also submit it to 
the mailing list, as long as it is sufficient.

John

> -----Original Message-----
> From: ext Ong, Lyndon [mailto:[email-masked]]
> Sent: 30 May, 2002 02:19
> To: 'Scott Bradner'
> Cc: Loughney John (NRC/Helsinki)
> Subject: RE: some comments on security for sigtran
> 
> 
> Hi Scott,
> 
> Hope that your retreat is going well.  Couple of brief notes - DUA
> has been revised and should be OK with IANA, I checked text with
> Michelle and she seemed to be OK with this (will forward you the
> message), also V5UA has passed through WG Last Call with minimal
> comments and the next version to the editor should be suitable for
> your review.  
> 
> Now.  Regarding Eric's message, I believe that there is actually
> some miscommunication on Sigtran's goals, I don't believe that the
> intention is to use the protocols to transport signaling on the 
> public internet due to the lack of QoS mechanisms as much as the
> security issues.  I believe that the intention is to use the 
> protocols to allow signaling to be transported over a private
> internet (which could be dedicated to signaling or could be shared
> with a carrier's operations traffic, so long as some QoS mechanism
> is supported) so that the carriers can get away from the older
> SS7 technology to something cheaper and less specialized.  
> 
> However, this does not eliminate the security issues, since a
> private internet can also be penetrated, especially if its use
> is shared with other applications.  Going to Eric's two options,
> I believe that his Option 1 makes the most sense from a Sigtran
> point of view - people see these associations as virtual wires
> that connect entities like signaling gateways and IP service
> control points (like an MGC), I believe that most people do not
> expect that anyone with a PC application should be able to join
> the conversation (as opposed to SIP, which is designed for 
> arbitrary endpoints such as a voice over IP app running on 
> someone's PC).
> 
> The keying issue is a bit beyond my range, so I would defer to
> other folks on this.  The issue of IPSEC vs. TLS we probably have
> not that much bias on, the documents pointed to IPSEC originally
> because that appeared to be the general direction for security,
> these days it sounds like IPSEC and TLS are both considered 
> acceptable mechanisms.  The adaptation layers are pretty much
> uniformly assumed to be running over SCTP, I have not heard 
> anyone on the list talk of using them over TCP for some time.
> 
> How shall we proceed on this issue?  We have had pretty much the
> same security text in all of the adaptation layer specs, SUA was
> the first spec to be held up because of the text.  Shall we try 
> and rev the text to handle the new security issues?  If so, we
> need someone to be the "consultant" to make sure we are getting
> all of the issues identified.  If Eric is interested, we would
> be happy to have his help :o)
> 
> BTW, I would like to fill in the rest of the WG on this if
> that's OK.
> 
> Cheers,
> 
> Lyndon
> 
> 
> -----Original Message-----
> From: Scott Bradner [mailto:[email-masked]]
> Sent: Monday, May 27, 2002 1:33 PM
> To: Ong, Lyndon
> Subject: some comments on security for sigtran
> 
> 
> 
> From [email-masked]  Mon May 27 13:26:56 2002
> To: [email-masked]
> Subject: SIGTRAN comments
> Cc: [email-masked], [email-masked]
> Mime-Version: 1.0 (generated by tm-edit 7.108)
> Content-Type: text/plain; charset=US-ASCII
> Date: Mon, 27 May 2002 10:28:05 -0700
> From: Eric Rescorla <[email-masked]>
> 
> Scott, as promised, here's my SIGTRAN comments. I've expanded them a
> bit since the initial version. Obviously, I'm more than happy to talk
> to the SIGTRAN people about this.
> 
> ------------------------------------------------------------------
> Just so we're on the same page, I'll start with my one paragraph
> summary of SIGTRAN. This shouldn't be news, but I want to have it on
> the table lest it show that I'm confused :)
> 
> SIGTRAN SUMMARY
> The current telco infrastructure consists of a bunch of devices
> connected via hardwired private links. The purpose of SIGTRAN
> appears to be allow telco signalling (and sometimes data) to 
> run over the public Internet instead. This is done by specifying
> bindings of those protocols to IP via adaptation layers, typically
> running over SCTP. The typical architecture is to have a gateway
> that speaks the PSTN protocol on one side and the SIGTRAN-hosted
> protocol on the other, though one can of course have an endpoint
> which just speaks the SIGTRAN hosted-protocols.
> 
> SECURITY ISSUES
> In my view, the high level security choice that needs to be made is
> what kind of system SIGTRAN is to be. We know what kind of system the
> PSTN is: peers are physically wired to other peers so each entity
> basically trusts any other entity on the network. When we move to
> the Internet, there are two basic approaches:
> 
> (1) Emulate a private network. Just nail up IPsec/TLS links between
> the peers to replace the physical links that used to exist. I'm
> basically assuming that we'd just keep all the same security stuff (if
> any) that the PSTN uses, since we're just replacing wires with VPN
> links. The right model here is to think of VPN links as "virtual
> wires", as Steve Bellovin says. This is by far the simplest security
> approach since it doesn't require designing an entirely new security
> model, just replacing one component.
> 
> This appears to be the approachthat the protocol designers have in
> mind. If this is what's done, then things are relatively simple, but
> the documents need to specify how it's done. Two major choices need to
> be made:
> 
>    (a) What kind of keying to use.
>        Since the links are essentially statically configured,
>        preconfigured keys make the most sense. For IPsec, this
>        probably means authenticating your DH exchange with a shared
>        secret. For TLS it means statically configured self-signed
>        certificates. (This approach could be used for IPsec as well.)
> 
>    (b) IPsec vs. TLS.
>        Since SIGTRAN is always going to run over SCTP, TLS seems like
>        the better choice here, but it's really just a matter of
>        convenience which one is chosen.
> 
> In any case, the documents should specify both these choices as
> well as mandatory to implement algorithms.
> 
> 
> (2) Assume that it's a basically open system, in which case
> we have to solve all sorts of difficult and serious security
> problems of the kind that SIP is trying to confront now. In
> particular:
> 
> 	(a) Authentication. In an open system you're pretty much
> 	    going to need some sort of PKI to identify endpoints.
> 	(b) Authorization. Once we know who a peer is, how do we
> 	    know whether he's entitled to handle a given class
> 	    of traffic or not?
> 	(c) Transitive protection. Once we have the authorization
> 	    problem dealt with on a hop-by-hop basis, we have
> 	    to ask whether you trust your neighbor to correctly
> 	    verify that the peer he's talking to is entitled to
> 	    handle a given class of traffic. Probably not, so
> 	    now you need some kind of message security system
> 	    to allow nodes to authenticate nodes that they're not
> 	    directly connected to.
> 
> Judging from our experience with SIP, I'm naturally kind of wary
> of strategy (2) but I fear that it's inevitable. If that's the
> way that we're going it's going to need some heavy thinking. This
> kind of secure multihop packet switching network is a security
> problem that hasn't seen that much attention and doesn't really
> have a standard solution.
> --------------------------------------------------------------------
> 
> -Ekr
> 
> 

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran