Subject: [Sip] Hopefully final agenda for SIP at IETF 70

From: Dean Willis <[email-masked]>
Date: Thu, 29 Nov 2007 14:34:52 -0600

Agenda revised again. Since Vijay won't be there to talk about  
connect-reuse, we'll tackle the candidates for the essential  
corrections process.

Session 1, Monday December 3, 1740-1950 Salon A/B
Start Time
Topic
Discussion Lead
Reading List
1740
Agenda Bash and Status
Chairs
This document
1800
Location Conveyance
Brian Rosen
James Polk
draft-ietf-sip-location-conveyance-09
1830
INFO Harmful
Eric Burger
draft-burger-sip-info-02
1900
INFO Events
Hadriel Kaplan
draft-kaplan-sip-info-events-00
1930
Essential corrections
Keith Drage
draft-ietf-sip-record-route-fix-01
draft-gurbani-sip-ipv6-abnf-fix-00
draft-hilt-sip-correction-503-01
draft-dotson-sip-mutual-auth-00
draft-sparks-sip-invfix-00

1950
End

Session 2, Wednesday December 5, 0900-1130, Salon A/B
Start Time
Topic
Discussion Lead
Reading List
0900
Agenda Bash
Chairs
This Document
0910
Outbound
Rohan Mahy
draft-ietf-sip-outbound-11
1000
RPH In Responses
James Polk
Janet Gunn
draft-polk-sip-rph-in-responses-00
draft-gunn-sip-req-for-rph-in-responses-00.txt

1030
Media Identity
Dan Wing
draft-wing-sip-identity-media-01
1055
DTLS Framework
Eric Rescorla
Jason Fischl
draft-ietf-sip-dtls-srtp-framework-00
1130
End

_______________________________________________
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: Adam Roach <[email-masked]>
Date: Thu, 29 Nov 2007 15:53:12 -0600

On 11/29/07 2:34 PM, Dean Willis wrote:
> <http://tools.ietf.org/html/draft-ietf-sip-record-route-fix-01>
>
> <http://tools.ietf.org/wg/sip/draft-gurbani-sip-ipv6-abnf-fix-00.txt>
> <http://tools.ietf.org/wg/sip/draft-hilt-sip-correction-503-01.txt>
> <http://tools.ietf.org/wg/sip/draft-dotson-sip-mutual-auth-00.txt>
> <http://tools.ietf.org/wg/sip/draft-sparks-sip-invfix-00.txt>
>
>
*
*Why are we considering draft-dotson-sip-mutual-auth for inclusion in 
the essential corrections process? Don't get me wrong -- the mechanism 
described in the document seems like a useful _extension_ to SIP, but 
it's hardly correcting something that's broken. I think things will get 
very confusing if we start couching _enhancements_ in terms of deltas to 
RFC 3261.

/a

---

From: Dean Willis <[email-masked]>
Date: Fri, 30 Nov 2007 00:05:46 -0600

On Nov 29, 2007, at 3:53 PM, Adam Roach wrote:

>> *
> *Why are we considering draft-dotson-sip-mutual-auth for inclusion  
> in the essential corrections process? Don't get me wrong -- the  
> mechanism described in the document seems like a useful _extension_  
> to SIP, but it's hardly correcting something that's broken. I think  
> things will get very confusing if we start couching _enhancements_  
> in terms of deltas to RFC 3261.
>

the argument goes that this was a bug in RFC 3261:

RFC 2543 had this to say about the Authentication-Info headers:

14.3 Digest Authentication

    The rules for digest authentication follow those defined in [36],
    with "HTTP 1.1" replaced by "SIP/2.0" in addition to the following
    differences:
         4.   The Authentication-Info and Proxy-Authentication-Info
              fields are not used in SIP.

But by the time we did RFC 3261, we had decided that mutual  
authentication using digest was important, so we added:

20.6 Authentication-Info

    The Authentication-Info header field provides for mutual
    authentication with HTTP Digest.  A UAS MAY include this header  
field
    in a 2xx response to a request that was successfully authenticated
    using digest based on the Authorization header field.

    Syntax and semantics follow those specified in RFC 2617 [17].

    Example:

       Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"

But for some currently unknown reason, we forgot to add the also- 
important Proxy-Authentication-Info header back in.

Now, is that a bug in the spec that needs correction, or is it an  
enhancement? Enquiring minds want to know.

--
Dean

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 30 Nov 2007 12:13:26 +0100

I got halfway through my answer to Adam, and discovered Dean had got
there first. 

