Re: Evaluation: draft-ietf-sigtran-security - Security Considerat ions for SIGTRAN Protocols to Proposed Standard

["Steven M. Bellovin" <smb@research.att.com>]

In message <7D5D48D2CAA3D84C813F5B154F43B155016A308F@nl0006exch001u.nl.lucent.c
om>, "Wijnen, Bert (Bert)" writes:
>>                     Yes    No-Objection  Discuss *  Abstain  
>> Bert Wijnen         [   ]     [   ]       [ X ]      [   ]
>
>On page 9 I read (2nd para):
>   Note that IPSec is considerably less flexible than TLS when it comes
>   to configuring root CAs. Since use of Port identifiers is prohibited
>   within IKE Phase 1, within IPSec it is not possible to uniquely
>   configure trusted root CAs for each application individually; the
>>> same policy must be used for all applications. This implies, for
>>> example, that a root CA trusted for use with a SIGTRAN protocol must
>>> also be trusted to protect SNMP. These restrictions can be awkward at
>   best. 
>
>I have marked a few lines with >>
>Can someone explain to me how it "implies" or "follows that the
>SIGTRAN protocol must also be trusted to protect SNMP. I guess I cannot
>find the proper context as to how SNMP plays a role here.
>

It's not SNMP per se, it's any service.

There are no port numbers specified in an IKE Phase 1 exchange, which 
means that given a Phase 1 security association, you don't know what 
it's trusted for.  You can only grant trust based on secure 
identification of the remote party, which is a <root CA,certificate> 
pair.  Suppose I want to talk secure SIGTRAN to you over IPsec, and 
you're willing to permit this.  We then negotiate a Phase 1 SA.  I now 
use that Phase 1 to negotiate a Phase 2 SA that specifies UDP port 161. 
You don't know at this point that the Phase 1 SA was only for SIGTRAN.
Oops.


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)