Subject: [Sip] (no subject)

From: [email-masked]
Date: Mon, 25 Jun 2007 09:40:26 -0400

Sorry, I had missed this going by until someone pointed it out ... 

Basically, I would support this work in SIP WG, which does seem like the 
right place at least for requirements (can see where it goes next from 
there). 

> So can I hear opinions of the WG on:
> 
> -              whether this represents a problem space that the working 
group
> should draft requirements on?

SIP WG seems like as good a place as any, at least for requirements. 

> 
> -              whether the problem space exists but is something 
slightly
> different, and if so what is that problem space?

Yes, the problem space exists. 

> 
> -              whether there is a more general problem that the security 
area
> should be addressing, rather than the SIP group addressing something
> specific?

Develop the *requirements* first, then ask this question.  A worthy 
question for this list would be whether the requirements should expand to 
use cases beyond Registrar interactions (e.g to Invite, Subscribe/Notify, 
or to streaming uses, etc).  Of course, the Security Area should be 
involved regardless, esp at solution time. 

> 
> -              based on your answers to the first three questions, 
whether this
> draft is essentially in the right direction to be adopted as the WG
> draft assuming we create the charter item, or whether we need to seek
> some other input draft?

I believe it is close, modulo wondering about expansion beyond Register as 
above.  (Could dicker over details...)

> 
> -              and finally, whether (assuming we go ahead with this 
work) there
> is any work in any other IETF WG that we should take account of?

Dunno. 

-- Peter Blatherwick

-----Original Message-----

From: DRAGE, Keith (Keith) [mailto:[email-masked]]

Sent: Wednesday, June 13, 2007 9:58 AM

To: IETF SIP List

Subject: [Sip] Certificate authentication in SIP

(As WG chair)

http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03
.txt 

Describes a set of requirements for:

   This document defines requirements for adding certificate
   authentication to the Session Initiation Protocol (SIP).  This
   document is being presented with the intention of providing clear
   requirements to any potential solutions specifying certificate
   authentication within SIP networks.  Supporting certificate
   authentication in SIP would provide strong authentication and
   increase the types of possible deployment scenarios.

(Before we go any further, please forget all about the solutions
document - that comes later and we are not dealing with it now)

We need to decide whether there is support for a body of work in this
area, and therefore whether we should charter some requirements work in
the SIP WG.

(Because this is security related we have agreed that SIP does the
requirements drafting and not SIPPING)

So can I hear opinions of the WG on:

-                whether this represents a problem space that the working 
group
should draft requirements on?

-                whether the problem space exists but is something 
slightly
different, and if so what is that problem space?

-                whether there is a more general problem that the security 
area
should be addressing, rather than the SIP group addressing something
specific?

-                based on your answers to the first three questions, 
whether this
draft is essentially in the right direction to be adopted as the WG
draft assuming we create the charter item, or whether we need to seek
some other input draft?

-                and finally, whether (assuming we go ahead with this 
work) there
is any work in any other IETF WG that we should take account of?

Regards

Keith

Regards

Keith

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of 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: Eric Burger <[email-masked]>
Date: Thu, 28 Jun 2007 13:31:42 -0700

Why not SIPPING, the home of requirements?

On 6/25/07 6:40 AM, "[email-masked]"
<[email-masked]> wrote:

> Basically, I would support this work in SIP WG, which does seem like the right
> place at least for requirements (can see where it goes next from there).
> 
>> -                whether the problem space exists but is something slightly
> Develop the *requirements* first, then ask this question.  A worthy question
> for this list would be whether the requirements should expand to use cases
> beyond Registrar interactions (e.g to Invite, Subscribe/Notify, or to
> streaming uses, etc).  Of course, the Security Area should be involved
> regardless, esp at solution time.
> 
>> 
>> -                based on your answers to the first three questions, whether
>> this
>> -                and finally, whether (assuming we go ahead with this work)
>> there
> <http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03>
> .txt 
> 
> -                whether the problem space exists but is something slightly
> -                based on your answers to the first three questions, whether
> this
> -                and finally, whether (assuming we go ahead with this work)
> there
> <https://www1.ietf.org/mailman/listinfo/sip>

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: Dean Willis <[email-masked]>
Date: Thu, 28 Jun 2007 23:49:55 -0500

> Why not SIPPING, the home of requirements?

The current policy of task division puts "security" in SIP instead of  
SIPPING. Although the task allocation is quite arguable on this  
specific exercise.

--
Dean

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 29 Jun 2007 08:28:51 +0200

>From the original mail:

> requirements drafting and not SIPPING)

I did agree this with the SIPPING chairs before sending the mail out.

Keith 

> From: Eric Burger [mailto:[email-masked]] 
> Sent: Thursday, June 28, 2007 9:32 PM
> To: IETF SIP
> Cc: DRAGE, Keith (Keith)
> Subject: Re: [Sip] Certificate authentication in SIP
> 
> > Basically, I would support this work in SIP WG, which does 
> seem like 
> > the right place at least for requirements (can see where it 
> goes next from there).
> > 
> > question for this list would be whether the requirements 
> should expand 
> > to use cases beyond Registrar interactions (e.g to Invite, 
> > Subscribe/Notify, or to streaming uses, etc).  Of course, 
> the Security 
> > Area should be involved regardless, esp at solution time.
> > 
> >> 
> > I believe it is close, modulo wondering about expansion beyond 
> > Register as above.  (Could dicker over details...)
> > 
> >> 
> > area, and therefore whether we should charter some 
> requirements work 
> > in the SIP WG.
> > 
> > This list is for NEW development of the core SIP Protocol Use 
> > sip-implementors at cs.columbia.edu for questions on 
> current sip Use 
> > sipping at ietf.org for new developments on the application of 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
> 
> 
> 
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
>