Subject: RE: [Sipping] Important: SMIME support required for SIP-T

From: Adam Roach <[email-masked]>
Date: Fri, 28 Jun 2002 11:47:18 -0400

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> 
> During IESG review of the draft-ietf-sipping-sipt-framework, the 
> Security Area asked... to recommend end-to-end encryption of encapsulated
ISUP.  
> This seems 
> quite sensible given the sensitive nature of ISUP and the variety of 
> intermediaries that such SIP messages might visit.

I guess that "ISUP could be encrypted (perhaps with S/MIME [4]) to
alleviate this concern" is the right sentiment was overlooked?

Given the informational nature of the draft (i.e. it's not standards
track, and it's not experimental), we can't really make normative
statements (e.g. SHOULD, MUST)... so... uh... what's being asked
of us? How can we "REQUIRE end-to-end message integrity" without
upgrading the draft to standards track?

/a

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Allison Mankin <[email-masked]>
Date: Fri, 28 Jun 2002 11:58:15 -0400

Hi, Adam,

Actually, the draft was on the charter as a BCP, which
is standards track.  That is why it had IETF Last Call,
and why it can be a reference for other standards
bodies, among other points.

The Security AD request recognized the existing statements
and asked that they become more explicit and also that
stronger normative requirements be expressed.

Thanks,

Allison

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 28 Jun 2002 09:07:03 -0700

> upgrading the draft to standards track?

Well, I was hoping to solicit technical comments rather than process 
comments.....

However, I believe it is reasonable to use normative language sparingly 
in a BCP.  We will have the same issue with Guidelines for Authors of 
SIP Extensions in SIP.  This could require some normative language 
sprinkled in a few places.  (Remember also that the proposed changes to 
SIP-T FW were specifically requested by the Security ADs.)

thanks,
-rohan