[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE:[iesg-secretary #6592] Evaluation: draft-ietf-sigtran-security - Security Considerat ions for SIGTRAN Protocols to Proposed Standard
Inline
> -----Original Message-----
> From: Steven M. Bellovin [mailto:smb@research.att.com]
> Sent: donderdag 17 april 2003 17:10
> To: Wijnen, Bert (Bert)
> Cc: IESG Secretary; Internet Engineering Steering Group
> Subject: Re: Evaluation: draft-ietf-sigtran-security - Security
> Considerat ions for SIGTRAN Protocols to Proposed Standard
>
>
> 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.
>
Guess it would then be better to change:
This implies, for
example, that a root CA trusted for use with a SIGTRAN protocol must
also be trusted to protect SNMP.
Into something aka:
This implies that a
root CA trusted for use with a SIGTRAN protocol must also be trusted
to protect other protocols (for example SNMP or xxx).
My worry is that current text seems to imply (or at least can easily be
read) that SNMP is a specific issue here.
But if your explanatory text can somehow be added as well, it would
make it even more understandable for less-security-geeked people like
myself :-)
Can do that with RFC-Editor note as far as I cam concerned.
Bert
>
> --Steve Bellovin, http://www.research.att.com/~smb (me)
> http://www.wilyhacker.com (2nd edition of
> "Firewalls" book)
>
>