Dean has answered all the technical issues, although feedback would be
useful from the large number of people that got involved in the final
delivery of RFC 3261 on how Proxy-Authentication-Info was omitted at the
time that the Authentication-Info header was added (we've asked the key
people who supposedly did this section and not got any input). 

That leads me only to add:

The SIP WG does it, whether it is an bugfix or not, so the progression
will not be so different, one way or the other. (In security issues SIP
does both the requirements and the protocol).

But the floor is open on all these to indicate:

-	progress rapidly
-	reject
-	more discussion needed
-	treat as a normal extension

And we would welcome such input to the list - if time permits in
Vancouver we will also be asking this at the end of one of the sessions.

Regards

Keith

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Friday, November 30, 2007 6:06 AM
> To: Adam Roach
> Cc: [email-masked] List; Cullen Jennings; DRAGE, Keith (Keith)
> Subject: Re: [Sip] Mutual Auth: Enhancement, not correction
> 
> 
> > it's hardly correcting something that's broken. I think things will 
> > get very confusing if we start couching _enhancements_ in terms of 
> > deltas to RFC 3261.
> >
> 
>     authentication with HTTP Digest.  A UAS MAY include this 
> header field
> But for some currently unknown reason, we forgot to add the 
> also- important Proxy-Authentication-Info header back in.
> 
> Now, is that a bug in the spec that needs correction, or is 
> it an enhancement? Enquiring minds want to know.
> 
> --
> Dean
> 
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 Nov 2007 10:58:04 -0500

I don't actually recall explicitly deciding to reject 
Proxy-Authentication-Info; however it was a long time ago. But anyway, 
its water under the bridge. Clearly its not there.

That said, I agree with Adam and do not think this is an essential 
correction. Its a new feature. It adds proxy to user authentication. 
Indeed, I think its clearly the case that there are differing 
requirements driving user to proxy authentication than there are driving 
the reverse (one is for protecting against fraud, the other against 
malicious proxies).

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Dean Willis <[email-masked]>
Date: Fri, 30 Nov 2007 10:31:59 -0600

On Nov 30, 2007, at 9:58 AM, Jonathan Rosenberg wrote:

> correction. Its a new feature. It adds proxy to user  
> authentication. Indeed, I think its clearly the case that there are  
> differing requirements driving user to proxy authentication than  
> there are driving the reverse (one is for protecting against fraud,  
> the other against malicious proxies).
>

I don't disagree with the result (progress the draft outside the  
essential corrections process) but I think the use-case is really the  
same: SIP nodes protecting themselves from other SIP nodes that may  
be impostors.

It doesn't really matter whether the nodes in question are proxies or  
user agents -- after all, some nodes will be proxies for some request  
and UAs for other requests. The way you have it worded makes it sound  
as if the proxies are trustworthy and the user agents aren't, which  
is classic "telco" mentality and not particularly valid in an  
Internet scenario. In the real world, I expect to see both hostile  
proxies and hostile user agents.

--
Dean

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 30 Nov 2007 11:12:23 -0700

Agree with Dean (w.r.t. technical details and the scenarios to protect the client from), 
That said, I think it was felt that this was left out as an oversight, as opposed 
to a conscious decision (need  verification of this, as Keith indicated earlier). 
 
In any case it would be nice to progress the I-D within the WG (irrespective of
the path chosen) and see if there is something amiss in what is being 
proposed. 
 
- S

________________________________

From: Dean Willis [mailto:[email-masked]]
Sent: Fri 11/30/2007 9:31 AM
To: Jonathan Rosenberg
Cc: [email-masked]; Cullen Jennings; DRAGE,Keith (Keith); Adam Roach
Subject: Re: [Sip] Mutual Auth: Enhancement, not correction

--
Dean

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 30 Nov 2007 19:31:47 +0100

At 16:58 30/11/2007, Jonathan Rosenberg wrote:
>I don't actually recall explicitly deciding to reject Proxy-Authentication-Info; however it was a long time ago. But anyway, its water under the bridge. Clearly its not there.
>
>That said, I agree with Adam and do not think this is an essential correction. Its a new feature. It adds proxy to user authentication. 

However, the capability to authenticate proxy servers can help to address an ugly security gap: 
relay attacks. Such can be orchestrated fairly easily (e.g., without eavesdropping
capability) now and allow impersonation of a user. That said, it appears a piece of work to
me which deserves appropriate attention. 

-jiri

>Indeed, I think its clearly the case that there are differing requirements driving user to proxy authentication than there are driving the reverse (one is for protecting against fraud, the other against malicious proxies).
>
>-Jonathan R.

--
Jiri Kuthan            http://iptel.org/~jiri/