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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jul 2011 19:28:03 +0300

Hi Martin, 

thank you for your feedback. 

On Apr 13, 2011, at 5:20 AM, Thomson, Martin wrote:

> The document is OK, modulo a few comments and nits:
> 
Good to hear that. 

> Comments:
> 
> Section 3, Figure 2: Why does the sensor not perform the route selection itself?  If it doesn't, then this is little different to the first scenario, where proxy == aggregator.

In the ECRIT architecture emergency "call" routing may at various places. These two scenarios are trying to demonstrate these different deployment options. 

>  This text is strange:
> 
>     [...] In case the LoST
>   resolution is done at an emergency services routing proxy rather than
>   at the entity issuing the alert since it may not know the address of
>   the receiver.  

This text reads indeed strange. It should read: 

"
  An emergency services routing proxy (ESRP) may use LoST to determine the next hop proxy to route the alert message to. 
"

> 
> The reason given doesn't make any sense to me.  A proxy might perform routing because the sensor has limited capabilities, but that smells more like the scenario in Figure 1 instead.  Suggest reworking this example to either provide better justification, or to have the sensor do the LoST lookup.

There are many reasons why the sensor may not do the LoST lookup itself but I don't think we need to go into that topic in this document itself. We just work with the existing ECRIT emergency services architecture. 

> 
> Section 4.2: It's unclear what interoperability gain is achieved by constraining the CAP contents in this manner.  In particular, the scope seems like a strange constraint.  
> 

CAP is a specification that defines the semantic of the elements in a very relaxed fashion. For interoperability that's not particularly useful. If we don't care about interoperability we could just say that any human readable text is allowed, such as a Word document. 
Since we don't want that we provide some additional guidance of what makes sense for our use case. 

You mention the scope element. The CAP specification says that it can have the following values (and it is a required element):

“Public” - For general dissemination to unrestricted audiences
“Restricted” - For dissemination only to users with a known operational requirement (see <restriction>, below)
“Private” - For dissemination only to specified addresses (see <address>, below)

From these values alerts issued by sensor's are not public. For restricted there is an additional (optional) element that provides a textual description of the restriction - not very helpful. 
In case of private we may indicate an address of the recipient. We could put the Service URN or the PSAP/ESRP URI there but it does not make sense since we have that information already in another place. So, we omit it altogether. Just passing information around for the fun of it does not strike me as a good idea (also keeping in mind that XML-encoded alerts are already big enough in size). 

> Section 6.1: This seems to advocate the use of XML digital signatures.  That would be a bad idea.  Even CMS is better.  JOES would be better still.

CAP comes with XML digitial signatures. What should I do? 
I agree that JSON would be better and I would be happy to standardize a JSON based encoding of CAP in the IETF, to be honest. 
CMS is not lightweight either. 

I have no good story here. 

> 
> Was "application/cap+xml" already taken?

I don't think so. That would be better. I will switch to cap+xml. 

> 
> Nits:
> 
> The example has a few errors:
> -	It needs to be updated for the latest sipcore-location-conveyance version
> -	The namespace prefix for the usage rules in the PIDF-LO are incorrect
> -	The use of a mac: URI for identifying the device requires the definition of the mac: URI scheme.
> 
OK. Took the example from the latest SIP Location Conveyance document. 

> What is the right case for scope?  I didn't check what the right answer is, but the example and the MUST use different case - one of them is probably wrong.
> 
"Private". 

Fixed. 

> Who is "phrank"? [citation required]
> 
I'll remove it 

> Section 6.3: hanging sentence in the threat description: "In scenario [...]"

Good catch. 

Ciao
Hannes

> 
> --Martin
> 
> On 2011-03-31 at 01:49:46, Marc Linsner wrote:
>> This message starts the Working Group Last Call for draft "Common 
>> Alerting Protocol (CAP) based Data-Only Emergency Alerts using
>> 
>> the Session Initiation Protocol (SIP)
>> 
>> "  (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01).
>> 
>> This draft fulfills the WG milestone:
>> 
>> Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only 
>> Emergency Alerts using the Session Initiation Protocol (SIP)'
>> 
>> Please submit comments to the list by COB on Friday April 15, 2011.
>> 
>> 
>> Thanks,
>> 
>> 
>> -Marc Linsner-
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jul 2011 19:28:10 +0300

Hi James, 

On Apr 13, 2011, at 6:48 AM, Winterbottom, James wrote:

> On the mac URI scheme, we originally had this in the HELD identity extensions but it was suggested in no uncertain terms that this had buckley's chance of getting through. This led us to use an explicit XML entity, though I seem to recall somebody suggesting that we may have been able to do something with UUIDs.

Hmmm. 

When I copied the example from the latest version of SIP location conveyance then I see that it says the same as in the ecrit-data-only-ea draft. 
I believe we need to consistently use something here. 

So, what would you suggest? The HELD identity extension cannot be used here out of the box since this is a completely different specification. In RFC 5491 we had also used the <dm:deviceID>mac:8asd7d7d70cf</dm:deviceID> notation....

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jul 2011 19:45:35 +0300

Hi Shida, 

thank you for your review comments. 

On Apr 20, 2011, at 5:27 AM, Shida Schubert wrote:

> 
> I reviewed the document and followings are some comments/questions. 
> 
>  In general, I am having a hard time understanding the intent of the 
> draft. Is it defining a CAP document composition rule (4.2) for delivering 
> the CAP message from citizen to authority only? OR is it defining a SIP 
> usage to transport CAP message as well? If it's latter I think more should 
> be said about how SIP entities should behave. I understand it is an 
> experimental document but I think we need to clarify the scope of the 
> document somewhat. 

Based on the received feedback the introduction section was enhanced. 
I hope the purpose is now clearer. 

> 
>  1. For scenario 1, I really don't think in reality a sensor will be 
>      implementing a SIP stack simply to support the transport of 
>      CAP message, it just seems like an overkill. I understand how 
>      aggregator to PSAP should be SIP to re-use what is defined 
>      in Phone-BCP and pre-exising infrastructure. May be text can 
>      be added that some other means may be used to deliver a CAP 
>      message from CAP to aggregator.  

Actually, sensors implement IP protocols, and various IETF protocols (including SIP, XMPP, and HTTP). 
No kidding. 

> 
>  2. I am assuming that any SIP device can use MESSAGE to 
>      send CAP to PSAP. If so, some device will be able to handle 
>      call-back and some won't. Do we need to distinguish devices 
>      that will be issuing the MESSAGE to see whether call-back 
>      can be established etc?  (I guess PSAP can look at allow header 
>      to see if the device can accept INVITE etc.)

Interesting comment and aligns nicely with the remark Bernard has made. 
I will post a separate mail about this topic. 

>      
>  3. For both cases, should there be any recommendation on how 
>      sensor should behave in case 200 OK is not received or error 
>      is received from downstream? Again related to the scoping of 
>      the document, this may not be necessary if the main intent is 
>      to recommend CAP document composition rule. 
> 

This aspect relates to the previous question. See also separate mail. 

>  4. If non SIP device is used what should be set in "sender" of CAP? 
>      What if the CAP message is sent by a sensor which doesn't support 
>      SIP and it is the aggregator that acts as the SIP intermediary and 
>      SIP endpoint?
> 
You are saying that you don't like it that the text in the document equates the sender identity of the SIP message with the sender identity in the CAP message. 
Bernard seems to argue in the same direction and maybe we should not make this restriction and say that if the author and the originator are the same then we just copy the SIP sending identity into the CAP sender element. 
OK? 

>  5. Use of P-Asserted-Identity doesn't provide any integrity so I would 
>      take it out of section 6.3.
> 
Input taken. Text will change based on Bernard's suggestion to restructure the security consideration section. 

>  6. Why is RFC3265/RFC3903 a normative reference? I think they 
>      should be in an informative reference as there is no normative text 
>      surrounding their uses. 

Fixed. A bug. 

> 
>  7. Shouldn't RFC3261(SIP)/RFC3428(MESSAGE)/location-conveyance/
>      RFC4119(PIDF-LO) be in a normative reference?
> 
Yes; The are indirectly imported through the PhoneBCP document. I moved the Phone BCP I-D to the normative reference section. 

> 
> **Some nits**
> 
>   Section 6: 
> 
>   OLD ".. this document and the discussion in.."
>   
>   NEW ".. this document and are discussed in.."
> 
OK. Fixed. 

>   Section 6.2
> 
>   OLD "..alerts and reply them at a later time.."
> 
>   NEW "..alerts and replay them at a later time.."
> 
OK. Fixed. 

Ciao
Hannes

> 
> Regards
>   Shida
> 
> On Mar 30, 2011, at 11:49 PM, Marc Linsner wrote:
> 
>> This message starts the Working Group Last Call for draft "Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)"  (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01).
>> 
>> Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)'
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jul 2011 19:28:18 +0300

Hi Bernard, 

thank you for your detailed review and text suggestions. 

On Apr 21, 2011, at 12:55 AM, Bernard Aboba wrote:

> [BA] Overall, I echo Shida's comments about potential additional
> usage scenarios and have a few additional comments about the
> Security Considerations section. 
> 
> Specific comments below:
> 
> Abstract
> 
>    The Common Alerting Protocol (CAP) is a document format for
>    exchanging emergency alerts and public warnings.  CAP is mainly used
>    for conveying alerts and warnings between authorities and from
>    authorities to citizen/individuals.  This document describes how
>    data-only emergency alerts allow devices to issue alerts using the
>    CAP document format.
> 
> [BA] It seems to me that the use of the term "Data-Only" may not be
> appropriate to describe all the potential usage scenarios.   For
> example, might it also not be possible to include CAP within an INVITE?
> Suggestion is that the draft be renamed "CAP Emergency Alerts Using SIP",
> and that the Abstract be changed as follows:
> 
>    The Common Alerting Protocol (CAP) is a document format for
>    exchanging emergency alerts and public warnings.  CAP is mainly used
>    for conveying alerts and warnings between authorities and from
>    authorities to citizen/individuals.  This document describes how
>    the CAP document format can be used to allow devices to issue
>    emergency alerts.
> 
> ----------------------------
> 
I am fine with the suggested text. 

>    Data-only emergency alerts are similar to regular emergency calls in
>    the sense that they require emergency call routing functionality and
>    may even have the same location requirements.  On the other hand, the
>    initial communication interaction will not lead to the establishment
>    of a voice or video channel.
> 
> [BA] There are a number of potential uses for CAP, some of which could not
> be characterized as "Data-only".  For example, CAP could be included in an
> INVITE which also included an SDP offer.  Also an INVITE might be sent
> without CAP and then when a response was received indicating that MESSAGE
> was allowed then a CAP alert could subsequently be sent.  So I wouldn't
> necessarily emphasize the "Data-only" aspect.  Suggested change:
> 
>    Eergency alerts containing data are similar to regular emergency calls in
>    the sense that they require emergency call routing functionality and
>    may even have the same location requirements.  On the other hand, the
>    communication interaction may occur without establishment
>    of a voice or video channel. 
> 
> ----------------------------
> 

Good for me as well. 

>    Based on the deployment experience with non-IP based systems we
>    distinguish between two types of environments, namely (1) data-only
>    emergency alerts that are targeted directly to a recipient
>    responsible for evaluating the alerts and for taking the necessary
>    steps, including triggering an emergency call towards a Public Safety
>    Answering Point (PSAP) and (2) alerts that are targeted to a Service
>    URN as used for regular IP-based emergency calls where the recipient
>    is not known to the originator.  We describe these two cases in more
>    detail in Section 3.
> 
> 
> [BA] The term "emergency call" as opposed to "emergency alert" suggests 
> that the aggregator could potentially convey the CAP message along with 
> establishing non-data channels.  My suggestion is to rewrite as follows:
> 
>    Based on the deployment experience with non-IP based systems, two
>    major deployment scenarios are envisaged:
> 
>    1) Emergency alerts containing only data are targeted to a 
>       recipient responsible for evaluating the next steps, which
>       could include:
> 
>          a. Sending an alert containing only data toward a Public
>             Safety Answering Point (PSAP);
>          b. Establishing an emergency call with a PSAP that could
>             include audio/video as well as data
> 
>    2)  Emergency alerts targeted to a Service URN used for IP-based 
>        emergency calls where the recipient is not known to 
>        the originator.  In this scenario, the alert may contain
>        only data (e.g. MESSAGE) or could be included along with
>        establishment of an audio/video channel (e.g. INVITE)
> 
> We describe these two cases in more detail in Section 3.
> 
Thanks for the improved text proposal. 

> ----------------------------
> 
> Section 3
> 
> There is a basic issue in scenario described in Figure 2, which
> is handling of failure conditions.
> 
> If we assume that the PSAPs do not deploy new capabilities uniformly,
> then the sender may not know beforehand what capabilities the PSAP 
> can support.   For example,  a given PSAP may or may not support MESSAGE,
> may or may not support CAP or PIDF-LO, etc. 
> 
> If at all possible, you want to avoid multiple error-terminated conversations
> between the sender and receiver, consuming precious time during an emergency. 
> 
> This is one argument for "silent call" approaches which utilize a
> "known good" mechanism for initiating an emergency call (e.g. an INVITE),
> then follow up with additional messages once the capabilities of
> the responder are known (e.g. from an Allow: header). 
> 

