Subject: [Sipping] Half baked idea for a PKI scheme for SIP/SIMPLE

From: "Cullen Jennings" <[email-masked]>
Date: Sat, 7 Dec 2002 13:30:31 -0800

I have been thinking about how to make the end to end security stuff in SIP
usable.

THE REQUIREMENTS

* allow UAs to use self signed certificates of their own making.

* minimize the risk any leap of faith step such as the first time you
connect in ssh

* Address the age old issue of some reasonable way to look up others users
certificates

First, consider the existing trust relationships. An end users called fluffy
selects iptel.org to be his AOR. Fluffy does this by setting up an the
account [email-masked]. By doing this fluffy is implicitly trusting
iptel.org to manage his AOR in a somewhat sane and rational way and provide
certain services - such as a registrar. It does not mean that fluffy wants
iptel.org to read all his IM but it does mean fluffy trusts iptel.org to do
some things like deliver the call to the correct contact.  Iptel.org has a
certificate signed by Verisign. iptel.org and fluffy's devices have a ways
establishing a security channel and authenticating each other - most likely
digest inside TLS.

THE SEMANTICS

Fluffy generates a self signed certificate and delivers the public portion
of this to iptel.org. iptel believes this really is from fluffy because it
already has an independent way to verify that this is from the person who
can register for the AOR [email-masked]. Now some third party, Alice,
wants to send me a secure message. Alice asks iptel.org for the certificate
for [email-masked]. iptel sends this to Alice and signs it as iptel.org.
Alice can check the iptel.org certificate because it was signed by Verisign.

The big risk in this is that iptel decides to generate a new private key and
certificate that pretends to be [email-masked] and they hand this to
Alice. Alice sends a message to [email-masked]. They decrypt it because
then have the new fake private key. If Alice did not encrypt then sign the
message, the evil people at iptel can even redo the encryption of the
message to fluffy with the correct private key and send it on so that fluffy
is not aware things have gone wrong. Fluffy can occasionally ask iptel.org
for his own certificate through some random intermediary and see if
iptel.org is providing the correct thing. If Alice is ever told that
fluffy's certificate has changed, she must proceed with caution - it might
be a valid certificate revocation, it might be something more sinister. The
best mitigation of the risk of iptel lying about fluffy's certificate is for
fluffy to have a contractual relationship with iptel.org and sue them if
they do lie. Remember the key point, fluffy selected iptel.org to provide
this service for him and has a prearranged trust relationship with them.

SOME DETAILS

iptel.org could run a special UA that I will call the certUA - it is
probably collocated with the registrar. This UA uses caller preferences to
only accept OPTION messages and only ones with
type="application/pkcs7-mime". Alice would request a certificate by sending
an options message with preferences for this type to [email-masked]. This
message would get sent to the certUA which would look up the certificate for
fluffy and put this in a mime body of type application/pkcs7-mime with a
file extensions of .p7c. This body would be put in a multipart/signed
multipart mime message signed with the iptel.org certificate.

I don't know how fluffy would publish his certificate to iptel.org. Perhaps
this is done with web pages when fluffy sets up the account - I don't really
like this option. Perhaps a SIP message is used to upload it along with the
CPL scripts. Perhaps it is managed along with other buddy list information.
I think the method a user to publish a certificate should be standardized
and a MUST implement for the registrar if we want to avoid the deployment
issues of S/MIME for email. Ideas?

THE COOL BITS

It this was a implemented in SIMPLE registrars, it would provide a way to
publish and find certificates by leveraging an IM system. If your AOR for IM
was the same as an email AOR, it would provide a reasonable way to look up
certificates for email too. It could provide automatic end to end security
for email, IM, and voice and video calls. It takes no extra effort on end
users part, it does have one party in the path that can compromised the
whole system but trust with the person can be provided by other means such
as reputation or legal remedies.

Cullen

_______________________________________________
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: Jari Arkko <[email-masked]>
Date: Sun, 08 Dec 2002 12:49:52 +0200

Looks like you are running cert registration and directory services
within SIP. Sounds good in the sense that the number of needed
protocols is small. (There'd be also other possible protocols to
use for this purpose.)

I was wondering if you scheme works for the case that we multiple
providers. I guess it does, because even if Alice doesn't have a
contract with Iptel.org she will still be able to verify the Verisign
cert. This is nice too.

