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

From: Allison Mankin <[email-masked]>
Date: Wed, 02 Nov 2005 14:00:22 -0800

Hi,

I think this is a reasonable place for the Area Director to
speak a little more.  There's definitely a precedent for making room
for existing types of SIM in the IETF-structured security designs.
But why is this an issue for the SIP working group,
once SIP has come up with a basic security design that has
IETF-structured security in it?

In my view, the Security Area needs to review your requirements
and then your specification.  I would recommend that
the document become an AD-sponsored individual submission, the
same way that Digest-AKA was.  

I would be happy to ask Russ Housley to adopt this work, and
ask SIP for advice to the extent any SIP issues come up.

Just reading a little, there have been enough attacks on CAVE, that
though it's widely used, the tradeoff for the specification will
be to make sure it states clearly what the risks are, and it's this
stuff especially that makes it a non-SIP Informational with a 
SEC AD sponsor.

Allison

Transport AD for SIP

_______________________________________________
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: "DENG, HUI -HCHBJ" <[email-masked]>
Date: Thu, 3 Nov 2005 23:36:40 +0800

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

	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. 

	==> Understand your concern here, one intention could be

	there are less IPR issue in IETF than 3GPP2.

	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. 

	==> I become understand what you said yesterday about conventional digest 

	solution, I feel what you proposed solution here is pretty smart, after get CAVE

	generated key, it could be directly used for HTTP digest solution, anyway,

	it still need more investigation about interopartion test consideration et al.

	-Hui

+���z��y�'������+���jwb�ƭ��!����'ڟ&�y�'~'^�ؚ��ݙ��z���-y������֧��ں�h�,�v�!����z��z+�v�b�隊V�+-jG���z����������޶�ʋ�����^�{^�ם��"�'���^jǧ�؟��^���z���e�隊V���'j�h�ț��uץzע���*.��&��^�̬�颚g���^�+az��~׫!����ޞ�m�觵��y��r*bz{r�鮲���)��b�隊Z+j�Zr���+v+�����{^��-����^�����ֆ)^��Z��u�z��}�+��$y�h��޷
+������y�����޲�'�&�+r~�ڟ'(���z���0�'!�(!������}��y�����~�b�隊

---

From: "DENG, HUI -HCHBJ" <[email-masked]>
Date: Thu, 3 Nov 2005 23:42:48 +0800

SGksIA0KDQoJSSB0aGluayB0aGlzIGlzIGEgcmVhc29uYWJsZSBwbGFjZSBmb3IgdGhlIEFyZWEgRGlyZWN0b3IgdG8gDQoJc3BlYWsgYSBsaXR0bGUgbW9yZS4gIFRoZXJlJ3MgZGVmaW5pdGVseSBhIHByZWNlZGVudCBmb3IgbWFraW5nIHJvb20gDQoJZm9yIGV4aXN0aW5nIHR5cGVzIG9mIFNJTSBpbiB0aGUgSUVURi1zdHJ1Y3R1cmVkIHNlY3VyaXR5IGRlc2lnbnMuIA0KCUJ1dCB3aHkgaXMgdGhpcyBhbiBpc3N1ZSBmb3IgdGhlIFNJUCB3b3JraW5nIGdyb3VwLCANCglvbmNlIFNJUCBoYXMgY29tZSB1cCB3aXRoIGEgYmFzaWMgc2VjdXJpdHkgZGVzaWduIHRoYXQgaGFzIA0KCUlFVEYtc3RydWN0dXJlZCBzZWN1cml0eSBpbiBpdD8gDQoNCgk9PT4gVGhhbmtzIEFEIGhlcmUsIHdlIHRoaW5rIHJlYXNvbiBpcyBzaW5jZSBIVFRQIEFLQS1EaWdlc3QgYXBwZWFycyBoZXJlIDopDQoNCglJbiBteSB2aWV3LCB0aGUgU2VjdXJpdHkgQXJlYSBuZWVkcyB0byByZXZpZXcgeW91ciByZXF1aXJlbWVudHMgDQoJYW5kIHRoZW4geW91ciBzcGVjaWZpY2F0aW9uLiAgSSB3b3VsZCByZWNvbW1lbmQgdGhhdCANCgl0aGUgZG9jdW1lbnQgYmVjb21lIGFuIEFELXNwb25zb3JlZCBpbmRpdmlkdWFsIHN1Ym1pc3Npb24sIHRoZSANCglzYW1lIHdheSB0aGF0IERpZ2VzdC1BS0Egd2FzLiAgDQoNCgk9PT4gd2UgYXJlIG5vdCBmYW1pbGlhciB3aXRoIHdoYXQncyBoYXBwZW5lZCBmb3IgRGlnZXN0LUFLQSBoaXN0b3JpY2FsbHkNCg0KCXdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCBtb3JlLg0KDQoJSSB3b3VsZCBiZSBoYXBweSB0byBhc2sgUnVzcyBIb3VzbGV5IHRvIGFkb3B0IHRoaXMgd29yaywgYW5kIA0KCWFzayBTSVAgZm9yIGFkdmljZSB0byB0aGUgZXh0ZW50IGFueSBTSVAgaXNzdWVzIGNvbWUgdXAuIA0KDQoJPT0+IFRoYW5rcyBhZ2Fpbg0KDQoJSnVzdCByZWFkaW5nIGEgbGl0dGxlLCB0aGVyZSBoYXZlIGJlZW4gZW5vdWdoIGF0dGFja3Mgb24gQ0FWRSwgdGhhdCANCgl0aG91Z2ggaXQncyB3aWRlbHkgdXNlZCwgdGhlIHRyYWRlb2ZmIGZvciB0aGUgc3BlY2lmaWNhdGlvbiB3aWxsIA0KCWJlIHRvIG1ha2Ugc3VyZSBpdCBzdGF0ZXMgY2xlYXJseSB3aGF0IHRoZSByaXNrcyBhcmUsIGFuZCBpdCdzIHRoaXMgDQoJc3R1ZmYgZXNwZWNpYWxseSB0aGF0IG1ha2VzIGl0IGEgbm9uLVNJUCBJbmZvcm1hdGlvbmFsIHdpdGggYSANCglTRUMgQUQgc3BvbnNvci4gDQoNCgk9PT4gSSBndWVzcyB0aGF0IGhlcmUgd2hhdCB5b3UgbWVhbiBpcyBsaWtlIHRoZSBTZWN0aW9uIG9mIFNlY3VyaXR5IENvbnNpZGVyYXRpb24NCg0KCWluIFJGQyAzMzEwLg0KDQoJT25lIHRoaW5nIEkgc3RpbGwgbm90IGNsZWFyIGlzIGRvIHlvdSBtZWFuIHRoaXMgYW5hbHlzaXMgc2hvdWxkIGJlIGRvbmUgaW4gcHJvYmxlbSANCg0KCXN0YXRlbWVudCBvciBpbiBzb2x1dGlvbi4NCg0KCUFub3RoZXIgdGhpbmcgaXMgZG8geW91IG1lYW4gdGhhdCBzb2x1dGlvbiBjb3VsZCBiZWNvbWUgbm9uLVNJUCBpbmZvcm1hdGlvbmFsDQoNCglvciBwcm9ibGVtIHN0YXRlbWVudCBjb3VsZCBiZWNvbWUgbm9uLVNJUCBpbmZvcm1hdGlvbmFsDQoNCgkgDQoNCgltYW55IHRoYW5rcw0KDQoJLUh1aQ0KDQo=Disclaimer:The contents of this e-mail, and its attachments, if any, are confidential and may be protectedby law against any unauthorized use.  If you have received this e-mail by mistake or havereason to believe that you are not the intended recipient, please notify the sender by replye-mail as soon as possible and delete it from your computer system immediately thereafter.If you are not the intended recipient, you must not copy this e-mail or attachment or disclosethe contents to any other person.  While we have made every effort to keep our network virus free,we take no responsibility for any computer virus which might be transferred by way of this e-mail.

---

From: Allison Mankin <[email-masked]>
Date: Thu, 03 Nov 2005 11:35:02 -0800

Hi,

>         ==> Thanks AD here, we think reason is since HTTP AKA-Digest appears here :)

Understood.  The first time that we extended Digest, we did do it with
a SIP WG document.  It sort of booted the security design.  Because
the original question asked by the AKA folks was whether this should be
HTTP-Digest-EAP-AKA, and there needed to be some discussion about why
not EAP (that was actually mostly with the Security Area, I recall)
and then some discussion to make sure that SIP Digest use was well thought
through (this was in 2002, a long time ago).

But when AKA folks needed to do HTTP AKA-Digest v2, this was not done as
a SIP document.  It was done as an independent AD-sponsored document
with security review.

>         ==> we are not familiar with what's happened for Digest-AKA historically
> 
>         would like to understand more.

See above.
>         ==> Thanks again
>         ==> I guess that here what you mean is like the Section of Security Consideration
> 
>         in RFC 3310.

Yes.

> 
>         One thing I still not clear is do you mean this analysis should be done in problem 
> 
>         statement or in solution.

I'd probably just do one document with both the problem statement and
the solution in it.

> 
>         Another thing is do you mean that solution could become non-SIP informational
> 
>         or problem statement could become non-SIP informational

I'd do one Informational document that is AD sponsored, a non-SIP Informational,
similar in content to draft-torvinen-http-digest-aka-v2-02.txt, which was
independent and AD-sponsored, and which is about to come out as RFC 4169.

Allison

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 4 Nov 2005 12:56:44 -0000

I am not sure I understand the concern about IPR here, and would like some clarification.

Both IETF and 3GPP2 have broadly similar IPR rules.

They both require IPR to be declared.

They both allow adoption of solutions that contain IPR.

Both organisations specifications are freely available without cost, and no charge is levied to implement the specifications by the organisations concerned.

I fail to see the difference. It depends on the decisions of the people adopting the solution as to what is there, and I would suggest that in your document, you have probably already gone far enough in deciding the solution that any IPR owned on the solution would become apparent.

As an example, I would note that most of the IPR in IMS comes from the inherited IETF specifications for SIP and associated protocols!

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> DENG, HUI -HCHBJ
> Sent: 03 November 2005 15:37
> To: Dean Willis; Binfeng Yan
> Cc: [email-masked]; Rohan Mahy
> Subject: RE: [Sip] Another Revised agenda for SIP et IETF 64
> 
>

---

From: "Binfeng Yan" <[email-masked]>
Date: Mon, 7 Nov 2005 12:04:49 +0800

Thanks for chair's help.

On Nov 4, 2005, at 11:54 Dean Willis wrote:

  It's a procedure defined in RFC 3932, which modifies the procedure of RFC 
2026. It allows for ADs to sponsor informational documents that are not in 
the scope of a specific working group, get the mIESG reviewed, and published 
as RFCs. It's preferred over direct-to-RFC-ed individual informationals 
because there is still IESG review over these documents and an opportunity 
for public debate that is not inherent with the direct-to-RFCed process of 
RFC 2026.

  While the IETF generally prefers approaches that are not IPR encumbered, 
the presence of an IPR claim does not generally prevent publication as an 
informational document.

---

From: "Binfeng Yan" <[email-masked]>
Date: Mon, 7 Nov 2005 12:12:37 +0800

IETF generally prefers approaches that are not IPR encumbered as chair 
said here.

  Anyhow, thanks for your explanation.

  -----Original Message----- 
  From: Drage, Keith  (Keith)
  Sent: 2005-11-4  20:56
  To: 'DENG, HUI -HCHBJ'
  Cc: [email-masked]'
  Subject: RE: [Sip] Another Revised agenda for SIP et IETF 64

  I am not sure I understand the concern about IPR here, and would like some 
clarification.

  Both organisations specifications are freely available without cost, and 
no charge is levied to implement the specifications by the organisations 
concerned.

  I fail to see the difference. It depends on the decisions of the people 
adopting the solution as to what is there, and I would suggest that in your 
document, you have probably already gone far enough in deciding the solution 
that any IPR owned on the solution would become apparent.

  As an example, I would note that most of the IPR in IMS comes from the 
inherited IETF specifications for SIP and associated protocols!

  regards

  Keith
  -------------------------------