This is an interesting issue that I will address this issue in a separate mail. 

> ----------------------------
> 
> Section 4.1
> 
>       Alternatively, the SIP PUBLISH mechanism or other SIP messages
>       could be used.  However, the usage of SIP MESSAGE is a simple
>       enough approach from an implementation point of view.
> 
> [BA] I'm not thrilled with using PUBLISH, so I'd remove that but it
> does occur to me that INVITE would make sense. 
> 

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. 

> ----------------------------
> 
> Section 5
> 
>    Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse
> 
> [BA] Use of TCP transport makes sense, particularly in scenarios where both CAP
> and a PIDF-LO might be included.  You might consider saying something about this
> since TCP transport for MESSAGE is not that common today. 
> 

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. 

> ----------------------------
> 
> Section 6.1
> 
> Does it really make sense to sign the CAP alert when the sender might be a sensor
> that may not even by IP-connected, and the signer might be an aggregator with a
> different identity from the <sender> or the identity in the From: field of the
> SIP message?  If you are going to recommend that, you really need to describe
> what if anything the receiver can do to validate the signature. 
> 

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. 

> ----------------------------
> 
> Section 6.2
> 
>       Additionally, it is RECOMMENDED to make use of SIP security
>       mechanisms, such as SIP Identity [RFC4474], to tie the CAP message
>       to the SIP message.
> 
> [BA] Since the sender of the CAP message and the SIP message can be
> different, RFC 4474 only can guarantee that the message isn't modified;
> it doesn't really "tie them together".  For example, an attacker could
> snoop on a signed CAP message, insert it in a SIP MESSAGE and then
> use RFC 4474, and the sender wouldn't be able to verify that they are
> unrelated though the sender would be accountable for the mis-behavior. 
> 
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? 

> ----------------------------
> 
> Section 6.3
> 
>       For some types of data-only emergency calls author/originator and
>       the receiver/recipient have a relationship with each other and
>       hence it is possible (using cryptographic techniques) to verify
>       whether a message was indeed issued by an authorized entity.
>       Figure 1 is such an environment.  Standard SIP security mechanisms
>       can be re-used for this purpose.  For example, identity based
>       access control is a viable approach utilizing the asserted
>       identity of the alert originator using P-Asserted-Identity
>       [RFC3325] or SIP Identity [RFC4474].
> 
> [BA] What is the distinction between "forgery" and "Injecting false alerts"? 

The former is a man-in-the-middle attack that requires the adversary to be on-path. With the latter one the adversary does not need to be along the communication path, i.e. does not need to have seen any earlier message exchanges. 

> Verifying the identity of the sender of the SIP message may tell you who
> is accountable for sending the emergency alert, but that isn't the same
> as verifying the authenticity of the alert itself.  

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?

> 
> I might suggest that the threat model focus on the following instead:
> 
> 1. Prevention of modification of data in transit (e.g. sending MESSAGE over TLS)
> 2. Verification of the sender identity (Section 6.3)
> 3. Signing of alerts (Section 6.1)
> 

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? 

Ciao
Hannes

> From: [email-masked]
> Date: Wed, 20 Apr 2011 11:27:33 +0900
> To: [email-masked]
> Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01
> 
> 
> _______________________________________________ Ecrit mailing list [email-masked] https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________
> Ecrit mailing list
> [email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 06 Jul 2011 16:42:37 -0500

At 11:28 AM 7/6/2011, Hannes Tschofenig wrote:
> > On the mac URI scheme, we originally had this in the HELD 
> identity extensions but it was suggested in no uncertain terms that 
> this had buckley's chance of getting through. This led us to use an 
> explicit XML entity, though I seem to recall somebody suggesting 
> that we may have been able to do something with UUIDs.
>
>Hmmm.
>
>When I copied the example from the latest version of SIP location 
>conveyance then I see that it says the same as in the 
>ecrit-data-only-ea draft.
>So, what would you suggest? The HELD identity extension cannot be 
>used here out of the box since this is a completely different 
>specification. In RFC 5491 we had also used the 
><dm:deviceID>mac:8asd7d7d70cf</dm:deviceID> notation....

I'm not tracking what the issue is wrt SIP Location Conveyance. I 
guess I'm not "getting it", so could someone explain it differently to me?

James

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Jul 2011 13:42:54 +0300

Regarding the security consideration section here is a proposed update: 
http://www.tschofenig.priv.at/svn/draft-rosen-ecrit-data-only-ea/draft-ietf-ecrit-data-only-ea-02.txt

Ciao
Hannes