RE: [Sip] RE: Question to Identity draft

[Fries Steffen <[e-mail]>]

Hi Francois,

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



> 
> 
> 
> 
> > -----Original Message-----
> > From: Peterson, Jon [mailto:[e-mail]]
> > Sent: Wednesday, April 06, 2005 12:39
> > To: Audet, Francois [SC100:9T51:EXCH]; Fries Steffen; 
> [e-mail]
> > Cc: IETF SIP List
> > Subject: RE: [Sip] RE: Question to Identity draft
> > 
> > 
> > 
> > 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:[e-mail]]
> > Sent: Tuesday, April 05, 2005 5:04 PM
> > To: Peterson, Jon; 'Fries Steffen'; '[e-mail]' 
> > Cc: 'IETF SIP List' 
> > Subject: RE: [Sip] RE: Question to Identity draft
> > 
> > 
> > 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.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] 
> On Behalf 
> > > Of Peterson, Jon
> > > Sent: Tuesday, April 05, 2005 14:20
> > > To: Fries Steffen; [e-mail]
> > > 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. 
> > > 
> > > > -----Original Message-----
> > > > From: Fries Steffen [mailto:[e-mail]]
> > > > Sent: Tuesday, April 05, 2005 3:04 AM
> > > > To: Peterson, Jon; [e-mail]
> > > > Cc: IETF SIP List
> > > > Subject: Question to Identity draft
> > > > 
> > > > 
> > > > 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 
> > > [e-mail] for questions on current sip Use 
> > > [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip