RE: [Sipping] SIP Identity Usage in Enterprise Scenarios

["Michael Slavitch" <[e-mail]>]

Due to past experience I am very pessimistic about how these numbers are
actually chosen in implementation, indeed I am pessimistic about any
protocol that's not locked down tight with all parts mandatory except
when they really really must have wiggle room and only for a clearly
defined and well understood purpose.  

The IETF is littered with protocols that leave things far too open to
interpretation. SNMP is but one notorious example of this, where each
implementation of so-called standard MIBs must be treated as a special
case due to almost certain implementation error.  If this happens in the
IP world where each device has a unique flavour of ICE it does not bode
well at all for the future. 

So what I suggest is some boring consistency, especially when there is
the likelihood of additional  and broad benefit.

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.  This adds a level of consistency and rigor
that's tough to muck up in implementation, especially in non-trivial
implementations where many thousand separate sessions may concurrently
be established from the same ICE source at the same time, and this is
especially true when many simultaneous sessions are being established
between two NAT networks.

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.

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.

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.

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=a2c8da4fe0c4
Not spam:
http://asteroid.objectworld.com/canit/b.php?c=n&i=434640&m=a2c8da4fe0c4
Forget vote:
http://asteroid.objectworld.com/canit/b.php?c=f&i=434640&m=a2c8da4fe0c4
------------------------------------------------------
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