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

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 1 Jul 2002 00:55:42 -0500

I don't think it requires universal S/MIME support any moreso than it might
require universal 'application/ISUP' MIME type support - the creation by
gateways of MIME bodies with optional Content-Disposition handling is
critical for interoperability with user agents that do not support the SIP-T
mechanism.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Sunday, June 30, 2002 9:57 PM
> To: 'Peterson, Jon'; [email-masked]
> Subject: RE: [Sipping] Important: SMIME support required for SIP-T
> 
> 
> Does this imply S/MIME support for endpoints that *might* have to
> interact
> with a SIP-T gateway? I'm wondering how this impacts the need 
> for S/MIME
> support in SIP UAs that don't necessarily care about SIP-T, but may be
> deployed
> in a network that will need to deal with a SIP-T gateway. How
> "end-to-end" are
> we really talking about here?
> 
> Sean
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Peterson, Jon
> Sent: Sunday, June 30, 2002 7:10 PM
> To: [email-masked]'
> Subject: RE: [Sipping] Important: SMIME support required for SIP-T
> 
> 
> 
> For the record, I support this change.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Rohan Mahy [mailto:[email-masked]]
> > Sent: Friday, June 28, 2002 7:45 AM
> > To: [email-masked]'
> > Subject: [Sipping] Important: SMIME support required for SIP-T
> > 
> > 
> > Hi,
> > 
> > During IESG review of the draft-ietf-sipping-sipt-framework, the
> > Security Area asked to require end-to-end message integrity using
> SMIME 
> > and 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.
> > 
> > Because this effectively requires all SIP-T implementors to add 
> > support
> > for SMIME, I'm asking for a one week comment period.  I'd like to
> point 
> > out that ISUP gateways are few enough that they can 
> feasibly obtain or
> 
> > be configured with the necessary certificates.  I'd also like to
> mention 
> > that any alternative proposal probably needs to have 
> demonstrably the 
> > same or better end-to-end security in its intended application in
> order 
> > to be amenable to the security ADs.
> > 
> > thanks,
> > -rohan
> > 
> > 
> > _______________________________________________
> > 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
> > 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Mon, 01 Jul 2002 13:23:31 +0300

Hi,

> critical for interoperability with user agents that do not support the SIP-T

Wouldn't every UA (assuming they support MIME in the first place, of course)
have to support at least signing (to my understanding the value of the SIP
Content-Type header would be "multipart/signed"), since there may also be an
(even if unencrypted) SDP MIME entity sent in the same SIP message as the ISUP?

...OR, ARE we allowed to keep the "multipart/mixed" header value on the SIP
level, in the Content-Type header, and then inside the specific ISUP MIME entity
define that SMIME is used for that specific MIME entity?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 02 Jul 2002 17:30:06 +0300

Hi,

Related to this.

Chapter 7.4.1 in bis-09 says:

"Implementations that send requests containing multipart message bodies MUST send a
session description
as a non-multipart message body if the remote implementation requests this through
an Accept header field that does not contain multipart."

My question is: how does this work? There would have to be TWO Content-Type headers
in the SIP message, 'Content-Type: application/sdp' for the session description and
'Content-Type:multipart/mixed' for the multipart message body. Is that allowed???

Regards,

Christer Holmberg
Ericsson Finland

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 2 Jul 2002 09:32:12 -0700

Hi,

You send the mulipart message first, the UAS complains with some 
400-class response (4xx Not Acceptable i think) with an Accept header 
listing the mime-types they support, and so you send back the same 
message with just an application/sdp body.

thx,
-r

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 2 Jul 2002 13:59:06 -0400

Christer,

The Content-Type for the application/sdp is included in the multipart body
which contains the SDP (as in the example in section 4.1 of RFC 3204).

If the multipart request was rejected by the UAS (with 415), the UAC would
then have to send a non-multipart request with ONLY the application/sdp
Content-Type and body.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Christer Holmberg" <[email-masked]>
To: "Peterson, Jon" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, July 02, 2002 10:30 AM
Subject: Re: [Sipping] Important: SMIME support required for SIP-T

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 03 Jul 2002 07:33:03 +0300

Hi,

> which contains the SDP (as in the example in section 4.1 of RFC 3204).

True. But my understanding of the text was that the session description was not
part of the multipart.

> then have to send a non-multipart request with ONLY the application/sdp

True.

I guess I missunderstood the text, because the picture I got was that the UAC
shall send BOTH the session description (outside the MIME) and a MIME, in the
same message, and that obviously doesn't work...

Thanks for your comments!

Regards,

Christer Holmberg
Ericsson Finland