RE: baseline CPIM security

The requirements of RFC2779 entail an end-to-end security model - this
suggests that either transport or network layer security would not meet the
base requirements. As one such instance, look at requirement 5.2.1 in
RFC2779. While IPSec can provide confidentiality and integrity properties,
it does not do so, for example, for instant messages that traverse a CPIM
gateway (without revealing the content of these messages to the gateway).
The framework of RFC2778 does not describe any "trust" model of the sort you
suggest below - in fact, I think they describe something quite to the
contrary. I think it is appropriate for the IETF to define a protocol that
allows an instant messaging client to send messages through a service but
does not allow the service to inspect the content of those messages.

I understand your concerns about the overhead associated with S/MIME,
especially for mobile devices. Of the tools available to us, however, I
believe it is the best. Hopefully the requirement for the AES ciphersuite
(as opposed to 3DES) will reduce the processing power necessary to implement
S/MIME.

Also note that in some networks, the instant messaging user agent and/or
presentity role could be distributed over multiple entities - in other
words, a mobile phone might not be a full presentity as such, so the burden
of implementing S/MIME might fall on some other device.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Beckmann Mark ICM MP P PS 4 SAL 2
> [mailto:[email protected]]
> Sent: Tuesday, October 01, 2002 6:41 AM
> To: 'Peterson, Jon'; '[email protected]'
> Subject: RE: baseline CPIM security
> 
> 
> I don't like the idea of mandating the implementation of S/MIME. Please
keep
> in mind that this would have to be implemented in all kind of devices,
> including mobile phones, which may be limited with regards to computing
> power and available memory.
> 
> Also, some network configurations may rely on different mechanisms like
> IPSec to ensure confidentiality of the presence information over the
> interfaces and consider intermediate proxies and the presence server as
> "trusted entities". In this case S/MIME would not be necessary.
> 
> Regards,
> 
> Mark
> 
> Mark Beckmann			Siemens AG
> 
> ICM MP P PS 4S2
> P.O.Box 100702			phone: +49 (5341) 906 1814
> D-38228 Salzgitter   		fax:   +49 (5341) 906 2010
> 
> mailto: [email protected]
> 
> 
> 
> > -----Original Message-----
> > From: Peterson, Jon [mailto:[email protected]]
> > Sent: Tuesday, September 24, 2002 9:10 AM
> > To: '[email protected]'
> > Subject: baseline CPIM security
> > 
> > 
> > 
> > I believe that without a mandatory-to-implement baseline 
> > security mechanism,
> > including a ciphersuite, the prospects of CPIM passing the 
> > IESG are slim.
> > Moreover, if different presence protocols/applications do not 
> > use common
> > security mechanisms to apply to security properties to MSGFMT 
> > and PIDF, the
> > prospects for interoperability through CPIM gateways are 
> > equally slim. It is
> > also desirable, I think, to use the same mechanism to secure 
> > MSGFMT and
> > PIDF, in order to minimize the number of security mechanisms that
> > CPIM-compliant applications and protocols must support.
> > 
> > Since both PIDF and MSGFMT are MIME-based, I'd like to 
> > suggest that S/MIME
> > should be the mandatory-to-implement security mechanism for 
> > CPIM-compliant
> > devices. In my experience, this option is currently preferred by the
> > Security ADs to the alternatives.
> > 
> > If we grant that S/MIME should be the 
> mandatory-to-implement security
> > mechanism, we must also select a minimum ciphersuite. Today, 
> > 3DES is most
> > commonly used for this purpose. However, an S/MIME 
> > ciphersuite for AES is
> > also underway; for example, see:
> > 
> > http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-04.txt
> > 
> > Ultimately, I think it is probably the right choice for CPIM 
> > to normatively
> > depend on AES rather than 3DES, even those the CMS AES work 
> > is mostly still
> > at the I-D stage.
> > 
> > In terms of textual changes, I'd further like to suggest that 
> > the baseline
> > CPIM specification is the appropriate place to declare the
> > mandatory-to-implement security mechanism, and that both the 
> > PIDF document
> > and the MSGFMT document should normatively reference the security
> > requirements in CPIM.
> > 
> > Comments? If not, this will be added to impp-cpim-04.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > 
> > 
> >   [reminder: [email protected] for non-technical 
> > discussions, please]
> > 
> 
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 



  [reminder: [email protected] for non-technical discussions, please]