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

From: Fries Steffen <[email-masked]>
Date: Wed, 20 Apr 2005 10:05:44 +0200

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

> -----Original Message-----
> 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.
> > 
> >> -----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: Wed, 20 Apr 2005 10:37:48 -0700

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.