[Gen-art] RE: Gen-art review of draft-ietf-sip-e2m-sec-05.txt

["DRAGE, Keith \(Keith\)" <[e-mail]>]

To respond to one point (2nd para of your summary), the IANA registration requirements for SIP headers, response codes, option-tags were updated by RFC 3427, and it is that document which requires a standards track item (through the SIP WG).

Regards

Keith

> -----Original Message-----
> From: Elwyn Davies [mailto:[e-mail]] 
> Sent: Monday, May 21, 2007 12:59 PM
> To: General Area Review Team
> Cc: Mary Barnes; [e-mail]; 
> [e-mail]; Jon Peterson; Cullen 
> Jennings; [e-mail]
> Subject: Gen-art review of draft-ietf-sip-e2m-sec-05.txt
> 
> I have been selected as the General Area Review Team 
> (Gen-ART) reviewer for this draft (for background on Gen-ART, 
> please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call 
> comments you may receive. Apologies for the late arrival of 
> these comments.
> 
> 
> Document: draft-ietf-sip-e2m-sec-05.txt
> Reviewer: Elwyn Davies
> Review Date:  18 May 2005
> IETF LC End Date: 14 May 2005
> IESG Telechat date: (if known) -
> 
> Summary:
> I think this document needs a fair bit of work before it is 
> ready to go to the IESG.
> 
> The request to publish as PS to facilitate IANA registration 
> rather than experimental (as merited by the content) appears 
> to be spurious.  AFAICS RFC 3261 only requires IETF consensus 
> through an RFC of some suitable kind, not necessarily 
> standards track.  The document should be published as experimental.
> 
> Although this proposed protocol is to be experimental, I 
> believe that the specification as it stands is not 
> sufficiently clear to be able to generate a well-defined 
> result, let alone interoperable implementations.  At least 
> part of the problem is linguistic:  there are parts of the 
> document that are difficult to decode and the document would 
> benefit from a co-author/editor with greater English language 
> skills.  I have flagged some (but not all) of these places below.
> 
> Apart from issues of document clarity, I think there are 
> several issues that need to be clarified:
> - Handling integrity and/or confidentiality:  The 
> introduction is less than clear that the protocol offers 
> options for integrity alone and combined with 
> confidentiality.  I would like to see a much clearer 
> statement of what can be achieved and the variants that can 
> apply to different proxies etc. up front in the introduction 
> and then carried through the document.
> - Clearer statements on what is protected by integrity 
> (always the whole message?) and confidentiality (potentially 
> different parts depending on proxy destination).  Some 
> diagrams (or tables) showing the *complete* sip message with 
> the added e2m security pieces indicating the total message 
> structure and what is protected in each case.
> - Several pieces (especially around integrity) offer multiple 
> options for ways of doing things.  Whilst this is an 
> experimental protocol, and hence some flexibility is 
> desirable, I think there may be too many options - maybe this 
> will get reduced after experiment but it would be good to say 
> this or alternatively to choose one option now.  I am also 
> not sure, particularly as regards carrying integrity 
> information in SIP identity, that the recipient is able to 
> determine what has been done by the sender in well-defined 
> way.  There appeared to be a certain amount of hand-waving 
> about this and the identity case is not mentioned in the 
> detailed descriptions of behaviour.
> - The protocol allows for using either pre-shared keys or 
> exchanging certificates.  I think there is an issue in the 
> case where a pre-shared key is used and, for whatever reason, 
> the proxy is unable to decipher the results.  The 
> specification expects to be able to send back a certificate 
> with a key that the sender can use, but this is either not 
> possible (if pre-shared keys are the only thing the proxy 
> has) or may have some security issues if the proxy is allowed 
> to substitute keys in this way.  Basically, the two cases get 
> intertwined which doesn't seem desirable.
> 
> There are a few more detailed points below.
> 
> 
> Comments:
> Abstract:
> The proposed status is PS although the second para of the 
> abstract admits that the protocol is experimental.  This is 
> justified because of the alleged need to have a standards 
> track document for IANA registration.  AFAICS from the IANA 
> web site and RFC3261, this is incorrect.  Registration 
> requires IETF concensus manifested by means of a published 
> RFC (presumably of a type that submits to IETF Last Call.. 
> like this one). I see no reason why this should not be 
> published as experimental to correctly reflect the status of 
> the content.
> 
> s1, para 2: s/consists of/may require some or all of/
> 
> s1, para 4: 'The proposed mechanisms are based on S/MIME [3], 
> since the major
>    requirement is to have little impact on standardized end-to-end
>    security mechanisms defined in [1], the way of handling 
> S/MIME-secure
>    messages.'  The last part of this does not make sense.  
> Maybe s/the way of handling/which already uses/?
> 
> s2.1, para 1: Expand CMS acronym.
> 
> s2.1, para 3:  The MUSTs in this paragraph are pointless and 
> slightly confusing.  Only the source UA knows which proxies 
> and UAS are targeted, so a recipient cannot do any checks to 
> verify that what is there satisfies the MUST.  All that is 
> being is stated is that it is a good thing if the list 
> contains exactly the intended recipients and the relevant keys.
> 
> s2.1, Figures 1 and 2 titles: s/for Sharing/to be Shared/
> 
> 
> s2.2, para 1: 'Generating the
>    signature requires the generator, i.e., the UA, has its own public
>    and private key pair that the UA is not required to have.' 
>  This sentence appears to contain contradictory statements - 
> the UA as a generator has a key pair that it is not required 
> to have.  Is this supposed to mean that it needs an 
> additional key pair that it is not otherwise required to 
> have?  I am confused.
> 
> s2.3: 'encrypt the message': this is is unclear.  To avoid 
> confusion it would help to place the statement from s3, para 
> 2 that the signature always applies to the whole SIP message 
> body here as well. 
> 
> s2.3, note: Can the UA know that the proxy server will only 
> accept messages with SIP identity attached? It is a bit messy 
> if this only happens if the UA only discovers this as a 
> result of an error message.  I am not sure this is 
> covered/discussed later.
> 
> s2.2/2.3: Is there really need for all the alternatives here? 
> It is also not clear to me how the recipient knows which 
> alternative was chosen by the UA.  Is this some flag in the 
> EnvelopedData or elsewhere in the SIP header?  I guess that 
> in the integrity only case the the presence or otherwise of 
> the SignedData flags this.  If the data is encrypted it is 
> not so clear.
> 
> s3, para 1: s/A UA need/A UA needs/
> 
> s3:  It is not clear that the optional inclusion of the 
> 'Proxy-Inspect-Body' in the integrity check case serves any 
> useful purpose. It appears that the specification and code 
> would simpler if it was specifically omitted if there is no 
> encryption to flag.  The content in this case is specifically 
> said to be of little (no) value in this case.  Proxies can 
> use the presence or otherwise of the SignedData element to 
> determine their action (although the SIP identity case is 
> less clear to me).
> 
> s3, para 2: s/singed/signed/ 
> 
> s3, para 3: s/next/subsequently/  (I assume there may be more 
> than one inner body so only one of them could be 'next').
> 
> s3.last para: Could do with a rewrite to better express the intention.
> 
> s4: s/proxy required message body/Proxy Required Message 
> Body/ (2 places - the second one could just use the acronym).
> 
> s4.1: 'The proxy's public key certificate SHOULD be set as an 
> "application/pkix-cert"...': This isn't a SHOULD.  If the 
> cert is present then it has to be appropriately encoded and 
> this is how it would be done. Presumably if there were other 
> appropriate encoding for a cert then they could be used and 
> the UA would be able to know that it had a cert.
> 
> s4.1, para 8 (starting 'Until the previous version...'):  It 
> is unclear if this paragraph contains normative text or is 
> just commentary.  If just commentary, it might be better 
> shifted either to the changelog or an appendix if it is 
> deemed to be of continuing value.
> 
> s4.1, para 9: ss2 and 3 appear to say that the signature is 
> *always* for the whole message. The second sentence appears 
> to imply that the signature could be for a part rather than 
> the whole ('just to the whole body').  Is this an artifact of 
> some previous change or just bad english?
> 
> s4.1, para 9:  I am unclear how or whether the proxy/UAS can 
> determine if the signature is buried in the SIP identity 
> rather than as a SignedData element.  The text says '.. not 
> attached to the message body' which sounds like it is 
> expecting to see a SignedData element.
> 
> s5: This section does not cover the case(s) where the 
> signature is in the SIP identity field either for clients or servers.
> 
> s5: I think this section needs a bit more structuring to 
> reflect the events that go on (sending/receiving various 
> sorts of messages) explicitly and general state maintenance.
> 
> s5.1, para 2: The discussion of the handling parameter for 
> the EnvelopedData talks about 'Proxy #1'.  This appears to 
> imply some sort of ordering constraint that isn't discussed 
> elsewhere.  This needs clarification.
> 
> s5.1, paras 3 and 6: the term 'acknowledges' is 
> inappropriate. 'Learns' would be better.
> 
> s5.1, para 3:  It would be good to remind readers that the 
> server's KEK may be the servers's public key returned in the 
> certificate with the Warning message if it wasn't preshared.  
> Question:  if the preshared key provokes an error should the 
> client believe that it should use the public key in the 
> certificate?  Is there adequate authentication? - forward ref 
> to s8.1 would help
> 
> s5.1, last para:  I think this makes refs 14 and 15 normative 
> (currently informative)
> 
> 
> 
> 


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art