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

From: "Elwell, John" <[email-masked]>
Date: Sat, 19 Mar 2005 14:32:12 +0000

Cullen,

I would suggest something like the following, perhaps inserted prior to the
last paragraph of section 3.

"As a variant on this, the credential server might generate credentials on
behalf of users instead of accepting credentials from UAs using the PUBLISH
method. Either UA Bob1 or UA Bob2 could retrieve these credentials as
described above for UA Bob1. If the private key is delivered encrypted, the
passphrase needed for decryption would have to be delivered to Bob by some
separate means. Alice would still be able to retrieve the certificate for
Bob as described above."

John

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 05 March 2005 20:03
> To: John Elwell
> Cc: sipping
> Subject: Re: [Sipping] draft-ietf-sipping-certs-01
> 
> On 2/28/05 1:20 AM, "Elwell, John" <[email-masked]> wrote:
> 
> > 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. 
> 
> 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
> > 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.
> 
> 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. 
> 

_______________________________________________
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