Subject: Re: [Sip] Another Revised agenda for SIP et IETF 64

From: "Binfeng Yan" <[email-masked]>
Date: Wed, 2 Nov 2005 01:05:06 +0800

Dear Dean and Rohan

Thanks for your kindly put my request in the list :
http://www.softarmor.com/sipwg/meets/ietf64/requests.html

and also sorry until today it could be posted to repository after we 
negotiate
with secretriat many times:
http://www.ietf.org/internet-drafts/draft-yan-sip-cave-requirements-00.txt

I understand that you already announced almost final agenda.

But I still expect that this draft could be discussed in this ietf meeting
if there are still very small chance.

Best wishes to you
Sincerely yours

Binfeng 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Tue, 1 Nov 2005 17:14:16 -0600

> if there are still very small chance.

The draft draft-yan-sip-cave-requirements-00.txt seems to be raising  
a requirement for an EAP extension supporting CAVE, much like the  
existing EAP extension supporting AKA as documented in RFC 3310.

One obvious question would be "And why can't you just use  
conventional digest authentication?"

Would the subject be adequately raised by including one slide (you  
provide the content)  during the chair's status report? Or is there   
a deeper discussion that we need to be having at this time?

Thanks,

--
Dean

---

From: "Binfeng Yan" <[email-masked]>
Date: Wed, 2 Nov 2005 23:49:20 +0800

Hi, Dean

> The draft draft-yan-sip-cave-requirements-00.txt seems to be raising  a 
> requirement for an EAP extension supporting CAVE, much like the  existing 
> EAP extension supporting AKA as documented in RFC 3310.

RFC 3310 is HTTP digest extension supporting AKA, which is different
with EAP extension AKA like IKEv2 EAP-AKA.

> One obvious question would be "And why can't you just use  conventional 
> digest authentication?"

Since there are tremendous subscribers of CDMA 1x, and they are currently
using CAVE, to ask them change SIM card is not easy work. Only China Unicom
is the only one CDMA 1x operator around the world using removable SIM card
like GSM/GPRS cellular phone.

As defined in RFC3329, four authentication mechanisms is supported by
SIP: tls, digest, ipsec-ike, ipsec-man. Currently none of them support
CAVE authentication.

Either to extend one of them supporting CAVE or to define a new CAVE
mechanism is essential to solve this problem.

> provide the content)  during the chair's status report? Or is there   a 
> deeper discussion that we need to be having at this time?
>

If possible, to attract more attention, we guess that one slide is
not enough for raising this problem. If possible, maybe 5 minutes
will be enough.

Thanks for your help
Best regards,

Binfeng

---

From: Dean Willis <[email-masked]>
Date: Wed, 2 Nov 2005 13:37:25 -0600

> SIP: tls, digest, ipsec-ike, ipsec-man. Currently none of them support

To be honest, I'm not at all sure that a direct extension to support  
CAVE would withstand an IETF security review, although I'm sure that  
our security advisors could say more on that. Those guys seem to be  
deeply paranoid.  If there is a retrofit needed to secure CAVE to the  
level that IETF would endorse, I would think that would be in-scope  
for 3GPP2, not IETF.

The CDMA operators I know doing SIP appear to have successfully  
deployed using digest (which, while it has certain security  
limitations, is essentially well-understood and is already specified  
by IETF). Why doesn't this approach work in the general CDMA case? I  
think you could perhaps use CAVE-secured OTA provisioning to push  
digest credentials easily to the phone, and thereby eliminate another  
IETF dependency.

--
Dean