Re: [Sip] Followup on WGLC for draft-ietf-sip-e2m-sec-01.txt

[Hans Persson <[e-mail]>]

tor 2006-03-09 klockan 15:32 -0600 skrev Dean Willis:

> > http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-01.txt
>
> Okay, kids. I haven't seen a single response to this WGLC, and Kumiko  
> tells me she hasn't either. This means one of several things:

In my case, the reason is

> 1) You ate so much over the holidays that you forgot all about it.

Since the holidays are a bit off by now (even though we still have the
slow... :-/ ), I read through the draft just now. I'm not very good with
encryption and such, so therefore I'm changing my reason to

> 3) We just haven't thought about it enough to have an opinion.

I'll try to give it some more thought, but this'll probably be an RFC
before something useful comes out of that...

While reading the draft, I did various minor nit changes (mostly, if not
entirely, editorial). I'm attaching them in the form of a diff below (I
don't have time to convert them to a more friendly format right now).

Hopefully, someone else has a more educated opinion about the workings
of the draft than I do.

Until then, ではまた。

Hans



--- draft-ietf-sip-e2m-sec-01.txt	2005-10-31 16:18:19.000000000 +0100
+++ draft-ietf-sip-e2m-sec-01-hp.txt	2006-03-10 16:58:18.273167367 +0100
@@ -136,7 +136,7 @@
    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 mechanisms consist of generating S/MIME-secured
+   messages.  The mechanisms consist of generating an S/MIME-secured
    message body and indicating the target message body for a proxy
    server selected by the UA.  In addition, this document describes a
    mechanism for a UA to discover the intermediary which needs to
@@ -176,7 +176,7 @@
    of each recipient or the shared keys between the UA and each
    recipient.
 
-   If the encrypted data is destined for one or more than one proxy
+   If the encrypted data is destined for one or more proxy
    server(s), the recipient list MUST contain only the proxy server(s).
    If the same encrypted data is shared with the user agent server
(UAS)
    and proxy servers, the recipient list (the "recipientInfos" field)
@@ -200,7 +200,7 @@
 
         Figure 1: An Example Structure of EnvelopedData for Sharing
 
-   If there are multiple pieces encrypted data destined for each proxy
+   If there are multiple pieces of encrypted data destined for each
proxy
    server, the recipient list in each piece of encrypted data MUST
    contain the relevant proxy server.  If a piece of encrypted data is
    destined for a proxy server and another piece of encrypted data for
@@ -260,7 +260,7 @@
 
       Note: There are other mechanisms which can provide data
integrity,
       such as S/MIME CMS AuthenticatedData, which requires that a UA
-      obtains the credential of the recipient, that is a proxy server,
+      obtains the credentials of the recipient, that is a proxy server,
       in advance.  However, this is not used in [1] and require a
       mechanism to securely transmit the credential from the proxy
       server to the UA.  Thus, this document does not describe the use
@@ -299,7 +299,7 @@
    other hand, the indication for signed data is usually useless
because
    any entities can verify the signed data and the signed data is
always
    protecting the whole message body.  Therefore, a UA is NOT
-   RECOMMENDED to set a indication using the "Proxy-Required-Body"
+   RECOMMENDED to set an indication using the "Proxy-Required-Body"
    header for signed data.
 
       Note: There were three other options to label a body: a new SIP
@@ -319,7 +319,7 @@
    indication.  Even if a UA indicates a proxy server that is not along
    the signaling path, or that doesn't support this mechanism, the UA
    doesn't have any error response.  The UA can only acknowledge the
-   proxy server's behavior or compliance through the service which
+   proxy server's behavior or compliance through that the service which
    requires proxy server's inspection of the message body fails.
 
       Note: Is "Proxy-Required-Body" an appropriate name?  "Proxy-
@@ -349,9 +349,9 @@
    servers.  One is by receiving an error response from the proxy
    servers.  The error response shows the violation of the policies,
    then a UAC can learn them.  However, it is not applicable to the UAS
-   because there is no way to react a response message.  Alternatively,
-   a policy server can provide a UAC and the UAS a package mentioning
-   proxy's policy as described in [11].  When a proxy server needs to
+   because there is no way to react to a response message.
Alternatively,
+   a policy server can provide a UAC and the UAS with a package
mentioning
+   the proxy's policy as described in [11].  When a proxy server needs
to
    inspect the message body contained in the response, it needs to
learn
    the policies from a policy server before sending the response.  This
    document covers only the former.
@@ -359,10 +359,10 @@
 4.1  Discovery with Error Responses
 
    When the proxy server receives a request that can not be accepted
due
-   to its condition, the proxy server MUST reject with an error
+   to its condition, the proxy server MUST reject it with an error
    response.  If the request contains encrypted data and the proxy
    server cannot view the message body that has to be viewed in order
to
-   proceed, the proxy server MUST reject with a new error response, 496
+   proceed, the proxy server MUST reject the request with a new error
response, 496
    (Proxy Indecipherable).  The proxy's public key certificate and
    Content-Type to be viewed SHOULD be contained with the error
    response.  The proxy's public key certificate SHOULD be set as an
@@ -375,14 +375,14 @@
    target Content-Type that the proxy server wants to view in the
    Warning header, if they exist.
 
-      Until the previous version, 493 (Undecipherable) error response
+      Until the previous version, the 493 (Undecipherable) error
response
       had been proposed to be shared by the UAS and a proxy server.
       However, the reactions requesting the UAC are different, as
       pointed out in the SIP mailing list.  On receiving the error
       response from the UAS, the UAC should totally renew
-      "recipientInfos" by encrypted CEK with the KEK obtained from the
+      "recipientInfos" by encrypting(?) the CEK with the KEK obtained
from the
       error response.  On the other hand, on receiving the error
-      response from the proxy server, the UAC first should analyze the
+      response from the proxy server, the UAC should first analyze the
       feature of the message body and the proxy-requiring Content-Type
       obtained from the Warning header.  If the UAC decides to share
the
 
@@ -394,7 +394,7 @@
 
 
       message body with the UAS and the proxy server, the UAC will
reuse
-      the "recipientInfos" of the previous request and add encrypted
CEK
+      the "recipientInfos" of the previous request and add an encrypted
CEK
       with the proxy's KEK obtained from the error response to it.  If
       the UAC decides to send two parts of the message body separately,
       the UAC will add the EnvelopedData that contains a message body
@@ -403,7 +403,7 @@
 
    If a digital signature is not attached to the message body in the
    request and the proxy server requires the integrity check, the proxy
-   server MUST reject with a 495 (Signature Required) error response.
+   server MUST reject the request with a 495 (Signature Required) error
response.
    This error response does not contain Content-Type that is required
    signature, since the attached signature to the whole body is always
    required.  The proxy server MAY attach the signature to a "message/
@@ -418,7 +418,7 @@
    server SHOULD send an error response only for requesting disclosure.
    After receiving a request message including encrypted data destined
    for the proxy server, it finds out whether the message has a
-   signature attached and SHOULD send an error response for requesting
+   signature attached and SHOULD send an error response for requesting
a
    signature when the message lacks it.
 
       There are two ways to encrypt and sign data: encrypt data after
@@ -428,8 +428,8 @@
       response requiring the signature for the data prior to the
       encryption, if the encryption is needed.
 
-   This discovery mechanism requires two more message exchange for an
-   error condition per each proxy server in the signaling path in order
+   This discovery mechanism requires two more message exchanges for an
+   error condition for each proxy server in the signaling path in order
    to establish a session between UAs.  Since this causes a delay in
    session establishment, it is desirable that the UAs learn the
    security policies of the proxy servers in advance.
@@ -464,7 +464,7 @@
 
 5.1  UAC Behavior
 
-   When a UAC (UA #1) sends an INVITE or a MESSAGE request including
+   When a UAC (UA #1) sends an INVITE or a MESSAGE request including an
    encrypted message body for end-to-middle confidentiality, it MUST
    generate S/MIME CMS EnvelopedData, and SHOULD specify the hostname
of
    Proxy #1 and Content-ID of the S/MIME CMS EnvelopedData which is to
@@ -472,8 +472,8 @@
 
    If UA #1 decides to share the message body with the UAS (UA #2) and
    the proxy server (Proxy #1) that requires the inspection of the
-   message body, UA #1 MUST list encrypted CEK with the Proxy #1's KEK
-   and encrypted CEK with the UA #2's KEK at the "recipientInfos" of
the
+   message body, UA #1 MUST list encrypted CEK with Proxy #1's KEK
+   and encrypted CEK with UA #2's KEK in the "recipientInfos" section
of the
    CMS EnvelopedData.  If UA #1 decides to set the message body
    separately, UA #1 MUST structure a "multipart/mixed" body that
    contains two CMS EnvelopedData: one encrypted for UA #2 and another
@@ -485,12 +485,12 @@
    parameter, since the default value is "required" as specified in
[1].
 
       This separate structure is useful when keying materials, such as
-      keys used for Secure RTP (SRTP), are included in the SDP[14], UA
+      keys used for Secure RTP (SRTP), are included in the SDP[14] and
UA
       #1 does not want to show the keying materials to Proxy #1,
       although Proxy #1 needs to view the SDP for the firewall
traversal
       service.
 
-   If UA #1 sends an INVITE request including encrypted the SDP just
for
+   If UA #1 sends an INVITE request including encrypted SDP just for
    end-to-end, being unaware of the service provided by Proxy #1 that
    requires the inspection of the message body, UA #1 will get a 496
    (Proxy Indecipherable) error response with the public key of Proxy
#1
@@ -508,18 +508,18 @@
    496 (Proxy Indecipherable) error response with the public key of
    Proxy #1 and no Warning header requiring Content-Type.
 
-   By obtaining the error response, UA #1 acknowledges that Proxy #1
+   When receiving the error response, UA #1 learns that Proxy #1
    requires the disclosure of a partial or the whole message body.  If
    UA #1 decides to meet the requirement of Proxy #1, UA #1 generates
    CMS EnvelopedData and sets the "Proxy-Required-Body" header as
-   described above.  If the UA #1 decides to share the message body
with
-   the UA #2 and Proxy #1, UA #1 MUST update the "recipientInfos" of
the
+   described above.  If UA #1 decides to share the message body with
+   UA #2 and Proxy #1, UA #1 MUST update the "recipientInfos" of the
    previous request by adding encrypted CEK with Proxy #1's KEK
obtained
    from the error response.  If UA #1 decides to set the message body
    separately for Proxy #1, UA #1 MUST structure a "multipart/mixed"
    body by adding the CMS EnvelopedData for Proxy #1.
 
-   When UA #1 sends a request message of which message body needs end-
+   When UA #1 sends a request message where the message body needs end-
    to-middle integrity, it SHOULD generate S/MIME CMS SignedData to
    attach a digital signature.  UA #1 MAY specify the hostname of Proxy
    #1 and Content-ID of the CMS SignedData to be validated by Proxy #1
@@ -540,9 +540,9 @@
    confidentiality and integrity for the message body, it SHOULD first
    generate S/MIME CME SignedData to attach the digital signature for
    the content, and then generate S/MIME EnvelopedData to encrypt the
-   CMS SignedData.  UA#1 SHOULD specify the hostname of Proxy#1 and the
+   CMS SignedData.  UA #1 SHOULD specify the hostname of Proxy #1 and
the
    Content-ID of the CMS EnvelopedData destined for Proxy #1 in the
-   "Proxy-Required-Body".  UA#1 also MAY specify the Content-ID of the
+   "Proxy-Required-Body".  UA #1 MAY also specify the Content-ID of the
    CMS SignedData following the Content-ID of the CMS EnvelopedData in
    the header.
 
@@ -551,7 +551,7 @@
       outside is easily detachable.
 
    If UA #1 needs the confidentiality of the SDP, and UA #1 knows that
-   Proxy #1 needs to view the both SDPs in an INVITE request and a 200
+   Proxy #1 needs to view both the SDPs in an INVITE request and a 200
    OK response for the firewall traversal service, UA #1 MAY use the
CEK
 
 
@@ -619,12 +619,12 @@
 
    requests or responses.  By checking the "Proxy-Required-Body" header
    in the receiving request, UA #2 MAY know the destination (Proxy #1)
-   and the Content-Type to be disclosed.  If UA #2 accept the
+   and the Content-Type to be disclosed.  If UA #2 accepts the
    disclosure, it MAY keep the CEK with the identifier specified in the
    "unprotectedAttrs" attribute.  If UA #2 receives an INVITE message
    specifying the CEK reuse, UA #2 MAY reuse the CEK (CEK #1) to
encrypt
    a new CEK (CEK #2) for encrypting the SDP in a 200 OK response as
-   showed in Figure 5
+   showed in Figure 5:
 
    +-------------------------------------------------------------+
    | The "encryptedContentInfo" field                            |
@@ -642,8 +642,8 @@
    Even when UA #2 receives a request that does not use S/MIME, UA #2
    sometimes needs end-to-middle confidentiality for the message body
in
    a response, for example, the SDP offer/answer in a 200 response and
-   ACK request.  The behavior for generating S/MIME CMS data is the
same
-   as how UA #1 operates as described in Section 5.1, while the
behavior
+   ACK request.  The behavior for generating S/MIME CMS data is similar
+   to how UA #1 operates as described in Section 5.1, while the
behavior
    for discovering the security policies of Proxy #1 can not be not
    supported.
 
@@ -651,12 +651,12 @@
 
    When the proxy server supporting this mechanism for its own security
    policies (Proxy #1) receives a message, it MUST inspect the "Proxy-
-   Required-Body" header(s).  If the header includes the Proxy #1's
+   Required-Body" header(s).  If the header includes Proxy #1's
    hostname, Proxy #1 MUST inspect the body indicated by the
    "content-id" parameter.  If multiple "content-id" parameters exist
in
    the header, Proxy #1 MUST inspect the bodies in order.  Even if the
-   header does not include the Proxy #1's hostname, nor the header
-   exists, Proxy #1 MAY view the message body following its own
security
+   header does not include Proxy #1's hostname or the header doesn't
+   exist, Proxy #1 MAY view the message body following its own security
    policies.
 
    When the indicated body is CMS EnvelopedData, Proxy #1 MUST try to
@@ -664,7 +664,7 @@
    data for Proxy #1, Proxy #1 will succeed in obtaining the CEK to
    decrypt the encrypted content at the "encryptedContentInfo" field.
 
-   If Proxy #1 fails to decrypt the message body that is required to
+   If Proxy #1 fails to decrypt the message body that it is required to
 
 
 
@@ -686,15 +686,18 @@
       information only for UA #2, if UA #1 sets different port
       information for UA #2 and Proxy #1 separately on purpose or not.
       The firewall traversal service for UA #1 will fail.  However,
-      Proxy #1 care about the information even only for UA #2, if Proxy
+      Proxy #1 cares about the information even only for UA #2, if
Proxy
       #1 provides a call admission control using codec information in
       SDP.  Proxy #1 needs to view the SDP destined not only for
itself,
       but also the SDP destined for UA #2 in order to confirm that both
-      of the codec information are the same.  In other words, Proxy #1
+      sets of codec information are the same.  In other words, Proxy #1
       needs to police if UA #1 does not attempt to use a different
codec
       that requires more bandwidth.  After all, Proxy #1 will require
       disclosure of all the message body by setting no Warning header
       requiring Content-Type.
+      [If the above is supposed to be just an example, it sounds
+      rather normative. If it really is part of the spec, why does
+      this spec mandate codec policing?]
 
    If Proxy #1 succeeds in this decryption, it MAY inspect the
    "unprotectedAttrs" field of the CMS EnvelopedData body.  If the
@@ -710,11 +713,11 @@
    a 403 (Forbidden) response if the message is a request, otherwise
any
    existing dialog MAY be terminated.
 
-   When Proxy #1 needs validate the data integrity of the content but
+   When Proxy #1 needs to validate the data integrity of the content
but
    the indicated body does not contain CMS SignedData body, Proxy #1
    MUST respond with a 495 (Signature Required) response if the message
    is a request, otherwise any existing dialog MAY be terminated.  A
495
-   response contain no Warning header requiring Content-Type to be
+   response contains no Warning header requiring Content-Type to be
    attached a signature, since the signature of the whole body is
always
    required, when the data integrity is required.
 
@@ -730,12 +733,12 @@
 
 
    to decrypt the CMS EnvelopedData.  If the decryption fails, Proxy #1
-   MUST respond with 496 (Proxy Indecipherable) that contains its own
+   MUST respond with a 496 (Proxy Indecipherable) response that
contains its own
    public key and no Warning header requiring a specific Content-Type.
    After getting decipherable data, Proxy #1 inspects the content and
-   validate the signature, if it exists.  If the signature for the
whole
-   body does not exist, Proxy #1 MUST respond with 495 (Signature
-   Required) that contains no Warning header requiring a specific
+   validates the signature, if it exists.  If the signature for the
whole
+   body does not exist, Proxy #1 MUST respond with a 495 (Signature
+   Required) response that contains no Warning header requiring a
specific
    Content-Type.  If the encrypted data is attached with the signature
    outside, Proxy #1 MAY first validate the signature, instead of
    checking the existence of the signature inside.
@@ -745,7 +748,7 @@
 
       When a provider operating Proxy #1 does not allow any information
       related to its security policies to be revealed to Proxy #2
-      serving UA #2, Proxy #1 MAY deletes the "Proxy-Required-Body"
+      serving UA #2, Proxy #1 MAY delete the "Proxy-Required-Body"
       header.  However, when UA #1 sends the request to Proxy #1 via a
       proxy server operated by another provider, there is no way to
       conceal the header from the other proxy servers.
@@ -791,7 +794,7 @@
       The "where" column gives the request and response types in which
       the header field can be used.  The values in the "where" column
       are as follows:
-      *  R: The header field may appear in requests
+      *  R: The header field may appear in requests.
       *  100-699: A numeral range indicates response codes with which
          the header field can be used.
       The "proxy" column gives the operations a proxy may perform on
the
@@ -813,7 +816,7 @@
 
    In the following example, a UAC needs message content in a MESSAGE
    request to be confidential and it allows a proxy server to view the
-   message body.  Even though the Content-Length has no digit, the
+   message body.  Even though the Content-Length field has no numeric
value, the
    appropriate length is to be set.  In the example message below, the
    text with the box of asterisks ("*") is encrypted:
 
@@ -904,7 +907,7 @@
    SIP/2.0 496 Proxy Indeciperable
    Warning: 380 ss1.atlanta.example.com "Required to view 'text/plain'"
    Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
-   ;received=192.0.2.101
+       ;received=192.0.2.101
    From: Alice <sip:[e-mail]>;tag=9fxced76sl
    To: Bob <sip:[e-mail]>;tag=8321234356
    Call-ID: [e-mail]
@@ -995,7 +998,7 @@
    ******************************************************************
 
 
-   When the proxy server successfully views the SDP, and the UAS
+   When the proxy server successfully views the SDP, the UAS
    responds with a 200 OK.  The 200 OK is to be encrypted as follows:
 
 
@@ -1048,7 +1051,7 @@
 
    In the following example, a UA needs the integrity of message
content
    in a MESSAGE request to be validated by a proxy server before it
-   views message content.  Even though the Content-Length has no digit,
+   views message content.  Even though the Content-Length field has no
numerical value,
    the appropriate length is to be set.
 
 
@@ -1099,7 +1102,7 @@
 
 
    If the proxy server successfully validates the integrity of the
-   message body, the UAC normally receives a 200 OK from the UAS.
+   message body, the UAC receives a 200 OK from the UAS as normal.
    However, if a proxy server does not receive a signature for the
whole
    message body, the UAC receives a 495 (Signature Required) error
    response from the proxy server, as follows:
@@ -1127,7 +1130,7 @@
 
    SIP/2.0 495 Signature Required
    Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
-   ;received=192.0.2.101
+       ;received=192.0.2.101
    From: Alice <sip:[e-mail]>;tag=9fxced76sl
    To: Bob <sip:[e-mail]>;tag=8321234356
    Call-ID: [e-mail]
@@ -1158,7 +1161,7 @@
    to, or the domain where the recipients connect to.  Additionally, a
    UA MUST verify the identifier of the proxy server and chains to a
    trusted certificate authority of the public key certificate.  If a
UA
-   fails to check the correspondence and/or the verification, the
public
+   can't check the correspondence and/or the verification, the public
    key certificate is presumably replaced or forged by a malicious
user.
 
 8.2  Tampering with a Message Body
@@ -1208,8 +1211,8 @@
 9.  IANA Considerations
 
    This document defines a new SIP header, "Proxy-Required-Body", of
-   which the syntax is shown in Section 6.  This document also defines
a
-   new SIP response-code, 495 "Signature Required", 496 "Proxy
+   which the syntax is shown in Section 6.  This document also defines
two
+   new SIP response-codes: 495 "Signature Required" and 496 "Proxy
    Indecipherable", and a new Warn-code, 380 "Required to view Content-
    Type", as described in Section 4.
 


--
Hans Persson <[e-mail]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  [phone]   http://www.ingate.com/

Private: <[e-mail]>  http://www.lysator.liu.se/~unicorn/



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip