[MMUSIC] RE: [Sipping] SIP Identity Usage in Enterprise Scenarios

["Dan Wing" <[e-mail]>]

...
> Using a session certificate asserts that the data streams and all
> associated negotiations belong to the same asserted identity 
> and session all the way down the line. 

So you're proposing this would occur at the session level so there
is only one RSA operation, plus CA validation, that needs to occur
and not on per a=candidate line?

...
> By tying the ICE negotiating identity to a session cert this makes
> everything easier to implement, manage, monitor and debug, as session
> and media can be tied together up and down the line. It is 
> also a tight way of ensuring implementation rigor.

I don't agree that certificates and RSA operations are easier to 
implement, manage, monitor and debug compared to the username/password
operations that were in ice-04.

How would -sip-identity- fail at providing those same functions?

> The recently expired draft-ignjatic-msec-mikey-rsa-r-00 has a proposal
> for key management where instigators do not initially know 
> the keys  of the respondent, a use of which is described as a best 
> practise for identity assertion in 
> draft-fries-sipping-identity-enterprise-scenario-00.txt.

MIKEY with RSA-R doesn't assure identity of the caller, it only 
provides assurance over the SRTP keys themselves.

> As SIP evolves identity assurance is going to be a key pain point, by
> taking these steps proactively we will help inoculate the protocol and
> its subcomponents from any future pain.

I believe that is sip-identity's purpose in life, no?

-d


> Regards to all,
> 
> Michael
> 
> 
> 
>  
> It is amazing what you can accomplish if you do not care who gets the
> credit. 
>  
> - Harry S Truman
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[e-mail]] 
> Sent: September 14, 2005 10:07 PM
> To: Michael Slavitch
> Cc: Fries, Steffen; [e-mail]; IETF MMUSIC WG
> Subject: Re: [Sipping] SIP Identity Usage in Enterprise Scenarios
> 
> moving to mmusic since we are now talking about ICE.
> 
> Michael Slavitch wrote:
> 
> > As a further update to my previous email, look at the USERNAME 
> > provision in the current ID for ICE (draft 05), which I consider a 
> > weakness of the protocol.
> 
> Firstly, it has been pointed out to me from several sources that the
> security mechanism in the most recent ICE draft is severely broken. I
> had somehow gotten it into my head that we didnt need to 
> convey both the
> username and password, which is false.
> 
> The next ICE draft will revert to what was there previously; each side
> conveys a username fragment and one side provides the password.
> 
> > 
> > My preference would be to replace that password with some kind of 
> > MIKEY exchange such that the password is only for that session, 
> > otherwise you'll see cheap phones or all with the same 
> password being 
> > vulnerable, which I suggest is a strong weakness of ICE.
> 
> Why would this happen? The password needs to be selected randomly for
> each candidate. Thats a requirement of the protocol. Its not that hard
> to create a random number.
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [e-mail]                              FAX:   [phone]
> http://www.jdrosen.net                         PHONE: [phone]
> http://www.cisco.com
> 
> 
> --
> BEGIN-ANTISPAM-VOTING-LINKS
> ------------------------------------------------------
> Teach CanIt if this mail (ID 434640) is spam:
> Spam:
> http://asteroid.objectworld.com/canit/b.php?c=s&i=434640&m=a2c
> 8da4fe0c4
> Not spam:
> http://asteroid.objectworld.com/canit/b.php?c=n&i=434640&m=a2c
> 8da4fe0c4
> Forget vote:
> http://asteroid.objectworld.com/canit/b.php?c=f&i=434640&m=a2c
> 8da4fe0c4
> ------------------------------------------------------
> END-ANTISPAM-VOTING-LINKS
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic