Subject: [MMUSIC] Re: [Sipping] SIP Identity Usage in Enterprise Scenarios

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

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Sep 2005 09:23:26 -0400

Moving to mmusic where this belongs.

I agree with Dan.

-Jonathan R.

Dan Wing 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.
> 
> 
> -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.
> 
> 
> 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: "Michael Slavitch" <[email-masked]>
Date: Thu, 15 Sep 2005 12:14:30 -0400

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

Yes indeed, that is correct.

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

It doesn't but this extends the identity down the line to the ICE
negotiation.

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

I agree on this part.

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

Agreed. But using the results from sip-identity down the line to
negotiations over media makes things much more reassuring. What ICE does
is effectively break NAT.  If you're breaking NAT in a network it would
do well to do so in a way that assures network managers that each break
has a corresponding identity that can be easily tracked. That is what is
useful. It doesn't matter what identity technique is used as long as one
is consistently used down the line and can be implemented effectively
and easily by all parties. 

Michael

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 19 Sep 2005 19:02:11 -0500

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

The draft-ignjatic-msec-mikey-rasa-r-00 is now a working group
document under the MSEC Working Group and has therefore been
renamed:
http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt