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

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 14 Sep 2005 11:52:23 -0400

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.

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.

Regards

Michael

It is amazing what you can accomplish if you do not care who gets the
credit. 
 
- Harry S Truman

-----Original Message-----
From: Fries, Steffen [mailto:[email-masked]] 
Sent: September 14, 2005 11:10 AM
To: Michael Slavitch; [email-masked]
Cc: Tschofenig, Hannes
Subject: RE: [Sipping] SIP Identity Usage in Enterprise Scenarios

Hi Michael,

no, from us there is just the draft available. 
What is your approach/your thoughts with respect to the draft?

Regards
	Steffen

> -----Original Message-----
> From: Michael Slavitch [mailto:[email-masked]]
> Sent: Wednesday, September 14, 2005 5:07 PM
> To: Fries, Steffen; [email-masked]
> Subject: RE: [Sipping] SIP Identity Usage in Enterprise Scenarios
> 
> Hello,
> 
> We are very much interesting in discussing SIP identity in the 
> enterprise. Is there more documentation than this brief draft?  If 
> need be we could collaborate using our own implementations as an 
> example.
> 
> Regards
> 
> Michael
> 
> 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Fries, Steffen
> Sent: September 14, 2005 10:57 AM
> To: [email-masked]
> Subject: [Sipping] SIP Identity Usage in Enterprise Scenarios
> 
> Hi all,
> 
> shortly before the last IETF meeting we submitted a draft regarding 
> SIP Identity Usage in Enterprise Scenarios. This document describes a 
> scenario for the SIP identity work involving certificate management in

> enterprise environments.
> A discussion of possible solutions is included.
> The document
> would be targeted for a BCP, as the available SIP identity work 
> already provides the base on the standards track.
> 
> Unfortunately there hasn't been discussion at the mailing list so far.
> We would like to see if there is any interest in doing this work 
> within this WG.
> 
> You may download the document from
> http://www.tschofenig.priv.at/drafts/draft-fries-sipping-identity-
> enterprise
> -scenario-00.txt
> 
> With friendly regards
> 
> Steffen
> 
> _______________________________________________
> 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
> 
> 
> --
> 
> 
> 

--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------
Teach CanIt if this mail (ID 434179) is spam:
Spam:
http://asteroid.objectworld.com/canit/b.php?c=s&i=434179&m=a059b2857d4f
Not spam:
http://asteroid.objectworld.com/canit/b.php?c=n&i=434179&m=a059b2857d4f
Forget vote:
http://asteroid.objectworld.com/canit/b.php?c=f&i=434179&m=a059b2857d4f
------------------------------------------------------
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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 Sep 2005 18:46:29 -0700

> 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.

-05 doesn't handle username/password exchanges correctly.  I think there
have been a few posts recently on this very topic.  -04 did this correctly.

> 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,

I don't believe generating a unique STUN username/password is
any harder than a unique SIP Call-ID or tag.

> which I suggest is a strong weakness of ICE.

Considering that each a=candidate line needs its own STUN username/password:

  * If you are proposing MIKEY DH (or MIKEY with any of 
    the public key modes), how many a=candidate lines 
    will you be able to process before running out of
    CPU horsepower?

  * If you are proposing MIKEY DH (or MIKEY with any
    of the public key modes), we need a public key 
    infrastructure.  We don't yet have one.  ICE was
    invented for NAT traversal, and we can't create a
    need on a non-existing solution (globally 
    available PKI) for NAT traversal.

  * If you are proposing the pre-shared key mode, we 
    need a way to pre-share the MIKEY keys across 
    administrative domains.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Sep 2005 22:07:26 -0400

moving to mmusic since we are now talking about ICE.

> in the current ID for ICE (draft 05), which I consider a weakness of the

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.

> 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
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com