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:[EMAIL PROTECTED] > Sent: Monday, May 21, 2007 12:59 PM > To: General Area Review Team > Cc: Mary Barnes; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; Jon Peterson; Cullen > Jennings; [EMAIL PROTECTED] > 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 [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
