Re: Mutual Auth: Enhancement, not correction

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.

DRAGE, Keith (Keith) wrote:
> 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:dean.willissoftarmor.com] 
>> Sent: Friday, November 30, 2007 6:06 AM
>> To: Adam Roach
>> Cc: sipietf.org List; Cullen Jennings; DRAGE,
Keith (Keith)
>> Subject: Re: [Sip] Mutual Auth: Enhancement, not
correction
>>
>>
>> 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
>>
>>
>>
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 

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


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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


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

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


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip