Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01

[Bernard Aboba <[e-mail]>]

Thanks. You might mention the Allow: header, as well as potential advice for avoiding errors (e.g. checking Allow: or Accept: headers, sending OPTIONS, etc.)

> Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01
> From: [e-mail]
> Date: Fri, 8 Jul 2011 14:15:49 +0300
> CC: [e-mail]; [e-mail]
> To: [e-mail]
> 
> I have updated the draft to reflect our discussion. Please find the most recent version here:
> http://www.tschofenig.priv.at/svn/draft-rosen-ecrit-data-only-ea/draft-ietf-ecrit-data-only-ea-02.txt
> 
> I now changed Section 4.1 that talks about the CAP transport: 
> 
> -----
> 
> 4.1.  CAP Transport
> 
>    Since alerts structured via CAP require a "push" medium.  The
>    following SIP requests MAY carry the CAP payload defined in this
>    document: INVITE [RFC3261], UPDATE [RFC3311], MESSAGE [RFC3428], INFO
>    [RFC6086], NOTIFY [RFC3265], and PUBLISH [RFC3903].  The MIME type is
>    set to 'application/cap+xml'.
> 
>    If the server does not support the functionality required to fulfill
>    the request then a 501 Not Implemented MUST be returned by RFC 3261
>    [RFC3261].  This is the appropriate response when a UAS does not
>    recognize the request method and is not capable of supporting it for
>    any user.
> 
>    The 415 Unsupported Media Type error MUST be returned by RFC 3261
>    [RFC3261] if the server is refusing to service the request because
>    the message body of the request is in a format not supported by the
>    server for the requested method.  The server MUST return a list of
>    acceptable formats using the Accept, Accept-Encoding, or Accept-
>    Language header field, depending on the specific problem with the
>    content.
> 
> -----
> 
> Ciao
> Hannes
> 
> On Jul 8, 2011, at 10:50 AM, Hannes Tschofenig wrote:
> 
> > Hi Bernard, 
> > 
> > On Jul 8, 2011, at 2:49 AM, Bernard Aboba wrote:
> > 
> >> Hannes said:
> >> 
> >> The question is also whether we need to restrict the way a CAP payload is sent to a recipient. 
> >> One could argue that it does not really matter whether it is an INVITE, a MESSAGE, or a PUBLISH. 
> >> Which one is best depends on a specific environment. 
> >> 
> >> But you seem to be arguing that we should rather stick with the INVITE instead of using MESSAGE. 
> >> This would at least allow us to get the message understood by every SIP device. 
> > 
> >> [BA] I have no problem with including CAP in MESSAGE.  My major concern was how to ensure interoperability and potential
> >> problems that could delay emergency calls. 
> > 
> > Your suggestion to use INVITE seemed to be interesting but after further thinking about it I am not sure whether the perceived level of interoperability is worth sticking only with an INVITE. If the recipient does not understand the CAP payload (and only the INVITE itself) then there is still no interoperability. 
> > 
> > As such, I believe I have to put text in there regarding error messages and the core SIP spec already provides them, namely 
> > * 501 Not Implemented, and 
> > * 415 Unsupported Media Type
> > 
> > I am still thinking whether we should allow the CAP payload to be used in an  INVITE, a MESSAGE, an a PUBLISH.
> > 
> >> 
> >> This is just an example. Using TCP indeed makes sense for XML-based payloads. 
> >> I don't think we want to mandate that TCP is mandatory-to-use. 
> >> 
> >> [BA] I agree that we don't want to mandate use.  But we are talking about emergency calls, so making a recommendation on how to avoid problems is probably a good idea. 
> >> 
> >> I assume that the device that issues the alert is actually an IP-based device. 
> >> For me the story begins with the first IP device. 
> > 
> >> 
> >> [BA] My problem with signatures is in emergency contexts is the cost and value of validating them.    In ATOCA there may
> >> be a model for this (e.g. government signs the CAP), but in a device scenario, it's not easy to figure out how a PSAP would
> >> validate the signature or what value it would have. 
> > 
> > I agree with you that most deployments will in their judgements about the security threats conclude that they do not need to additionally sign the CAP message and instead rely on the SIP security mechanisms. That's my assumption. Still, the security consideration section lays out the options. 
> > 
> > 
> >> 
> >> With SIP Identity the identity header is either added by the end point (unlikely) or by the outbound proxy. 
> >> If it is added by the outbound proxy then there has to be TLS between the end point and the outbound proxy. 
> >> This would provide proper protection of the message exchange and would fulfill our purpose here. Wouldn't you say so? 
> >> 
> >> [BA] TLS is fine with me -- but it solves a different problem than RFC 4474.
> > 
> > In the typical use case of SIP Identity (at least as envisioned in the specification) the identity assertion is added by the Authentication service (e.g. the outbound proxy) and there still has to be security provided from the end host to that Authentication Service. This may likely come in form of TLS since otherwise the identity assurance is of little value if the adversary is sitting somewhere along that path. 
> > 
> >> 
> >> True. There is the SIP identity of the sender, the field in the CAP message (sender field), and then there is cryptographic material in case of a signature that will have some identity information associated with it. 
> >> Currently, the draft says that we should set the sender field of the CAP message to the value of the sender of the SIP message. Useful to set to two equal?
> >> 
> >> [BA] That is useful if the CAP sender and SIP sender are actually the same.  If not, then the CAP sender field should reflect who composed the CAP. 
> >> 
> > 
> > I put text into the draft already about the case where the two are different. 
> > 
> >> I am OK with not focusing on security threats as the document currently does, but instead focus on the solutions. 
> >> Using the terminology from the ATOCA requirements document maybe it is better to talk about 
> >> 
> >> 1) Verification of the alert originator (this is the SIP stuff) 
> >> 2) Verification of the alert author (this is the alert stuff)
> >> 3) Integrity of alerts in transit (the TLS)
> >> 
> >> OK for you? 
> >> 
> >> 
> >> [BA] Yes, that is a better approach.
> >> 
> > 
> > I proposed text already that follows this type of structure - although not with sub-section headings. 
> > 
> > Ciao
> > Hannes
> > 
> >> _______________________________________________
> >> Ecrit mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> > 
>