Re: [Sipping] Further proceeding with draft-ietf-sipping-update-pai--05

[Cullen Jennings <fluffy at cisco.com>]

On Sep 3, 2008, at 1:35 AM, Elwell, John wrote:

> I received no feedback in the changes made in draft-05 concerning the
> forward compatibility mechanism, nor on the particular issue I asked  
> for
> comments on:
> http://www.ietf.org/mail-archive/web/sipping/current/msg16105.html
> Therefore I assume these changes are acceptable.
>

Uh, be careful with this sort of assumption. Unless you have consensus  
for significant technical changes, you should not be making them to WG  
documents. I'm trying to separating technical changes from editorial  
changes here - obviously I think the editor should just make editorial  
changes and technical changes which either have, or clearly would  
have, census.  This change is not backwards compatible with some 3325  
implementations and I don't think you have consensus one way or the  
other on it. Silence does not necessarily imply people agree - I  
suspect few people have read this. Perhaps my recollection of how this  
went in the meeting is wrong - I have not gone back and looked at the  
notes.
>
>
> So we have the one remaining issue concerning response authentication.
> We had some list discussion on this, the last one being on 20th  
> August:
> http://www.ietf.org/mail-archive/web/sipping/current/msg16121.html
>
> The use of PAI in responses is something that needs clarifying,  
> because
> RFC 3325 is ambiguous (sometimes it talks about SIP messages, other
> times it specifically talks about requests). In one place it actually
> states "message (request or response)".
>
> So I think we have the following options:
>
> 1. Say nothing about responses at all, thereby leaving us with the
> ambiguity that exists in RFC 3325. I don't think this is a sensible
> option. A lot of the value of updating RFC 3325 is lost if we don't
> tackle the response ambiguity issue.
>
> 2. Clarify the situation by stating that PAI (and PPI) MUST NOT be  
> used
> in responses. I would be very reluctant to go down this path, since I
> know there is a lot of use of PAI in responses (e.g., in 3GPP).
>
>
>
> 3. Devise a mechanism that exploits TLS to achieve authenticated
> response identity and use this in the update-pai draft. As Cullen
> pointed out, this needs to be a separate and non-trivial piece of  
> work,
> probably done in the SIP WG. Waiting for this would hold up update-pai
> for a considerable time.
>
> 4. Go ahead with the present update-pai draft, leaving it open how to
> achieve authentication of a response. The present example of how to do
> this (towards the end of section 3.3) is broken, so would have to be
> removed, or at least qualified.
>
> Any other options?
>
Saying is "MUST NOT be used"  is not the right path since at least  
some people want to leave the door open to adding this in future  
specifications. Describing how to do is not something that should be  
done as an update to 3325 because the solution to response identity  
have a wider implication than just PAI - if we are going to do that,  
we should do it in some separate draft in SIP. If folks agree with  
that, it seems like something along lines of option 4 is the right  
path where we say that PAI is not currently defined for responses but  
future specifications may do so. I think it is also important for the  
draft to document some of the reasons around why it is not defined for  
responses.
>
>
> My preference is for option 4. Please let me know which options you
> would prefer and which you would definitely not be happy with.
>
> John
>

Cullen <in my individual contributor roll>

>
>
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP