Subject: [Sigtran] FW: draft-ietf-sigtran-security-02 IESG feedback

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 23 Apr 2003 13:26:26 -0700

Hi Folks,

We have had some feedback on the security draft from
the IESG, and I am attaching the comments FYI.  Michael
will be making changes accordingly to the draft and
submitting an updated version.  I believe the comments
are all basically for clarity and do not require any
basic change to the security framework.

Cheers,

L. Ong

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Wednesday, April 23, 2003 12:26 PM
To: 'Michael Tüxen'; [email-masked]';
[email-masked]
Cc: Ong, Lyndon
Subject: draft-ietf-sigtran-security-02 IESG feedback

Hello sigtran-security authors,

There was some substantial feedback from the IESG on this document. We're
going to need a revision from you that answers the points that I've
cut-and-pasted below. Many of these issues are just editorial (several
people commented that 'IPSEC' should be 'IPsec'), but some are more
substantial (like the TLS upgrading issue and the certificate root text).

Anyway, if you have any further questions about these issues, please direct
them to me.

- J

---

Section 3., "Security in Telephone Networks" seems to report things
like "the trusted network principle" without any comment on how
valid these principles are.  Purely as a personal note, I would find
some more cynicism here comforting.  This does not, of course,
change the specification in any substantive way.

---

   Please make these changes throughout the document:
     - change "man in the middle" to "man-in-the-middle"
     - change "certificate authority" to "certification authority"
     - change "IPSEC" to "IPsec"
     - change "root CA" to "trust anchor"

   Section 5, 3rd paragraph says: "These nodes MUST support IKE ..."  Are 
these nodes the ones that implement ESP, or just the ones that implement 
ESP in tunnel mode.  It needs to be clear which implementations MUST 
support IKE.

   Section 5, 5th paragraph says: "IKE negotiators SHOULD use pertinent 
certificate revocation checks before accepting a PKI certificate for use in 
IKE's authentication procedures."  What are these checks?  At a minimum 
include a normative reference to RFC 3280.  If on-line checking is 
anticipated, then a reference to RFC 2560 may be in order.

   Section 5, 7th paragraph seems to use the terms security association 
(SA), session, and connection interchangeably.  I think that security 
association is the proper term.

---

Section 6. on TLS usage notes that SIGTRAN  protocols use the same
port number and payload protocol identifier when run over TLS, and
that a session upgrade procedure has to be used to initiate the TLS-based
communication.  There are, however, no pointers to a specification for
this (even an example).  I think _something_ is required here, because
the consequences of doing an upgrade here may not be obvious.
RFC 3436 notes in section 6.2, for example:

    TLS requires that the underlying transport delivers TLS records in
    strict sequence.  Thus, the 'unordered delivery' feature of SCTP MUST
    NOT be used on streams which are used for TLS based user data
    transmission.  For the same reason, TLS records delivered to SCTP for
    transmission MUST NOT have limited lifetimes.

If you UPGRADE, in other words, there are consequences to how you use
SCTP that you may need to take into account.  If these don't apply to
SIGTRAN, great, but a worked example or additional text on the
UPGRADE scenario would really help.

---

Section 8 speaks of certificate authorities.  Since SIGTRAN connections 
are by prearrangement among parties with a pre-existing business 
arrangement, there's no need for a CA.  One party can issue a 
certificate to the other, or each can use self-signed certificates.  
Regardless of where the certificate comes from (including a 
conventional CA), knowledge of the expected certificate chain is a 
necessary part of the security provisioning.

---

[Section 8]:

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.
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran