Subject: Re: [secdir] secdir review of draft-drage-sipping-service-identification-01

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 21 Oct 2008 16:14:00 +0200

I have placed a response to the comments raised in this review (and
other comments received in IETF LC) at:

http://www.softarmor.com/sipping/process/wg-review/reviews/service-id-co
mments.htm

I have made some attempt to address the comments, which may well not
provide the answers you were looking for. I would say that the starting
point for this draft was RFC 3325, and therefore much of the handwaving
obviously came from that document. 

I have marked one of your comments: "To resolve" as I am currently not
sure how to address this. Note that
draft-ietf-sipping-service-identification does address some of these
issues and is referenced from the document.

I will attempt to correct any further comments you care to raise.

Regards

Keith

> -----Original Message-----
> From: Barry Leiba [mailto:[email-masked]] 
> Sent: Sunday, July 15, 2007 8:00 PM
> To: [email-masked]; [email-masked]; DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: secdir review of 
> draft-drage-sipping-service-identification-01
> 
> I have reviewed this document as part of the security 
> directorate's ongoing effort to review all IETF documents 
> being processed by the IESG.  These comments were written 
> primarily for the benefit of the security area directors.  
> Document editors and WG chairs should treat these comments 
> just like any other last call comments.
> 
> (I was actually asked to review the -00 version, but that was 
> replaced by -01 in the meantime.)
> 
> I have to say up front that I'm very unhappy with this 
> document.  It doesn't say what its status is, but I see from 
> the tracker that it's informational, not standards-track.  
> Still, it seems to provide very little information, and waves 
> its hands about too many things.  It also has enough problems 
> with grammar that I'm often not sure what it's trying to say. 
>  The very first sentence of the introduction, for example:
> 
>    This document describes private extensions to the Session 
> Initiation
>    Protocol (SIP) that enable a network of trusted SIP 
> servers to assert
>    the service and for users entitled to that service.
> 
> I can't parse that sentence, and I don't know what it means 
> to say.  Similarly for the beginning of section 4.2:
> 
>    The P-Preferred-Service header field is used from a user agent to a
>    trusted proxy to carry the preferred service of the user 
> sending the
>    SIP message wishes to be used for the P-Asserted-Service 
> field value
>    that the trusted element will insert.
> 
> It's hard to decide on the technical content of a document 
> when there are what seem to be key bits that aren't readable.
> 
> What I *can* understand seems to be missing a lot.  It seems 
> to me that this document is basically defining two new SIP 
> header fields, P-Asserted-Service and P-Preferred-Service.  
> The document is very vague -- necessarily so, it says -- 
> about the actual usage of these fields, and that's the second 
> thing that makes me unhappy with publishing this.  The 
> vagueness results in my not understanding what it is that 
> these fields are used to assert or request, why and when a 
> SIP request would want/need to use these (and when it 
> wouldn't), and what, exactly, happens when they're used.  I 
> can't imagine that an implementor who didn't already know 
> what was going on would get things right based on reading 
> this document.  And my experience with even simple protocol 
> standards is that there are many implementors who get things 
> wrong even when the specs are clearly written -- and SIP is 
> not a simple standard.
> 
> The third thing that bothers me is that the Security 
> Considerations section blows off all considerations, even 
> though there are many references in the document to 
> security-related issues.  Trust domains are talked about 
> often, and there are MUST and MUST NOT requirements for 
> passing around information and credentials.  None of that is 
> brought up as a security consideration.  For example, here's 
> something, in section 5.1.3, that I think has to be discussed 
> in the security considerations section:
> 
>    If a UA is part of the Trust Domain from which it received 
> a request
>    containing a P-Asserted-Service header field, then it can use the
>    value freely but it MUST ensure that it does not forward the
>    information to any element that is not part of the Trust Domain.
> 
> What happens if it does forward this information?  How does 
> it know what elements are part of the trust domain?  Can the 
> composition of the trust domain change over the life of a SIP 
> request/session?  How can a trust domain rely on the actions 
> of a user agent?  What if a malicious user tampers with the 
> user agent, which is, after all, under his control?  How does 
> the trust domain defend itself against that?  Why are 
> security-sensitive itens entrusted to a user agent in the first place?
> 
> There may be reasonable answers to these sorts of questions, 
> but there's nothing at all about them in the security considerations.
> 
> All in all, I think this document needs significant work 
> before it's ready to be published.
> 
> 
> Barry
> 
> --
> Barry Leiba, STSM, Internet Messaging Technology  
> ([email-masked])
> http://www.research.ibm.com/people/l/leiba
> http://www.research.ibm.com/spam
> 
> 
> 

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir