Subject: Re: [Sip] S/MIME, Authentication and Integrity

From: "Jari Arkko" <[email-masked]>
Date: Sun, 3 Feb 2002 23:36:12 +0200

I tend to agree with Jon on this issue. After thinking about this
for a while and studying the SSH documentation, I think Bis 06
achieves roughly the same as SSH did. However, I believe Bis
06 text could still indicate that in the SIP world there are more
of these potentially bad intermediaries as there were in the SSH
case (as you indicate below). Also, I'm not sure the current text
says as clearly as the SSH text does that there are three alternative
methods for key verification -- config, CA, and leap-of-faith. The
config option I think isn't mentioned.

But I do believe James does have a point on the lack
of key exchange framework. However I do not see a security
difference in what SSH achieves and what we can achieve with
S/MIME. But functionality-wise SSH provides session key
establishment after initial authentication, which the current text
in Bis 06 does not provide, as far as I can see. But this would
still be doable, perhaps as a future extension of SIP in a separate
RFC. For instance, assuming self signed certs are the main
usage pattern, we could get away with encrypted session keys inside
the first S/MIME attachment, then resorting to the symmetric crypto
capabilities of S/MIME on further messages. This could be relevant
for e.g. busy media servers that employ S/MIME as a means to
reduce the number of public key operations.

Jari

----- Original Message ----- 
From: "Peterson, Jon" <[email-masked]>
To: "'James Undery'" <[email-masked]>; "SIP (E-mail)" <[email-masked]>
Sent: 28. tammikuuta 2002 20:21
Subject: RE: [Sip] S/MIME, Authentication and Integrity

> On removal of certificates, yes, I totally agree that's an omission. I
> thought we had some text about how to handle this (and a couple of similar
> cases, like what happens when S/MIME is unsupported by a recipient) but now
> I can't find it anywhere in the text. Hmm, been doing too much cut and paste
> lately to be sure. Well, it'll be added in the build next Monday. Removal is
> I think pretty easy to detect (easier that replacement), and it's fairly
> obvious what you should do in that case.
> 
> The relatively 'likeliness' of having obtained a reliable fingerprint is
> debatable; there are certainly some people who use SSH that make sure to
> acquire an original fingerprint from the same LAN as the host in question
> before they go on a business trip or what have you. In some SIP
> architectures this certainty won't be achievable - but then again, in some
> it will be. Clearly there are all sorts of customary SIP intermediaries,
> such as proxy servers, that potentially have carte blanche to act as MiTMs
> which are not a concern in SSH. So I don't entirely disagree with you - but,
> that much said, I think it's pretty clear why we draw the analogy. Perhaps
> the most important similarity between the two is that the oversight of a
> human is required in trust establishment.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: James Undery [mailto:[email-masked]]
> > Sent: Monday, January 28, 2002 9:03 AM
> > To: Peterson, Jon; SIP (E-mail)
> > Subject: RE: [Sip] S/MIME, Authentication and Integrity
> > 
> > 
> > comments inline.
> > 
> > > -----Original Message-----
> > > From: Peterson, Jon [mailto:[email-masked]]
> > 
> > > The attack is mentioned in 21.2, and discussed relatively 
> > > extensively in
> > > 22.4.2.
> > 
> > The replacement of a certificate is mentioned, the removal of
> > certificates isn't.
> > 
> > > The basic jist of the text is that while the use of the 
> > > S/MIME mechanism
> > > admits of the startup MiTM attack, it nevertheless improves 
> > > the security of
> > > SIP. We contend that this isn't entirely dissimilar to the 
> > > degree that SSH
> > > improves telnet security.
> > 
> > I'd agree it improves security, I'd just disagree it was anywhere near
> > the amount SSH improves telnet. The reason for this is if I 
> > telnet to a
> > machine I am much more likely to have obtained a reliable
> > fingerprint/copy of the certificate for the machine. The other reason
> > and the one that definately isn't addressed is the lack of 
> > framework for
> > the key exchange, which SSH provides.
> > 
> > James
> > 
> > > > -----Original Message-----
> > > > From: James Undery [mailto:[email-masked]]
> > 
> > > > Looking over section 21.4.1 I am having trouble seeing how 
> > > any of the
> > > > claims can be justified against a MiTM attack. Without a
> > > > challange/credentials framework S/MIME can't offer 
> > Authentication or
> > > > Integrity e.g. a MiTM just removes the S/MIME protection (and 
> > > > optionally
> > > > adds it's own).
> > 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

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