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)

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf