Re: baseline CPIM security

** You see a big puff of smoke and the long-absent co-chair steps
   out of the mist, waving the smoke out of his face and coughing
   for fresh air....

"Mark Day" <[email protected]> writes:

> > While no specific understanding of CPIM's requirements was ever formalized
> > in our charter, to date I have worked under the assumption that the
> > requirements of RFC2779 apply to CPIM - in the sense that two
> > CPIM-compliant
> > protocols communicating with one another through a CPIM gateway must meet
> > the requirements of RFC2779. This would seem to entail that end-to-end
> > encrypted notifications and so forth should be able to pass a CPIM gateway
> > without violating the requirements of RFC2779 (like 5.2.1).
> 
> I believe this is a correct interpretation of the relationship between CPIM
> and 2779.

I also agree with this interpretation of the relationshib between
2778/2779 and CPIM.  The goal of CPIM is to define the core
definitions for CPIM-compliant protocols to communicate.  Because 2779
specifically requires end-to-end security, that implies that encrypted
messages must be transferable between CPIM-compliant protocols.  In
other words, a message encrypted with a SIP client must be readable,
parsible, and understandable when decrypted by an APEX client.

[snip]

> Concretely, and as a non-expert on security, I'll observe that the S/MIME
> part of Jon's proposal seems reasonable. However, specifying a ciphersuite
> that is still in the discussion phase seems like a complete non-starter. For
> better or worse, any security baseline would have to be something that can
> be completely specified and implemented right now.

I would point out that AES is implementable today..  All the
specifications on AES are close enough to "standard" that specifying
AES is probably "the way to go".  The security ADs would certainly
approve of using AES.  The only reasonable alternative is 3DES.

However, this begs the question of whether S/MIME per se is the
appropriate method to use.  In the case of IM, I have to ask whether
we want the ability to leverage a single public-key operation across
multiple messages?  This might be an interesting "compromise" for some
of the lower-powered (read: handset) devices.  Another option would be
a Kerberos-like security solution, which is certainly much lighter on
the CPU requirement.

> --Mark

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email protected]             www.ihtfp.com



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