RE: [Sip] WGLC for referred-by

[Robert Sparks <[e-mail]>]

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.

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

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