Subject: Re: [Sipping] draft-ietf-sipping-certs-01

From: Cullen Jennings <[email-masked]>
Date: Sat, 05 Mar 2005 11:54:29 -0800

Thanks for the comments - inline

On 2/28/05 1:20 AM, "Elwell, John" <[email-masked]> wrote:

> Cullen,
> 
> In section 3: "The private key portion of the credential may have been
> encrypted with a secret that only Bob's UA (and not the credential server)
> knows." If Bob's second UA doesn't already have Bob's credentials, it is
> unlikely to already have a decryption key. Perhaps you intended the key to
> be derived from a passphrase that Bob himself has to enter? This does appear
> to be the case from section 5.

yes - will update to say that.

> 
> "Some time later Alice decides that she wishes to discover Bob's certificate
> so that she can send him an encrypted message." Or so that she can verify a
> signed message from Bob.

ok will add - but I think that we are moving towards using Identity for
signing more than this but yes, it could be used this way

> 
> In section 4: "If the UA uses a cached certificate in a request and receives
> a 493 (Undecipherable) response, it SHOULD remove the certificate it used
> from the cache, attempt to fetch the certificate again, and retry the
> original request again." I believe a 493 response can arise because of
> retargeting to a UAS with different credentials. Simply refreshing the
> certificate in this situation will not do. Until we have a solution to
> response identity or a ruling on the use of retargeting versus redirection,
> we can't solve this. However, it should at least be mentioned.

Excellent point - will update. Now if only I had a way to the the connected
party id, I mean the response Identity, I could fetch the correct
certificate :-) I will discuss this and I point out that once the response
identity problem is solved, it will solve this problem here too.

> 
> Section 8 seems to be missing subscriber generation of PUBLISH requests.
> 
will add. 

> I think it would also be useful to be able to use the credential service in
> a mode in which it generates credentials (and perhaps gets them signed by a
> CA) and makes them available to UAs, rather than accepting credentials via
> PUBLISH. In this case the passphrase would be generated at the server and
> communicated to the user by out of band means. This may be preferred by some
> organisations. Also it might help avoid a possible situation where, without
> Bob noticing a hacker gets access to Bob's UA and instructs the UA to
> generate new credentials for Bob, along with a new passphrase. Only the
> hacker knows the passphrase, so Bob would find that his other UAs have new
> private keys that Bob cannot unlock.
>  

will address in separate email

> John 
> 
> ________________________________
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cullen Jennings
> Sent: 23 February 2005 01:24
> To: sipping
> Subject: [Sipping] draft-ietf-sipping-certs-01
> 
> 
> 
> I submitted a new version of the draft "Certificate Management
> Service for The Session Initiation Protocol (SIP)". This version is much
> more specific about all the normative details - I would greatly appreciate a
> careful read on this as people are starting to implement it. You can find
> the HTML version at
> 
> 
> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sipping-certs-01
> .html
> 
> (and change html to txt for text version)
> 
> Thanks, Cullen
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 05 Mar 2005 12:02:52 -0800

On 2/28/05 1:20 AM, "Elwell, John" <[email-masked]> wrote:

> organisations. 

yes - I can definitely imagine this. I was thinking that one could consider
it as a the organization IT department had a UA that could publish into the
credential server and it was the only thing that was authorized to do this.
It of course could also be implemented as just the credential could be
directly loaded and all PUBLISH were rejected. The Credential server could
generate the certificates and use some online protocol to talk to the CA to
get them signed. I don't think any normative text would change to talk about
this - it is more a detail of implementation of the credential server. Do
you have some suggested text I should add to explain this? Does it need
mentioning?

> Also it might help avoid a possible situation where, without

Agreed - this would assume that the UA the hacker got had cached in it the
shared secret between the server and the UA had no protection to access the
secret. I imagine this will be true, oh, about 100% of the time.