Gen-art review of draft-ietf-sip-e2m-sec-05.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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)





_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]