However, I'm wondering how this compares to the e2e leap-of-faith
scheme we have now. First of all, the fundamental security properties
depend highly on the method Fluffy uses to register at iptel.org. The
part about "@iptel.org" can be guaranteed to be right, but the "fluffy"
part is prone to spoofing and other attacks unless there's some strong
authentication (such as looking at the customer's passport) at the
registration procedure. For instance, if the operator just lets in anyone
in using a leap-of-faith, then obviously we have a possibility for mitms
during the registration. Of course, that leap-of-faith is just done once,
whereas if Fluffy did leap-of-faith with everyone he calls, there'd be
multiple possibilities for attacks.

Also, does Alice get the cert from Iptel.org for every call? Or does
she get it once, and then store it in a leap-of-faith manner? If former,
then I would actually prefer the original e2e leap-of-faith scheme
since it didn't offer a continuous mitm possibility for the operator.

The good things with your proposal are that it lets the operators to
assist users in getting the certs for the other party. The bad things
are that the quality of the delivered certs is highly dependent on the
registration prolicies of the peer's operator, of which you may have never
heard of. Also, there's more protocol machinery and we could perhaps argue
that current LoF works extremely well where it really matters i.e. with
your long-term peers and is less susceptile for goverment mitms.

Jari

---

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 20 Dec 2002 13:35:45 -0800

I completely agree with your comments. 

When Alice encrypts a secret message to fluffy, this message is only
secret if fluffy has wisely managed his private key. So if fluffy
decides that iptel.org is good enough to be his CA, and Alice has never
heard of iptel.org, I'm not sure that this makes much difference to
Alice. Alice needs to trust that fluffy is making reasonable choices
about managing his certificates and which CA fluffy chooses to use. 

I imagine my original proposal of protocols would not be the best
choice. Perhaps a better choice would be the Call-Info header would Cary
a http URL with a purpose=card tag. The URL would point to a vcard that
contained the public certificate. 

Do folks think it is worth perusing some idea along these lines?

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jari Arkko
> Sent: Sunday, December 08, 2002 2:50 AM
> To: Cullen Jennings
> Cc: [email-masked]; Jon Peterson
> Subject: Re: [Sipping] Half baked idea for a PKI scheme for SIP/SIMPLE
> 
> 
> 
> Looks like you are running cert registration and directory 
> services within SIP. Sounds good in the sense that the number 
> of needed protocols is small. (There'd be also other possible 
> protocols to use for this purpose.)
> 
> I was wondering if you scheme works for the case that we 
> multiple providers. I guess it does, because even if Alice 
> doesn't have a contract with Iptel.org she will still be able 
> to verify the Verisign cert. This is nice too.
> 
> However, I'm wondering how this compares to the e2e 
> leap-of-faith scheme we have now. First of all, the 
> fundamental security properties depend highly on the method 
> Fluffy uses to register at iptel.org. The part about 
> "@iptel.org" can be guaranteed to be right, but the "fluffy" 
> part is prone to spoofing and other attacks unless there's 
> some strong authentication (such as looking at the customer's 
> passport) at the registration procedure. For instance, if the 
> operator just lets in anyone in using a leap-of-faith, then 
> obviously we have a possibility for mitms during the 
> registration. Of course, that leap-of-faith is just done 
> once, whereas if Fluffy did leap-of-faith with everyone he 
> calls, there'd be multiple possibilities for attacks.
> 
> Also, does Alice get the cert from Iptel.org for every call? 
> Or does she get it once, and then store it in a leap-of-faith 
> manner? If former, then I would actually prefer the original 
> e2e leap-of-faith scheme since it didn't offer a continuous 
> mitm possibility for the operator.
> 
> The good things with your proposal are that it lets the 
> operators to assist users in getting the certs for the other 
> party. The bad things are that the quality of the delivered 
> certs is highly dependent on the registration prolicies of 
> the peer's operator, of which you may have never heard of. 
> Also, there's more protocol machinery and we could perhaps 
> argue that current LoF works extremely well where it really 
> matters i.e. with your long-term peers and is less susceptile 
> for goverment mitms.
> 
> Jari
> 
> Cullen Jennings wrote:
> > I have been thinking about how to make the end to end 
> security stuff 
> > in SIP usable.
> > 
> > THE REQUIREMENTS
> > 
> > * Address the age old issue of some reasonable way to look 
> up others 
> > users certificates
> > 
> > First, consider the existing trust relationships. An end 
> users called 
> > fluffy selects iptel.org to be his AOR. Fluffy does this by 
> setting up 
> > an the account [email-masked]. By doing this fluffy is implicitly 
> > trusting iptel.org to manage his AOR in a somewhat sane and 
> rational 
> > way and provide certain services - such as a registrar. It does not 
> > mean that fluffy wants iptel.org to read all his IM but it 
> does mean 
> > fluffy trusts iptel.org to do some things like deliver the 
> call to the 
> > correct contact.  Iptel.org has a certificate signed by Verisign. 
> > iptel.org and fluffy's devices have a ways establishing a security 
> > channel and authenticating each other - most likely digest 
> inside TLS.
> > 
> > THE SEMANTICS
> > 
> > Fluffy generates a self signed certificate and delivers the public 
> > portion of this to iptel.org. iptel believes this really is from 
> > fluffy because it already has an independent way to verify 
> that this 
> > is from the person who can register for the AOR 
> [email-masked]. Now 
> > some third party, Alice, wants to send me a secure message. 
> Alice asks 
> > iptel.org for the certificate for [email-masked]. iptel 
> sends this 
> > to Alice and signs it as iptel.org. Alice can check the iptel.org 
> > certificate because it was signed by Verisign.
> > 
> > The big risk in this is that iptel decides to generate a 
> new private 
> > key and certificate that pretends to be [email-masked] 
> and they hand 
> > this to Alice. Alice sends a message to [email-masked]. 
> They decrypt 
> > it because then have the new fake private key. If Alice did not 
> > encrypt then sign the message, the evil people at iptel can 
> even redo 
> > the encryption of the message to fluffy with the correct 
> private key 
> > and send it on so that fluffy is not aware things have gone wrong. 
> > Fluffy can occasionally ask iptel.org for his own 
> certificate through 
> > some random intermediary and see if iptel.org is providing 
> the correct 
> > thing. If Alice is ever told that fluffy's certificate has changed, 
> > she must proceed with caution - it might be a valid certificate 
> > revocation, it might be something more sinister. The best 
> mitigation 
> > of the risk of iptel lying about fluffy's certificate is 
> for fluffy to 
> > have a contractual relationship with iptel.org and sue them 
> if they do 
> > lie. Remember the key point, fluffy selected iptel.org to 
> provide this 
> > service for him and has a prearranged trust relationship with them.
> > 
> > SOME DETAILS
> > 
> > probably collocated with the registrar. This UA uses caller 
> > preferences to only accept OPTION messages and only ones with 
> > type="application/pkcs7-mime". Alice would request a certificate by 
> > sending an options message with preferences for this type to 
> > [email-masked]. This message would get sent to the certUA which 
> > would look up the certificate for fluffy and put this in a 
> mime body 
> > of type application/pkcs7-mime with a file extensions of .p7c. This 
> > body would be put in a multipart/signed multipart mime 
> message signed 
> > with the iptel.org certificate.
> > 
> > I don't know how fluffy would publish his certificate to iptel.org. 
> > Perhaps this is done with web pages when fluffy sets up the 
> account - 
> > I don't really like this option. Perhaps a SIP message is used to 
> > upload it along with the CPL scripts. Perhaps it is managed 
> along with 
> > other buddy list information. I think the method a user to 
> publish a 
> > certificate should be standardized and a MUST implement for the 
> > registrar if we want to avoid the deployment issues of S/MIME for 
> > email. Ideas?
> > 
> > THE COOL BITS
> > 
> > It this was a implemented in SIMPLE registrars, it would 
> provide a way 
> > to publish and find certificates by leveraging an IM 
> system. If your 
> > AOR for IM was the same as an email AOR, it would provide a 
> reasonable 
> > way to look up certificates for email too. It could provide 
> automatic 
> > end to end security for email, IM, and voice and video 
> calls. It takes 
> > no extra effort on end users part, it does have one party 
> in the path 
> > that can compromised the whole system but trust with the 
> person can be 
> > provided by other means such as reputation or legal remedies.
> > 
> > Cullen
> > 
> > 
> > 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
> > 
> > 
> 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>