Subject: RE: [Sip] RE: Question to Identity draft

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 19 Apr 2005 14:55:46 -0400

I do agree that sip-identity provides body integrity, and as such, that it could be used to provide integrity protection for a self-signed certificate in the body of a SIP message, and furthermore, that such a self-signed certificate could be used in subsequently messages to provide confidentiality services for SIP message bodies in order to encrypt symmetric keys used for SRTP.

I have reservations when we start describing the use of that self-signed certificate to provide integrity services for subsequent requests, thereby obviating the need to use an authentication services. I furthermore think that sipping-certs provides a better way to discover certificates for confidentiality than this method of tunneling certificates in SIP requests. 

That much said, I would not rule out tunneling self-signed certificates in this fashion, no.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Fries Steffen [mailto:[email-masked]]
> Sent: Thursday, April 14, 2005 7:48 AM
> To: Peterson, Jon; [email-masked]
> Cc: IETF SIP List
> Subject: RE: [Sip] RE: Question to Identity draft
> 
> 
> Hi Jon,
> 
> I'm still not sure what the answer to the scenarios is. 
> 
> Do you see the option with the identity draft to assert a FROM field of a
> SIP message and also an embedded certificate in the body and thus have a
> security context for that dialog. The  security context may be used on
> subsequent messages (e.g., to negotiate media encryption), which do not need
> to be sent via the authentication service?
> 
> Regards
> 	Steffen
>  
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Fries Steffen
> > Sent: Thursday, April 07, 2005 4:56 PM
> > To: Peterson, Jon; [email-masked]
> > Cc: IETF SIP List
> > Subject: [Sip] RE: Question to Identity draft
> > Importance: High
> > 
> > Hi Jon,
> > 
> > > > [stf] yes, RFC3261 talks about certificate exchhange. But
> > > here it is
> > > > only possible to take certificates, which are (more or
> > > less) bound to a person.
> > > > Assume that you use certificates, which are bound to the
> > > host used for
> > > > phone calls. Then you would need some instance assuring, 
> > that this 
> > > > certificate is connected with the registration under some AOR.
> > > > 
> > > > What I had in mind is an inband certificate exchange from,
> > > e.g., self
> > > > signed certificates, were the authentication services basically 
> > > > assures that the message (and thus the certificate) came
> > > from a person
> > > > registered under a certain AOR.
> > > 
> > > RFC3261 does in fact describe the self-signed certificate case.
> > [stf] Okay, I put it in a wrong way, I meant the certificate 
> > must follow some dedicated syntax, connected with the domain 
> > you are registering in.
> > When you have something like device certificates, which are 
> > issued by a corporate CA on the base of machine names, these 
> > certificates may be used in SIP scenarios. After successful 
> > registering, the Proxy knows, that a user, who authenticated 
> > himself using digest authentication over a TLS link that he 
> > uses the dedicated device certificate for the duration of his 
> > registration for security purposes. That means next time he 
> > registers, his identity may be connected with a different 
> > certificate, as he may use a different phone. Sure, the user 
> > could publish the certificate to a cert server, as described 
> > in the certs draft, but I was thinking of some kind of 
> > "inband provisioning" for such a scenario. 
> > 
> > > 
> > > > The certificate itself may then be used for end-to-end 
> integrity 
> > > > services.
> > > 
> > > In what respect would using this certificates for an end-to-end 
> > > integrity service be superior to just using
> > > sip-identity-04 for integrity? Note that that strength of a 
> > > self-signed credential is necessarily equivalent to the 
> strength of 
> > > the security mechanism used to deliver that self-signed 
> > credential to 
> > > potential users. So, if
> > > sip-identity-04 is used to secure the cert, it isn't 
> clear how the 
> > > cert provides a stronger or more attractive assurance than 
> > > sip-identity-04 itself would provide.
> > [stf]Using the certificate would require to send just one 
> > message over the authentication service and use the supplied 
> > certificate for the rest of the communication.
> > 
> > 
> > > > A usage example would be the key management for SRTP using
> > > MIKEY, were
> > > > one option is the usage of certificates. When here a 
> > certificate is 
> > > > used, which is completely unknown to the receiver, then 
> > there is no 
> > > > real value. But when a trusted component (the
> > > authentication service)
> > > > assures, that a person registered with a dedicated AOR is 
> > connected 
> > > > with this certificate, then it gets a meaning. It would 
> basically 
> > > > provide the assurance, that for the time I am in the call,
> > > I am using
> > > > this certificate, which may be sufficient.
> > > 
> > > No question that using sip-identity-04 would guarantee the 
> > integrity 
> > > of the certificate contained in a SIP message body.
> > > But why not have sip-identity-04 secure the SDP body 
> containing the 
> > > keymgmt attribute for MIKEY, rather than going through a 
> > certificate 
> > > exchange phase in order to subsequently use the a cert 
> > (whose strength 
> > > is equivalent to
> > > sip-identity-04) to secure the SDP body containing the 
> keymgmt? In 
> > > what respect is this not a redundant step?
> > [stf] as stated above, the authentication server would only 
> > be needed for one message, to support the establishment of a 
> > session security context. The other thing is that for the key 
> > management for SRTP the client itself needs to include the 
> > appropriate message body for MIKEY, as the MIKEY container is 
> > protected. The same would be true in scenarios were S/MIME 
> > would be required to protect sdescriptions.
> > 
> > 
> > Regards
> > 	Steffen
> > 
> > > 
> > > Jon Peterson
> > > NeuStar, Inc.
> > > 
> > > > Regards
> > > > 	Steffen
> > > > 
> > > > 
> > > 
> > 
> > _______________________________________________
> > 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: Cullen Jennings <[email-masked]>
Date: Tue, 19 Apr 2005 13:30:28 -0700

Agreeing with Jon here and want to point out a critical thing about the
certificates. For the AOR [email-masked], the certificate in a body would
most likely be for the user [email-masked] while the certificate used for
identity is for the domain example.com. You can't use a certificate for a
user, like [email-masked] to assert identity using the identity draft
mechanism. 

Cullen

On 4/19/05 11:55 AM, "Peterson, Jon" <[email-masked]> wrote:

> 
> I do agree that sip-identity provides body integrity, and as such, that it
> could be used to provide integrity protection for a self-signed certificate in
> the body of a SIP message, and furthermore, that such a self-signed
> certificate could be used in subsequently messages to provide confidentiality
> services for SIP message bodies in order to encrypt symmetric keys used for
> SRTP.
> 
> I have reservations when we start describing the use of that self-signed
> certificate to provide integrity services for subsequent requests, thereby
> obviating the need to use an authentication services. I furthermore think that
> sipping-certs provides a better way to discover certificates for
> confidentiality than this method of tunneling certificates in SIP requests.
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Apr 2005 11:53:02 -0700

On Tue, 2005-04-19 at 13:30, Cullen Jennings wrote:
>  You can't use a certificate for a

That strikes me as a bug rather than a feature. What if I
have outsourced functions where I only want to delegate
a certain subset of sip URI's to them? Oh say, like 
[email-masked] that's really some other company?
That is, I want them to be able to assert [email-masked],
but nothing else. Or suppose that [email-masked] is the
CEO and she wants to be able to call from her device on the
road when she's not behind the example.com corporate 
proxies? Why can't she just sign the identity herself...
she's the CEO, right?

		Mike

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Apr 2005 14:45:57 -0700

With email, you need to be able to do offline things and this may be needed
but with SIP it is only online and it's not clear this extra level of
indirection is needed. You can't phone the CEO without going to the proxy,
likewise the CEO can't phone you without going to the same proxy that
provides the Auth service.