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

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

On Jul 6, 2011, at 7:28 PM, Hannes Tschofenig wrote:

> 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: shida@ntt-at.com
>> Date: Wed, 20 Apr 2011 11:27:33 +0900
>> To: ecrit@ietf.org
>> Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01
>> 
>> 
>> 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. 
>> 
>> 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.   
>> 
>> 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.)
>> 
>> 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. 
>> 
>> 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?
>> 
>> 5. Use of P-Asserted-Identity doesn't provide any integrity so I would 
>>     take it out of section 6.3.
>> 
>> 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. 
>> 
>> 7. Shouldn't RFC3261(SIP)/RFC3428(MESSAGE)/location-conveyance/
>>     RFC4119(PIDF-LO) be in a normative reference?
>> 
>> 
>> **Some nits**
>> 
>>  Section 6: 
>> 
>>  OLD ".. this document and the discussion in.."
>> 
>>  NEW ".. this document and are discussed in.."
>> 
>>  Section 6.2
>> 
>>  OLD "..alerts and reply them at a later time.."
>> 
>>  NEW "..alerts and replay them at a later time.."
>> 
>> 
>> 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).
>> 
>> 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
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
>> 
>> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
> 