Subject: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 19 Jun 2006 19:49:08 +0200

If a dog barks at a tree and no-one hears it, did the dog make a sound?

OK, leaving aside the dogs and the trees for the moment, a short question about the contents:
The draft states "The certificates discussed in this draft are generally self signed". It then talks about how the credential service can be used to obtain the credentials using an authenticated SUBSCRIBE/NOTIFY sequence.

What puzzles me: why would a UA use the credential service to obtain a previously submitted self-signed certificate, instead of simply generating a new one by itself?

Regards,

Jeroen

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Jun 2006 08:32:39 -0400

> What puzzles me: why would a UA use the credential service to obtain a previously submitted self-signed certificate, instead of simply generating a new one by itself?

Because several UAs share the same AOR and they all want to use a common 
cert?

	Paul

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Jun 2006 13:05:40 -0700

Paul Kyzivat wrote:

>> The draft states "The certificates discussed in this draft are 
>> generally self signed". It then talks about how the credential 
>> service can be used to obtain the credentials using an authenticated 
>> SUBSCRIBE/NOTIFY sequence.
>>
>> What puzzles me: why would a UA use the credential service to obtain 
>> a previously submitted self-signed certificate, instead of simply 
>> generating a new one by itself?
>
>
> Because several UAs share the same AOR and they all want to use a 
> common cert?

Let us keep in mind that a certificate is nothing more than a key to 
identity
binding. There is absolutely nothing wrong with having multiple keys being
able to assert a given binding. Private keys should be thought of as 
roach motels:
they check in, but they don't check out.

          Mike

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 20 Jun 2006 23:05:18 +0200

----- Original Message ----- 
From: "Michael Thomas" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>
Cc: "Jeroen van Bemmel" <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 20, 2006 10:05 PM
Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and 
self-signed certificates

>>> The draft states "The certificates discussed in this draft are generally 
>>> self signed". It then talks about how the credential service can be used 
>>> to obtain the credentials using an authenticated SUBSCRIBE/NOTIFY 
>>> sequence.
>>>
>>> What puzzles me: why would a UA use the credential service to obtain a 
>>> previously submitted self-signed certificate, instead of simply 
> able to assert a given binding. Private keys should be thought of as roach 
> motels:

My thinking was that for some use cases (perhaps not all, e.g. not for the 
example in section 9.1) a user could obtain a list of certificates (or 
perhaps only their fingerprints) from the credential service. The UAC would 
then setup a TLS connection, and verify that the certificate presented by 
the other side is in the list.

In this way, perhaps one could avoid sending private credentials across the 
network altogether.

Small question on the Security considerations: it says 200 responses are 
omitted because "they do not have much to do with the overall security" - 
what about mutual authentication, using Authentication-Info? Should mutual 
authentication be RECOMMENDED, or would that be overkill (given that the TLS 
server cert is also verified)?

Regards,

jeroen

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Jun 2006 14:41:25 -0700

Jeroen van Bemmel wrote:

>
> ----- Original Message ----- From: "Michael Thomas" <[email-masked]>
> Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys 
> and self-signed certificates
>
>
>> Paul Kyzivat wrote:
>>
>>>
>>>
>>> Jeroen van Bemmel wrote:
>>>
>>>> service can be used to obtain the credentials using an 
>>>> authenticated SUBSCRIBE/NOTIFY sequence.
>>>>
>>>> What puzzles me: why would a UA use the credential service to 
>>>> obtain a previously submitted self-signed certificate, instead of 
>>>> simply generating a new one by itself?
>>>
>>>
>>>
> My thinking was that for some use cases (perhaps not all, e.g. not for 
> the example in section 9.1) a user could obtain a list of certificates 
> (or perhaps only their fingerprints) from the credential service. The 
> UAC would then setup a TLS connection, and verify that the certificate 
> presented by the other side is in the list.

This is a different beast than moving private keys around. Transporting 
*public*
keys is perfectly OK.

> In this way, perhaps one could avoid sending private credentials 
> across the network altogether.

Yes, sending private keys is a no-no.

       Mike

> Small question on the Security considerations: it says 200 responses 
> are omitted because "they do not have much to do with the overall 
> security" - what about mutual authentication, using 
> Authentication-Info? Should mutual authentication be RECOMMENDED, or 
> would that be overkill (given that the TLS server cert is also verified)?
>
> Regards,
>
> jeroen
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Jun 2006 09:51:27 -0700

Some (not all deployments) will have multiple devices registered to  
one AOR. The original draft had each device have it's own asymmetric  
key pair and if someone wanted to encrypt a message for the AOR, the  
message was encrypted with a symmetric key then the symmetric key was  
included in the message and encrypted with asymmetric keys for  
*every* device on that AOR. The WG decided this was not feasible and  
it would be better to have the devices share the asymmetric key so  
there was only one to deal with.

The draft in no way mandates that a deployment move around private  
keys over the network - deployments and users are allowed to do it  
any way they want including:

1) just say no and do one device
2) just say no and use some other way (like a crypto smart card) to  
move the private key around
3) use some other sacred framework to move the private key around
4) use the certs approach to store the private key on a server but  
the private key would be encrypted such that the severer could never  
decrypt it and only the clients would have the passphrase to decrypt
5) user the certs approach where the server knows the private key
6) user the certs approach where the server generates the private key  
(and knows it) so clients don't

These are listed in what is probably close to order of what is most  
secure (i.e. 1 is most secure, 6 least) although the later ones may  
be more convenient.

Cullen

On Jun 20, 2006, at 2:05 PM, Jeroen van Bemmel wrote:

> Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private  
> keys and self-signed certificates
>
>
>> Paul Kyzivat wrote:
>>
>>>
>>>
>>> Jeroen van Bemmel wrote:
>>>
>>>> obtain a previously submitted self-signed certificate, instead  
>>>> of simply generating a new one by itself?
>>>
>>>
>> Let us keep in mind that a certificate is nothing more than a key  
>> to identity
>> able to assert a given binding. Private keys should be thought of  
>> as roach motels:
> My thinking was that for some use cases (perhaps not all, e.g. not  
> for the example in section 9.1) a user could obtain a list of  
> certificates (or perhaps only their fingerprints) from the  
> credential service. The UAC would then setup a TLS connection, and  
> verify that the certificate presented by the other side is in the  
> list.
>
> Small question on the Security considerations: it says 200  
> responses are omitted because "they do not have much to do with the  
> overall security" - what about mutual authentication, using  
> Authentication-Info? Should mutual authentication be RECOMMENDED,  
> or would that be overkill (given that the TLS server cert is also  
> verified)?
>
> Regards,
>
> jeroen
>
>
>
>
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 26 Jun 2006 22:00:01 +0200

Cullen,

>
> Some (not all deployments) will have multiple devices registered to  one 
> AOR. The original draft had each device have it's own asymmetric  key pair 
> and if someone wanted to encrypt a message for the AOR, the  message was 
> encrypted with a symmetric key then the symmetric key was  included in the 
> message and encrypted with asymmetric keys for  *every* device on that 
> AOR. The WG decided this was not feasible and  it would be better to have 
> the devices share the asymmetric key so  there was only one to deal with.
>

I agree that this would not be feasible. I was thinking that for a 
multi-device scenario where encryption (and not TLS) is required, the 
"caller" could discover GRUUs for all currently registered devices (eg using 
presence), select one (perhaps guided in some way by preferences of the 
callee, say q-value ordering), and then encrypt specifically for that device

Slightly less flexible than having one cert per user, but better than 
encrypting a symmetric key for each potential device as you sketch above

> The draft in no way mandates that a deployment move around private  keys 
> over the network - deployments and users are allowed to do it  any way 
> they want including:
>
> 2) just say no and use some other way (like a crypto smart card) to  move 
> the private key around
> 4) use the certs approach to store the private key on a server but  the 
> private key would be encrypted such that the severer could never  decrypt 
> it and only the clients would have the passphrase to decrypt
> secure (i.e. 1 is most secure, 6 least) although the later ones may  be 
> more convenient.
>

To me, some text like the above would be good to put in the draft

Regards,

Jeroen

>> In this way, perhaps one could avoid sending private credentials  across 
>> the network altogether.
>>
>> omitted because "they do not have much to do with the  overall 
>> security" - what about mutual authentication, using  Authentication-Info? 
>> Should mutual authentication be RECOMMENDED,  or would that be overkill 
>> (given that the TLS server cert is also  verified)?
>>
>> Regards,
>>
>> jeroen
>>
>>
>>
>>
>>

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 27 Jun 2006 14:48:26 -0700

Hi Jeroen,

Paul K got the right answer here but didn't explain why they want a common cert:
>Because several UAs share the same AOR and they
>all want to use a common cert?

The reason they want a common cert is so a peer can encrypt messages
for their AOR that can be read ANY of the those several UA instances.

thanks,
-rohan

On 6/19/06, Jeroen van Bemmel <[email-masked]> wrote:
> self signed". It then talks about how the credential service can be used to
> obtain the credentials using an authenticated SUBSCRIBE/NOTIFY sequence.
>
> previously submitted self-signed certificate, instead of simply generating a
> new one by itself?
>
> Regards,
>
> Jeroen
>
>
> Sip mailing list
> https://www1.ietf.org/mailman/listinfo/sip

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 30 Jun 2006 06:19:30 -0700

On Jun 26, 2006, at 1:00 PM, Jeroen van Bemmel wrote:

> Cullen,
>
>
>>
>> Some (not all deployments) will have multiple devices registered  
>> to  one AOR. The original draft had each device have it's own  
>> asymmetric  key pair and if someone wanted to encrypt a message  
>> for the AOR, the  message was encrypted with a symmetric key then  
>> the symmetric key was  included in the message and encrypted with  
>> asymmetric keys for  *every* device on that AOR. The WG decided  
>> this was not feasible and  it would be better to have the devices  
>> share the asymmetric key so  there was only one to deal with.
>>
>
> multi-device scenario where encryption (and not TLS) is required,  
> the "caller" could discover GRUUs for all currently registered  
> devices (eg using presence), select one (perhaps guided in some way  
> by preferences of the callee, say q-value ordering), and then  
> encrypt specifically for that device
>
> Slightly less flexible than having one cert per user, but better  
> than encrypting a symmetric key for each potential device as you  
> sketch above

There had been some discussions of that, and I imagine this would  
work with the current draft as well. I think one of the problems with  
this is it involves revealing all my devices and if they are on line  
or not but I agree it sounds like another possible way to use this.

On the using a GRUU in a cert, would need to consider that any time  
my GRUU changes I need to generate a new cert - if this meant a new  
private/public key pair, this might be expensive.