RE: [Sip] WGLC for referred-by

["Mary Barnes" <[e-mail]>]

Robert,

Thanks for your response; I just have a couple of final comments embedded
below [MB].

Mary.

-----Original Message-----
From: Robert Sparks [mailto:[e-mail]]
Sent: Friday, June 20, 2003 2:18 PM
To: Barnes, Mary [NGC:B602:EXCH]
Cc: [e-mail]; Jon Peterson; Dean Willis; 'Rohan Mahy'
Subject: RE: [Sip] WGLC for referred-by




On Fri, 2003-06-20 at 11:36, Mary Barnes wrote:
> There were a couple points that I made on the list around the -01 version
> that don't seem to have been addressed
> http://www1.ietf.org/mail-archive/working-groups/sip/current/msg07955.html
> and I couldn't find that they had been responded to on the list in the
> archives: 
> 
> Editorial Nits:
> -------------------
> - References: authid-body and cc-transfer need upversioning.

Hmm - I'm generating this using the xmlrefs stuff from xml2rfc and
I _did_ update my copy of that content before building this doc. 
Something is broken. I'll fix it when I cut the version that pulls
out the "changes since" section.

I failed to respond to the following two points on list. This was not
intentional, and I apologize.

> Other items:
> --------------------------------------
> - Section 2.3: Last paragraph: should this be a MUST (reject an otherwise
> well-formed request with an invalid token)?   Reasonably, one should, but
> perhaps there are users that would still like to be able to decide
> themselves, thus I would suggest this be stated similar to the previous
> paragraph as:

> "The refer target SHOULD reject an otherwise well-formed request with an
> invalid Referred-By token (see Section 4) with a 429 error response. If
the
> agent chooses to proceed with the request and provides any information
from
> the Referred-By header to its user as part of processing the request, it
> MUST notify the user that the information was determined to be invalid." 
> 
> My reasoning is that it just seems that if an optional parm is mucked up
(in
> general or from a security perspective), then following the adage of being
> generous in what you accept ...that whether to accept the request,
provided
> that it is warned that it's bad,  should still be up to the user.  This
also
> seems consistent with the MAYs in the previous 2 paragraphs. I do
understand
> the reasoning that you'd want to let the Referrer know and that by
allowing
> the request, you're actually bypassing the security put in place to keep
the
> bad guys from mucking with the messages, but again since it's optional, it
> just seems that you can't make it stronger than a SHOULD. 

This situation for this clause is different from the preceding MAYs.

Here, you _know_ you've got something invalid, where the two earlier
paragraphs deal with the case that you have data that you have no
indication of its integrity one way or another.

If the token is invalid, something's gone wrong and it will be
sufficiently hard to tell whether that's due to attack or implementation
error, that the action needs to be to return an error.

Diving into this just a little more deeply:

Well, you've got two classes of possible "invalidity".

1) The signature is not valid. Here, you have now way to know what
   got mucked with. No way to know if the failure is related to an
   optional parameter or something important. Clearly, this condition 
   warrants only rejection.

2) The signature is valid, but the contents of the token don't
   match the request. You or I might be able to inspect the message
   and make an educated decision about the safety of accepting
   the request. Ordinary people won't have that skill. (Ordinary
   devices currently aren't making it easy for me to get the
   information I would need to make that educated decision anyhow).
   So, again, rejection is warranted.

[MB]: I do understand your point, but I'm still wondering whether it
shouldn't be a SHOULD or perhaps RECOMMENDED rather than a MUST (to allow
for devices that might be able to provide a different level of user
interface for that scenario).  I do realize that the user interface should
not require a high level of technical knowledge, but I still think that a
specific implementation shouldn't be limited by the protocol (eg there may
be an "Advanced User" mode whereby this can be appropriately handled and a
user wants to know when they're being "attacked").  

> 
> - Section 4.1:  2nd paragraph suggesting that "A target SHOULD verify the
> request...".  I don't think this is useful since retargeting makes this
> check not meaningful.  UNLESS, of course, you're using History-Info.  With
> History-Info, you could verify that the Refer-To matches one of the
> Targeted-to-URIs (and of course, this implies that this information has
all
> been sent securely, not mucked with by the proxies, etc.). 

There is a lot of information present than just the Request-URI that
can be validated. The method, requested end-to-end headers, etc.

[MB]: I agree. I think my point initially arose because I read that Note as
directly coupled with the first, so it might be useful to add a 2nd sentence
between the current two and RECOMMEND some of the comparisons that should be
done to verify the identity, since you cannot rely on the Request-URI.

> 
> Regards,
> Mary.  
> 
> -----Original Message-----
> From: Rohan Mahy [mailto:[e-mail]]
> Sent: Thursday, June 19, 2003 1:39 PM
> To: [e-mail]
> Cc: [e-mail]; Jon Peterson; Dean Willis; 'Robert Sparks'
> Subject: [Sip] WGLC for referred-by
> 
> 
> Hello Everyone,
> 
> I would like to begin a Working Group last call on:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-02.txt
> 
> WGLC will end on Friday July 18th.
> 
> thanks,
> -rohan
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip