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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf