Subject: [Sip] Question to Identity draft

From: Fries Steffen <[email-masked]>
Date: Tue, 5 Apr 2005 12:03:49 +0200

Hi Jon, hi Cullen,

by reading the IDs regarding enhanced identity management
(draft-ietf-sip-identity-04) and certificate management
(draft-ietf-sipping-certs-01) I've got a question to a possible use case. 

Assumed that two user A and B from two different domains X and Y want to
communicate securely. User A sends his INVITE with an attached certificate
to User B in domain Y. The INVITE is send through an authentication service,
which authenticates (according the identity draft) that the AOR matches the
FROM field. Additionally a digital signature is calculated also over the
body of the message. Thus also the attached certificate is signed. Using
this approach would assure User B that User A has registered with his
credentials in domain X. User B could then use the received certificate to
communicate securely with user A at least for the duration of the session.
User B may also send his certificate to user B also through an
authentication service. Within a next session, when both users newly
registered, the certificates may be different than in the session before.

Is this scenario somehow covered by the identity draft? It could save the
credential server in certain scenarios. The approach itself may require an
enhanced storing of the username and certificate associations if
non-repudiation is desired.

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 5 Apr 2005 17:20:17 -0400

Your question points to an important difference in applicability between sip-identity-04 and sipping-certs-01, and it is essentially a matter of what you mean by "communicate securely".

The primary differences between sip-identity-04 and sipping-certs-01 lie in what they require user agents to support and what security services they offer. sip-identity-04 offers an integrity and replay protection service, whereas sipping-certs-01 offers a full suit of MIME security services including confidentiality (the cost of course being that UAs must support S/MIME and the certificate acquisition service).

The method of exchanging certificates within SIP messages which you describe below was subtantially documented in RFC3261. There's no doubt the integrity provided by sip-identity-04 could help to secure certificates exchanged in this manner. But the question is what security properties you want to derive from this practice. If you want to use the exchanged certificates for integrity, then well, sip-identity-04 already provides integrity. If you want to use the exchanged certificates for confidentiality, then you get the bootstrapping problem - how does the sender of the INVITE learn the key they must use to encrypt the body of their request? This is the purpose of the certificate server, and of sipping-certs-01. I doubt that exchanging certificates within INVITEs and so on will prove more servicable.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Fries Steffen [mailto:[email-masked]]
> Sent: Tuesday, April 05, 2005 3:04 AM
> To: Peterson, Jon; [email-masked]
> Cc: IETF SIP List
> Subject: Question to Identity draft
> 
> 
> Hi Jon, hi Cullen,
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 5 Apr 2005 20:04:15 -0400

There is still many cases where the sipping-certs does not work
properly, which I think could be addressed by something along
the lines of sip-identity and what Steffen is talking about.
I think it would complement sipping-certs very well. 

For example, it is often not the case that sipping-certs
will be able to fetch the certificate of the 
UA that will answer the session. For example:

- The target corresponds to a group of people, say in 
  a call center, a hunt group or something along those 
  lines. In many cases, it may not be feasible, or
  even desireable that all these people share the same
  certificate. 

- Retargeting will also not work. By retargetting, I am
  including any time of forking, forwarding and so forth
  where the targets correspond to people with different
  certificates.

- The target is a "moving target". For example, it could
  be a bank of gateways, media servers, IVR systems or
  whatever.

(I guess all those cases are a form of retargeting because
the responder is not who was in the initial request).

In those cases, you can send SUBSCRIBEs as much as you want,
but you won't get a usable certificate because the INVITE 
after the SUBSCRIBE is not going to land at the same place.

If instead something along lines of sip-indentity was used
(even in conjunction with sipping-certs), I think we can get
rid of the bootstrap problem you refer to, by having a two-pass
process.

What I am pointing out is the bootstrap problem may exist
as well with sipping-certs. In fact, it can be worst in the sense
that it would get in an infinite loop of retrying because the
target keeps on moving.

Assume A always includes it's certificate when it calls B.
If A had access to B's certificate beforehand (using certs), then
no problem. It works exactly as per sipping-certs.

If A couldn't get access to B's certificate beforehand, or if
it turns out to be the wrong B, then B would receive the 
request, but the key (as per your example) would be wrong. B should
be able to provide it's certificate to A in the same session, so 
that the session could be renegotiated (if A whishes to do so).

For example, I can think of the following mechanism:

- B rejects the request with error code XXX and includes it's certificate
  in the response. B also includes a Contact.

- A examines the certificate (and Contact), and determine if it will 
  re-initiate the request or not, based on it's own local criteria 
  (is C already trusted, etc.).
 
One use case of course for this is encryption (sRTP). It would work equally
well with SDESC and with MIKEY/kmgmt. 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Peterson, Jon
> Sent: Tuesday, April 05, 2005 14:20
> To: Fries Steffen; [email-masked]
> Cc: IETF SIP List
> Subject: [Sip] RE: Question to Identity draft
> 
> 
> 
> Your question points to an important difference in 
> applicability between sip-identity-04 and sipping-certs-01, 
> and it is essentially a matter of what you mean by 
> "communicate securely".
> 
> The primary differences between sip-identity-04 and 
> sipping-certs-01 lie in what they require user agents to 
> support and what security services they offer. 
> sip-identity-04 offers an integrity and replay protection 
> service, whereas sipping-certs-01 offers a full suit of MIME 
> security services including confidentiality (the cost of 
> course being that UAs must support S/MIME and the certificate 
> acquisition service).
> 
> The method of exchanging certificates within SIP messages 
> which you describe below was subtantially documented in 
> RFC3261. There's no doubt the integrity provided by 
> sip-identity-04 could help to secure certificates exchanged 
> in this manner. But the question is what security properties 
> you want to derive from this practice. If you want to use the 
> exchanged certificates for integrity, then well, 
> sip-identity-04 already provides integrity. If you want to 
> use the exchanged certificates for confidentiality, then you 
> get the bootstrapping problem - how does the sender of the 
> INVITE learn the key they must use to encrypt the body of 
> their request? This is the purpose of the certificate server, 
> and of sipping-certs-01. I doubt that exchanging certificates 
> within INVITEs and so on will prove more servicable.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
> 
>

---

From: Fries Steffen <[email-masked]>
Date: Wed, 6 Apr 2005 10:58:57 +0200

Hi John, 

I made some inline comments.

------snipp
> within INVITEs and so on will prove more servicable.

[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. The certificate itself may then be used for end-to-end
integrity services. 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. 

Regards
	Steffen

> > Assumed that two user A and B from two different domains X 
> and Y want 
> > to communicate securely. User A sends his INVITE with an attached 
> > certificate to User B in domain Y. The INVITE is send through an 
> > authentication service, which authenticates (according the identity 
> > draft) that the AOR matches the FROM field. Additionally a digital 
> > signature is calculated also over the body of the message. 
> Thus also 
> > the attached certificate is signed. Using this approach 
> would assure 
> > User B that User A has registered with his credentials in domain X. 
> > User B could then use the received certificate to 
> communicate securely 
> > with user A at least for the duration of the session.
> > Is this scenario somehow covered by the identity draft? It 
> could save 
> > the credential server in certain scenarios. The approach itself may 
> > require an enhanced storing of the username and certificate 
> > associations if non-repudiation is desired.
> > 
> > Regards	
> > 	Steffen
> > 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 6 Apr 2005 15:39:05 -0400

I agree that the problems you describe below are all retargeting problems. The retargeting draft (peterson-sipping-retarget-00 Section 2.3) notes that this problem applies to the RFC3261 INVITE-like certificate exchange mechanism. All in all, though, I'm pretty sure that these sorts of problems are more tractable in a SUBSCRIBE-like model for certificate acquisition than they are in an INVITE-like model for certificate acquisition.

In an INVITE-like model, you are sending the content that you want to encrypt - that is, a session request - to an unanticipatable target. In a SUBSCRIBE-like model, you are merely sending a request for a certificate to an unanticipatable target. The second is at least superficially better. If you strip everything out of the INVITE that might be considered sensitive before you send your request, in the hopes of just soliciting a certificate in a response, then basically you are using the INVITE as a makeshift fetch. Using SUBSCRIBE has decided advantages over a fetch - namely, you can establish persistent relationships and get notifications when the target's certificate changes.

Speaking at a high level, there is no technical reason why a subscription to a certificate service could not be redirected/retargeted or somehow trickle down to the right service for the apparently destination of the call. The tough part, of course, is synchronizing the path traversed by the subscription with the path that would be traveled by an INVITE, so that the certificate held by the UAC will always correspond with the appropriate UAS target. I can imagine publication models, though, in which users publishing certificates to a certificate service will cause the cert to propagate, through multiple publications, to where it needs to go for the purposes of certificate acquisition. There are also possible ways this could be addressed with presence.

So, regardless of whether or not sipping-certs solves all of the conceivable problems, I think it's a more promising direction than INVITEs. Of course, if a UA for whatever reason receives a request that is undecipherable, it can reply with a 493 Undecipherable message, as decribed in RFC3261, and return its certificate in that response. So, I think the functionality that you describe at the end of your message is indeed already available in RFC3261. The issues rasied in the sipping-retargeting draft, though, illustrate why this might not be sufficient. To address those sorts of problems, I think you'll need something closer to sipping-certs.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Tuesday, April 05, 2005 5:04 PM
To: Peterson, Jon; 'Fries Steffen'; [email-masked]'
Cc: 'IETF SIP List'
Subject: RE: [Sip] RE: Question to Identity draft

> > and Y want to 
> > could save the

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 6 Apr 2005 15:51:22 -0400

> certain AOR. 

RFC3261 does in fact describe the self-signed certificate case.

> 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.

> A usage example would be the key management for SRTP

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?

Jon Peterson
NeuStar, Inc.

---

From: Fries Steffen <[email-masked]>
Date: Thu, 7 Apr 2005 16:56:18 +0200

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.
> 
[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

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 7 Apr 2005 17:28:12 -0400

Hi Jon,

Your draft peterson-sipping-retarget-00 describes very well the 
issues at hand.

I don't view the use of INVITE as a "fetch". To me the SUBSCRIBE mechanism
is the fetch mechanism, and it should definitively be used whenever it 
is possible. There is a very strong incentive to use SUBSCRIBE to fetch the
certificates of the "people you know" because it will result in session
setup
in ONE round-trip (which will not be the case when there is a failure, as
with 
unanticipated respondents).

What I am saying is that there are a lot of cases where the 
SUBSCRIBE mechanism will NOT work, but where you may still have a need for 
either/both Identity and/or Privacy (encryption). We absolutely need to 
acknowlege that this will happen (and it will happen a lot).

I've listed a few cases where SUBSCRIBE won't work. It boils down to cases 
where the responder is unpredictable which is extremly common.

Going through the specifics of the retarging-draft regarding identity:

- To me the logical choice for the connected party information would be
  to use the far-end certificate (especially if we need to do encryption
  as well). It fact, it seems to be the only choice as, as you point out,
  it is impossible to enforce a rule that prohibits proxies from 
  retargeting in a domain it is not responsible for.

- It seems to me that it would solve the unanticipated respondent problem 
  (2.2.1). The sender of the request would have many choices, depending
  of the application, on what to do before sending a request:

  - In the case of sending a request that does NOT include an encrypted 
    body, the sender needs to decide if there is any information that is
    sensitive before it sends the request. For example, if it is a SIP
    INVITE, it may decide that it will NOT send an SDP body (because it
    doesn't want to advertize the information to anybody) in the INVITE
    (which means it is doing delayed offer/answer. That particular mechanism
    has some advantage, including avoiding a re-negotiation later on (what
you
    call the fetch). There are some cases where this makes sense.

  - In most cases, I would say that you would use encryption (S/MIME) to
    send the body. This means that there is no unanticipated respondent
    problem because the unintendent respondent won't be able to decrypt
    the body in the first place. Perhaps, we should highly recommend
    this approach (as opposed to "depopulate the message" as above.

  - Again, if for specific requests, it only makes sense to reach a specific
    recipient (e.g., MESSAGE), you still have the option to rely strictly on
    SUBSCRIBE. To me the real important use case where SUBSCRIBE is not 
    enought is INVITEs (and more importantly, for sRTP).

  It is important to acknowledge in advance that there is no way for the
  sender to know in advance that there will be an unanticipated responder.
  Even if a SUBSCRIBE was successful earlier, it may still be retargeted.

- In section 2.3, you talk about using 493. Personally, I would think that
  a 3XX code (possibly a new one) would be more appropriate. In case of
  forking for example, it is more likely that the forking proxy would
redirect
  than a 4XX code which would be very likely to be dropped. You talk about a
  potential problem that the new INVITE could still be routed to a different
  users (just like SUBSCRIBE). Why not use a URI that specifically refers to
  a specific user as a Contact (perhaps a GRUU)? This essentially transforms
  a retargeting into a redirection, which solves a lot of issues (the To:
  would of course remain as per the original INVITE).

- The second to last paragraph of 2.3 says that "This whole class of failure
  would be preventable if Alice were able to guess who would eventually
receive
  her request." I would say that it is quite unrealistic to think that this
  is feasible all the time. There are countless examples where this is not
  possible, and where you would still want to know (1) who responds, and (2)
you
  may still want to do encryption.

- In section 2.4 you talk about consent of the UAC. You are right: this is
  absolutely crucial. My take is that the UAC could clear the session.
  I would say that would be appropriate for INVITEs for example (keep in
mind
  that normally, the receiver wouldn't understand the SDP if it is not 
  authorized, so no harm is done). I would agree that you probably don't
want 
  to do this for MESSAGE. We could also do some sort of precondition if
  we really have to.

- Section 5 is where I was a little puzzled... The way I read the document,
  I was convinced the conclusion would be to use a "Connected party"
approach, but
  instead it suggests that the entities doing the retargeting would have to
  do some new procedures. I think this is not enforceable. Even if it was
enforceable,
  it would be increadibly complicated when multiple retargeting occur. I'd
much rather 
  rely on the certificate of the responder, and let the sender decide how to
proceed.

This would also allow for supporting sRTP to unanticipated respondents.

Note: I will point out that MIKEY allows for this today because the
certificates
      can be included in the MIKEY message. Not so for SDESC. If we "pop up
2 levels" 
      the certificates to the SIP level (instead of inside MIKEY inside SDP
in SIP), then
      we could have a solution that would work for both mechanisms, allowing
a UAC to
      advertize support for both mechanism. You could use S/MIME with both
mechanisms.

> From: Peterson, Jon [mailto:[email-masked]] 
> Sent: Wednesday, April 06, 2005 12:39
> To: Audet, Francois [SC100:9T51:EXCH]; Fries Steffen; [email-masked]
> Cc: IETF SIP List
> I agree that the problems you describe below are all 
> retargeting problems. The retargeting draft 
> (peterson-sipping-retarget-00 Section 2.3) notes that this 
> problem applies to the RFC3261 INVITE-like certificate 
> exchange mechanism. All in all, though, I'm pretty sure that 
> these sorts of problems are more tractable in a 
> SUBSCRIBE-like model for certificate acquisition than they 
> are in an INVITE-like model for certificate acquisition.

[rest trimmed]

---

From: Fries Steffen <[email-masked]>
Date: Fri, 8 Apr 2005 15:24:38 +0200

Hi Francois,

> Note: I will point out that MIKEY allows for this today 
> because the certificates 
>       can be included in the MIKEY message. Not so for SDESC. 
> If we "pop up 2 levels" 
>       the certificates to the SIP level (instead of inside 
> MIKEY inside SDP in SIP), then 
>       we could have a solution that would work for both 
> mechanisms, allowing a UAC to 
>       advertize support for both mechanism. You could use 
> S/MIME with both mechanisms.
 
You could provide your certificates also as part of the S/MIME body. We
discussed that in a parallel threat. The only thing, that I'm not convinced
with is, if it is possible to use certificates, which are not directly
related to the FROM field in terms of a user name but a machine name for
instance. As far as I understand RFC3261, the subject name should correspond
to what is signaled in the FROM (AoR)field. That was actually my though to
use the authentication service of the identity draft to associate the AoR
with the certificate used for the session.

Regards	
	Steffen

> > I agree that the problems you describe below are all retargeting 
> > problems. The retargeting draft 
> (peterson-sipping-retarget-00 Section 
> > 2.3) notes that this problem applies to the RFC3261 INVITE-like 
> > certificate exchange mechanism. All in all, though, I'm pretty sure 
> > that these sorts of problems are more tractable in a SUBSCRIBE-like 
> > model for certificate acquisition than they are in an INVITE-like 
> > model for certificate acquisition.
> > 
> > In an INVITE-like model, you are sending the content that 
> you want to 
> > encrypt - that is, a session request - to an 
> unanticipatable target. 
> > In a SUBSCRIBE-like model, you are merely sending a request for a 
> > certificate to an unanticipatable target. The second is at least 
> > superficially better. If you strip everything out of the 
> INVITE that 
> > might be considered sensitive before you send your request, in the 
> > hopes of just soliciting a certificate in a response, then 
> basically 
> > you are using the INVITE as a makeshift fetch.
> > Using SUBSCRIBE has decided advantages over a fetch - 
> namely, you can 
> > establish persistent relationships and get notifications when the 
> > target's certificate changes.
> > 
> > Speaking at a high level, there is no technical reason why a 
> > subscription to a certificate service could not be 
> > redirected/retargeted or somehow trickle down to the right 
> service for 
> > the apparently destination of the call. The tough part, of 
> course, is 
> > synchronizing the path traversed by the subscription with the path 
> > that would be traveled by an INVITE, so that the 
> certificate held by 
> > the UAC will always correspond with the appropriate UAS 
> target. I can 
> > imagine publication models, though, in which users publishing 
> > certificates to a certificate service will cause the cert to 
> > propagate, through multiple publications, to where it needs 
> to go for 
> > the purposes of certificate acquisition. There are also 
> possible ways 
> > this could be addressed with presence.
> > 
> > So, regardless of whether or not sipping-certs solves all of the 
> > conceivable problems, I think it's a more promising direction than 
> > INVITEs. Of course, if a UA for whatever reason receives a request 
> > that is undecipherable, it can reply with a 493 Undecipherable 
> > message, as decribed in RFC3261, and return its certificate in that 
> > response. So, I think the functionality that you describe 
> at the end 
> > of your message is indeed already available in RFC3261. The issues 
> > rasied in the sipping-retargeting draft, though, illustrate 
> why this 
> > might not be sufficient. To address those sorts of 
> problems, I think 
> > you'll need something closer to sipping-certs.
> > 
> > Jon Peterson
> > NeuStar, Inc. 
> > 
> > properly, which I think could be addressed by something along the 
> > lines of sip-identity and what Steffen is talking about.
> will be able 
> > to fetch the certificate of the UA that will answer the 
> session. For 
> > example:
> > (I guess all those cases are a form of retargeting because the 
> > responder is not who was in the initial request).
> > In those cases, you can send SUBSCRIBEs as much as you 
> want, but you 
> > won't get a usable certificate because the INVITE after the 
> SUBSCRIBE 
> > is not going to land at the same place.
> > If instead something along lines of sip-indentity was used (even in 
> > conjunction with sipping-certs), I think we can get rid of the 
> > bootstrap problem you refer to, by having a two-pass process.
> as well with 
> > sipping-certs. In fact, it can be worst in the sense that 
> it would get 
> > in an infinite loop of retrying because the target keeps on moving.
> > If A had access to B's certificate beforehand (using 
> certs), then no 
> > problem. It works exactly as per sipping-certs.
> > If A couldn't get access to B's certificate beforehand, or 
> if it turns 
> > out to be the wrong B, then B would receive the request, 
> but the key 
> > (as per your example) would be wrong. B should be able to 
> provide it's 
> > certificate to A in the same session, so that the session could be 
> > renegotiated (if A whishes to do so).
> > One use case of course for this is encryption (sRTP). It would work 
> > equally well with SDESC and with MIKEY/kmgmt.
> > 
> > 
> > 
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of Peterson, Jon
> > > Your question points to an important difference in applicability 
> > > between sip-identity-04 and sipping-certs-01, and it is 
> essentially 
> > > a matter of what you mean by "communicate securely".
> > > 
> service, 
> > > whereas sipping-certs-01 offers a full suit of MIME security 
> > > services including confidentiality (the cost of course being that 
> > > UAs must support S/MIME and the certificate acquisition service).
> > > 
> which you 
> > > describe below was subtantially documented in RFC3261. There's no 
> > > doubt the integrity provided by
> > > sip-identity-04 could help to secure certificates 
> exchanged in this 
> > > manner. But the question is what security properties you want to 
> > > derive from this practice. If you want to use the exchanged 
> > > certificates for integrity, then well,
> > > sip-identity-04 already provides integrity. If you want 
> to use the 
> > > exchanged certificates for confidentiality, then you get the 
> > > bootstrapping problem - how does the sender of the INVITE 
> learn the 
> > > key they must use to encrypt the body of their request? 
> This is the 
> > > purpose of the certificate server, and of 
> sipping-certs-01. I doubt 
> > > that exchanging certificates within INVITEs and so on will prove 
> > > more servicable.
> > > 
> > > Jon Peterson
> > > NeuStar, Inc. 
> > > 
> > > > Assumed that two user A and B from two different 
> domains X and Y 
> > > > want to communicate securely. User A sends his INVITE with an 
> > > > attached certificate to User B in domain Y. The INVITE is send 
> > > > through an authentication service, which authenticates 
> (according 
> > > > the identity draft) that the AOR matches the FROM field. 
> > > > Additionally a digital signature is calculated also 
> over the body 
> > > > of the message. Thus also the attached certificate is signed. 
> > > > Using this approach would assure User B that User A has
> > > registered with his
> > > > credentials in domain X. User B could then use the received 
> > > > certificate to communicate securely with user A at 
> least for the 
> > > > duration of the session.
> > > > registered, the certificates may be different than in 
> the session 
> > > > before.
> > > > 
> > > > Is this scenario somehow covered by the identity draft? 
> It could 
> > > > save the credential server in certain scenarios. The approach 
> > > > itself may require an enhanced storing of the username and 
> > > > certificate associations if non-repudiation is desired.
> > > > 
> > > > Regards     
> > > >     Steffen
> > > > 
> > > 
> > > 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: "Francois Audet" <[email-masked]>
Date: Fri, 8 Apr 2005 11:48:51 -0400

> You could provide your certificates also as part of the 
> S/MIME body. We discussed that in a parallel threat. 

Right: that's what I was alluding to.

> The only 
> thing, that I'm not convinced with is, if it is possible to 
> use certificates, which are not directly related to the FROM 
> field in terms of a user name but a machine name for 
> instance. As far as I understand RFC3261, the subject name 
> should correspond to what is signaled in the FROM (AoR)field. 
> That was actually my though to use the authentication service 
> of the identity draft to associate the AoR with the 
> certificate used for the session.

Good: that was also my tought. That makes sense for the sender
certificate. An alternative would be that the subject in the certificate
would supercede the one in the From field.

In the identity draft, there is some hint of that in the last paragraph
of section 2.2 with regards to the receiver certificate (connected 
party) "clobbering the value in the To header".
_______________________________________________
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: Fries Steffen <[email-masked]>
Date: Thu, 14 Apr 2005 16:47:59 +0200

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

> Behalf Of Fries Steffen
> Sent: Thursday, April 07, 2005 4:56 PM
> Importance: High
> [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 
> > In what respect would using this certificates for an end-to-end 
> > integrity service be superior to just using
> > 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.
> 
> 
> 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
> > > 
> > > 
> > 
> 
> [email-masked] for questions on current sip

---

From: Fries Steffen <[email-masked]>
Date: Fri, 22 Apr 2005 12:18:18 +0200

> If Alice and Bob both get to use a phone called Device A, do 
> both Alice and Bob learn the private key of Device A?
Good point.  It may lead to the same problem downloading credentials to a
device which is is not completely under the users control.

> If device A calls Bob, and Bob is going to answer on device 
> B, how does A know what certificate to use for encrypting.
There are for instance MIKEY options in discussion, were the sender proposes
his certificate in the first message, while the receiver uses it for
encryption in a reply. So there is no need of having the certificate in
advance. Also signed DH variants do not need the receivers certificate in
advance. For sdescriptions, well, you are right, there I would need to have
the cert in advance.

> 
> 
> 
> On 4/20/05 11:12 PM, "Fries Steffen" 
> <[email-masked]> wrote:
> 
> > Assume an enterprise does not issue certificates to users but for 
> > devices for whatever reason. So the user authenticates during 
> > registration by using his username and password with HTTP Digest 
> > Authentication. The client he uses possesses a certificate. 
> When this 
> > user wants to make a phone call to somebody else, were, e.g., SRTP 
> > shall be used to encrypt the media, he simply may use the 
> certificate 
> > (and corresponding private key) belonging to the phone he 
> is using, if 
> > some instance is there assuring that he uses a dedicated (allowed) 
> > identity in the from field. As soon as the call ends and the same 
> > person is called again by the same user, the callee might receive a 
> > different certificate in case the caller switched the phone. The 
> > certificate may be used to protect the signaling for DSRTP 
> with either 
> > MIKEY or sdecription. I would consider this as a scenario, were the 
> > identity draft helps, as the authentication server assures 
> the identity from the FROM field, while the cert approach may 
> be to long winded.
> > 
> >> From: Cullen Jennings [mailto:[email-masked]]
> >> Sent: Wednesday, April 20, 2005 7:38 PM
> >> To: Fries Steffen; Jon Peterson
> >> Cc: [email-masked]
> >> Subject: Re: [Sip] RE: Question to Identity draft
> >> 
> >> 
> >> I'm lost on why and how you would use a device certificate to be a 
> >> user certificate. When a user logged off the phone would 
> you revoke 
> >> the device certificate?  It just all sounds very 
> convoluted. I more 
> >> or less view a user certificate as something that binds a 
> user to a 
> >> private key. What it sounds like you are doing here is binding a 
> >> private key that is specific to the device to the user.
> >> 
> >> On 4/20/05 1:05 AM, "Fries Steffen" 
> <[email-masked]> wrote:
> >> 
> >>> Agreed. 
> >>> What I had in mind was more that Alice from example.com 
> uses a cert 
> >>> issued for [email-masked], which may be a self-signed 
> >>> certificate or come from a corporate CA, which has not public 
> >>> available root certificate. In this case the 
> authentication service 
> >>> asserts the FROM field and the cert (in the body) may be
> >> used within
> >>> the dialog.
> >>> 
> >>> @Jon, I dont think this approach obviates the
> >> authentication service at all.
> >>> On
> >>> the contrary, the authentication service MUST assert the
> >> identity at
> >>> the beginning of the session, and the receiver is able to 
> keep this 
> >>> assertion together with the certificate received in the asserted 
> >>> message. The authentication service may be then left out of
> >> the path
> >>> for the rest of the session, when not needed or may be 
> invoked for 
> >>> further assertions. From my point of view this would be worth 
> >>> mentioning it as an example in the identity ID.
> >>> 
> >>> Regarding the cert service, this service is extermely useful, 
> >>> especially for the approach of storing credentials. But
> >> there may be
> >>> scenarios, were the usage may be simplyfied by using just the 
> >>> authentication service. For instance in cases were the 
> user has no 
> >>> certificate at all but the used device has one assigned (I
> >> used that
> >>> example at the beginning of this discussion too). The
> >> certificate may
> >>> have no meaning outside an enterprise but using the 
> authentication 
> >>> service provides the meaning for the receiver, at least for the 
> >>> duration of the session. The worst case here would be that
> >> the caller
> >>> uses a different phone for each call. Well, it might not be very 
> >>> likely, but it may be the worst case. Using a cert service
> >> here would
> >>> mean, that I would have to propagate my certificate
> >> information each
> >>> time I change the device.
> >>> The
> >>> certificate server would use the authentication server to
> >> assert the
> >>> FROM field and provide integrity protection for the body
> >> when sending
> >>> a NOTIFY. In those scenarios, the user may also sent the
> >> certificate
> >>> information inline via an authentication service and thus save 
> >>> additional communication with the cert server. Another
> >> scenario may be
> >>> the case were the cert server is not reachable by every
> >> receiver of a call.
> >>> 
> >>> Regards
> >>> Steffen
> >>> 
> >>> 
> >>> 
> >>>> From: Cullen Jennings [mailto:[email-masked]]
> >>>> Sent: Tuesday, April 19, 2005 10:30 PM
> >>>> To: Fries Steffen
> >>>> Cc: [email-masked]; Jon Peterson
> >>>> Subject: Re: [Sip] RE: Question to Identity draft
> >>>> Importance: High
> >>>> 
> >>>> 
> >>>> 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.
> >>>>> 
> >>>>> That much said, I would not rule out tunneling self-signed 
> >>>>> certificates in this fashion, no.
> >>>>> 
> >>>>> Jon Peterson
> >>>>> NeuStar, Inc.
> >>>>> 
> >>>>>> Sent: Thursday, April 14, 2005 7:48 AM
> >>>>>> 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
> >>>>>>  
> >>>>>> 
> >>>>>>> Of Fries Steffen
> >>>>>>> [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.
> >>>>>>> 
> >>>>>>>> 
> >> end-to-end
> >>>>>> strength of
> >>>>>>> [stf]Using the certificate would require to send just
> >> one message
> >>>>>>> over the authentication service and use the supplied
> >>>> certificate for
> >>>>>> containing the
> >>>>>> keymgmt? In
> >>>>>>> [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
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>> 
> >>>>>>>