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

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 27 Jun 2006 06:21:32 +0200

And in addition: when generating self-signed certificates, have the UA 
include the GRUU in the certificate

Jeroen

> 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:
>>
>> 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.
>>
>
> To me, some text like the above would be good to put in the draft
>
> Regards,
>
> Jeroen
>
>> Cullen
>>
>>
>>
>> On Jun 20, 2006, at 2:05 PM, Jeroen van Bemmel wrote:
>>
>>>
>>> ----- 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
>>>
>>>
>>>> Paul Kyzivat wrote:
>>>>
>>>>>
>>>>>
>>>>> Jeroen van Bemmel wrote:
>>>>>
>>>>>> 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?
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Jun 2006 09:29:31 -0400

> include the GRUU in the certificate
[snip]
>> 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
>>

This would limit secure communication to cases when the callee has 
presence and enough of a relationship with the caller to provide this 
much presence information to the caller. Disclosing the existence of 
particular devices, and how to reach them is not something that most 
people would do for arbitrary callers.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 27 Jun 2006 20:49:50 +0200

Paul,

I wasn't suggesting it as a one-size-fits-all approach. No need to make it 
mandatory, but it would be nice if we could *enable* it (adding a 7th point 
to Cullen's list of possible uses)

For example (not exhaustive):
- Section 7.5: NOTIFY bodies - Suggestion to allow MIME/multipart or perhaps 
some other format to allow a list of certificates to be returned for a user
- Section 10.6 : "The subjectAltName must have a URI type that is set to the 
SIP URL corresponding to the user AOR."
   Suggestion is to allow a GRUU here too

With a GRUU in the subjectAltName it would work even without Presence. And 
if you're worried about disclosing that... well, then we could use the magic 
of TRUUs...

Regards,

Jeroen

>>> of the callee, say q-value ordering), and then encrypt specifically for 
>>> that device
>>>
> presence and enough of a relationship with the caller to provide this much 
> presence information to the caller. Disclosing the existence of particular 
> devices, and how to reach them is not something that most people would do 
> for arbitrary callers.
>
> Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Jun 2006 15:58:20 -0400

Jeroen van Bemmel wrote:
> Paul,
> 
> I wasn't suggesting it as a one-size-fits-all approach. No need to make 
> it mandatory, but it would be nice if we could *enable* it (adding a 7th 
> point to Cullen's list of possible uses)

As just another option I guess this is ok.

	Paul

> - Section 7.5: NOTIFY bodies - Suggestion to allow MIME/multipart or 
> perhaps some other format to allow a list of certificates to be returned 
> for a user
> - Section 10.6 : "The subjectAltName must have a URI type that is set to 
> the SIP URL corresponding to the user AOR."
> With a GRUU in the subjectAltName it would work even without Presence. 
> And if you're worried about disclosing that... well, then we could use 
> the magic of TRUUs...
> 
> Regards,
> 
> Jeroen
> 
> 
>>
>>
>> Jeroen van Bemmel wrote:
>>> And in addition: when generating self-signed certificates, have the 
>>> UA include the GRUU in the certificate
>> [snip]
>>>> 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
>>