draft-ietf-drinks-spp-protocol-over-soap-02.txt   draft-ietf-drinks-spp-protocol-over-soap-03.txt 
DRINKS K. Cartwright DRINKS K. Cartwright
Internet-Draft V. Bhatia Internet-Draft V. Bhatia
Intended status: Standards Track TNS Intended status: Standards Track TNS
Expires: January 17, 2013 J-F. Mule Expires: April 26, 2013 J-F. Mule
CableLabs CableLabs
A. Mayrhofer A. Mayrhofer
enum.at GmbH enum.at GmbH
July 16, 2012 October 23, 2012
Session Peering Provisioning (SPP) Protocol over SOAP Session Peering Provisioning (SPP) Protocol over SOAP
draft-ietf-drinks-spp-protocol-over-soap-02 draft-ietf-drinks-spp-protocol-over-soap-03
Abstract Abstract
The Session Peering Provisioning Framework (SPPF) is an XML framework The Session Peering Provisioning Framework (SPPF) is an XML framework
that exists to enable the provisioning of session establishment data that exists to enable the provisioning of session establishment data
into Session Data Registries or SIP Service Provider data stores. into Session Data Registries or SIP Service Provider data stores.
Sending XML data structures over Simple Object Access Protocol (SOAP) Sending XML data structures over Simple Object Access Protocol (SOAP)
and HTTP(s) is a widely used, de-facto standard for messaging between and HTTP(s) is a widely used, de-facto standard for messaging between
elements of provisioning systems. Therefore the combination of SOAP elements of provisioning systems. Therefore the combination of SOAP
and HTTP(s) as a transport protocol for SPPF is a natural fit. The and HTTP(s) as a transport protocol for SPPF is a natural fit. The
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2013. This Internet-Draft will expire on April 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 6 3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 6
4. HTTP(s) Features and SPP Protocol over SOAP . . . . . . . . . 9 4. HTTP(s) Features and SPP Protocol over SOAP . . . . . . . . . 9
5. Authentication and Session Management . . . . . . . . . . . . 10 5. Authentication, Integrity and Confidentiality . . . . . . . . 10
6. Language Identification . . . . . . . . . . . . . . . . . . . 11 6. Language Identification . . . . . . . . . . . . . . . . . . . 11
7. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 12 7. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 12
7.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 12 7.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 12
7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . . 12 7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . . 12
7.1.2. Public Identity Object Key . . . . . . . . . . . . . . 13 7.1.2. Public Identity Object Key . . . . . . . . . . . . . . 13
7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 14 7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 14
7.2. Operation Request and Response Structures . . . . . . . . 15 7.2. Operation Request and Response Structures . . . . . . . . 15
7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 15 7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 15
7.2.2. Delete Operation Structure . . . . . . . . . . . . . . 18 7.2.2. Delete Operation Structure . . . . . . . . . . . . . . 18
7.2.3. Accept Operation Structure . . . . . . . . . . . . . . 21 7.2.3. Accept Operation Structure . . . . . . . . . . . . . . 21
skipping to change at page 3, line 13 skipping to change at page 3, line 13
10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . . 61 10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . . 61
10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . . 62 10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . . 62
10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 64 10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 64
10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 65 10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 65
10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 67 10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 67
10.13. Get Destination Group . . . . . . . . . . . . . . . . . . 68 10.13. Get Destination Group . . . . . . . . . . . . . . . . . . 68
10.14. Get Public Identity . . . . . . . . . . . . . . . . . . . 70 10.14. Get Public Identity . . . . . . . . . . . . . . . . . . . 70
10.15. Get SED Group Request . . . . . . . . . . . . . . . . . . 71 10.15. Get SED Group Request . . . . . . . . . . . . . . . . . . 71
10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 73 10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 73
10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 75 10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 75
10.18. Delete Destination Group . . . . . . . . . . . . . . . . 76 10.18. Delete Destination Group . . . . . . . . . . . . . . . . 77
10.19. Delete Public Identity . . . . . . . . . . . . . . . . . 77 10.19. Delete Public Identity . . . . . . . . . . . . . . . . . 78
10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 79 10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 80
10.21. Delete SED Group Offers Request . . . . . . . . . . . . . 80 10.21. Delete SED Group Offers Request . . . . . . . . . . . . . 81
10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . . 81 10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . . 82
10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . . 82 10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . . 83
11. Security Considerations . . . . . . . . . . . . . . . . . . . 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 86
11.1. Integrity, Privacy, and Authentication . . . . . . . . . 85 11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 86
11.2. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 85
11.3. Deployment Environment Specifics . . . . . . . . . . . . 86
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 88 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 88
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89
14.1. Normative References . . . . . . . . . . . . . . . . . . 89 14.1. Normative References . . . . . . . . . . . . . . . . . . 89
14.2. Informative References . . . . . . . . . . . . . . . . . 89 14.2. Informative References . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91
1. Introduction 1. Introduction
SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], is best SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], is best
skipping to change at page 10, line 5 skipping to change at page 10, line 5
the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent
connection" feature, which allows multiple HTTP request/response connection" feature, which allows multiple HTTP request/response
pairs to be transported across a single HTTP connection. This is an pairs to be transported across a single HTTP connection. This is an
important performance optimization feature, particularly when the important performance optimization feature, particularly when the
connections is an HTTPS connection where the relatively time connections is an HTTPS connection where the relatively time
consuming SSL handshake has occurred. Persistent connections SHOULD consuming SSL handshake has occurred. Persistent connections SHOULD
be used for the SPPF HTTP connections. be used for the SPPF HTTP connections.
HTTP 1.1 [RFC2616] or higher SHOULD be used. HTTP 1.1 [RFC2616] or higher SHOULD be used.
5. Authentication and Session Management 5. Authentication, Integrity and Confidentiality
To achieve integrity and privacy, conforming SPP Protocol SOAP To accomplish authentication, conforming SPP Protocol over SOAP
Clients and Servers MUST support SOAP over HTTP over TLS [RFC5246] as Clients and Servers MUST use HTTP Digest Authentication as defined in
the secure transport mechanism. This combination of HTTP and TLS is [RFC2617] as the authentication mechanism.
referred to as HTTPS. And to accomplish authentication, conforming
SOAP SPPF Clients and Servers MUST use HTTP Digest Authentication as To achieve integrity and privacy, conforming SPP Protocol over SOAP
defined in [RFC2617]. As a result, the communication session is Clients and Servers MUST support Transport Layer Security (TLS) as
established through the initial HTTP connection setup, the digest defined in [RFC5246] as the secure transport mechanism.
authentication, and the TLS handshake. When the HTTP connection is
broken down, the communication session ends.
6. Language Identification 6. Language Identification
Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires transport Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires transport
protocols to provide a mechanism to transmit language tags together protocols to provide a mechanism to transmit language tags together
with human-readable messages. When conforming SPP Protocol SOAP with human-readable messages. When conforming SPP Protocol SOAP
servers use such tagging, the XML "lang" attribute (see Section 2.12 servers use such tagging, the XML "lang" attribute (see Section 2.12
of [W3C.REC-xml-20081126]) MUST be used for that purpose. Clients of [W3C.REC-xml-20081126]) MUST be used for that purpose. Clients
MAY use the HTTP "Accept-Language" header field (see Section 14.4 of MAY use the HTTP "Accept-Language" header field (see Section 14.4 of
[RFC2616]) in order to indicate their language preference. [RFC2616]) in order to indicate their language preference.
skipping to change at page 14, line 43 skipping to change at page 14, line 43
provisioned as members of a Destination Group. provisioned as members of a Destination Group.
o number: An element of type NumberType (refer framework document) o number: An element of type NumberType (refer framework document)
that contains the value and type of a number . that contains the value and type of a number .
o range: An element of type NumberRangeType (refer framework o range: An element of type NumberRangeType (refer framework
document) that contains a range of numbers. document) that contains a range of numbers.
o uri: A value that represents a Public Identifier. o uri: A value that represents a Public Identifier.
It is MUST that only one of the "number", "range", and "uri" elements Any instance of PubIdKeyType MUST contain exactly one element from
appears in a PubIdKeyType instance. the following set of elements: "number", "range", "uri".
7.1.3. SED Group Offer Key 7.1.3. SED Group Offer Key
In addition to the attributes in the generic ObjKeyType, a SED Group In addition to the attributes in the generic ObjKeyType, a SED Group
Offer object is uniquely identified by the organization ID of the Offer object is uniquely identified by the organization ID of the
organization to whom an SED Group has been offered. The definition organization to whom an SED Group has been offered. The definition
of SedGrpOfferKeyType is as below: of SedGrpOfferKeyType is as below:
<complexType name="SedGrpOfferKeyType"> <complexType name="SedGrpOfferKeyType">
<complexContent> <complexContent>
skipping to change at page 69, line 41 skipping to change at page 69, line 41
<ns3:spppGetResponse <ns3:spppGetResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>success</msg> <msg>success</msg>
</overallResult> </overallResult>
<resultObj xsi:type="ns2:DestGrpType"> <resultObj xsi:type="ns2:DestGrpType">
<ns2:rant>iana-en:222</ns2:rant> <ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar> <ns2:rar>iana-en:223</ns2:rar>
<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName> <ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
</resultObj> </resultObj>
</ns3:spppGetResponse> </ns3:spppGetResponse>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
10.14. Get Public Identity 10.14. Get Public Identity
SSP2 obtains the last provisioned record associated with a given TN. SSP2 obtains the last provisioned record associated with a given TN.
skipping to change at page 71, line 19 skipping to change at page 71, line 19
<ns3:spppGetResponse <ns3:spppGetResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>success</msg> <msg>success</msg>
</overallResult> </overallResult>
<resultObj xsi:type="ns2:TNType"> <resultObj xsi:type="ns2:TNType">
<ns2:rant>iana-en:222</ns2:rant> <ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar> <ns2:rar>iana-en:223</ns2:rar>
<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName> <ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
<ns2:tn>+12025556666</ns2:tn> <ns2:tn>+12025556666</ns2:tn>
<ns2:corInfo> <ns2:corInfo>
<ns2:corClaim>true</ns2:corClaim> <ns2:corClaim>true</ns2:corClaim>
<ns2:cor>true</ns2:cor> <ns2:cor>true</ns2:cor>
<ns2:corDate>2010-05-30T09:30:10Z</ns2:corDate> <ns2:corDate>2010-05-30T09:30:10Z</ns2:corDate>
</ns2:corInfo> </ns2:corInfo>
</resultObj> </resultObj>
</ns3:spppGetResponse> </ns3:spppGetResponse>
</S:Body> </S:Body>
skipping to change at page 73, line 20 skipping to change at page 73, line 20
<ns3:spppGetResponse <ns3:spppGetResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>success</msg> <msg>success</msg>
</overallResult> </overallResult>
<resultObj xsi:type="ns2:SedGrpType"> <resultObj xsi:type="ns2:SedGrpType">
<ns2:rant>iana-en:222</ns2:rant> <ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar> <ns2:rar>iana-en:223</ns2:rar>
<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
<ns2:sedGrpName>SED_GRP_SSP2_1</ns2:sedGrpName> <ns2:sedGrpName>SED_GRP_SSP2_1</ns2:sedGrpName>
<ns2:sedRecRef> <ns2:sedRecRef>
<ns2:sedKey xsi:type="ns3:ObjKeyType"> <ns2:sedKey xsi:type="ns3:ObjKeyType">
<rant>iana-en:222</rant> <rant>iana-en:222</rant>
<name>SED_SSP2_SBE2</name> <name>SED_SSP2_SBE2</name>
<type>SedRec</type> <type>SedRec</type>
</ns2:sedKey> </ns2:sedKey>
<ns2:priority>100</ns2:priority> <ns2:priority>100</ns2:priority>
</ns2:sedRecRef> </ns2:sedRecRef>
<ns2:sedRecRef> <ns2:sedRecRef>
skipping to change at page 74, line 35 skipping to change at page 75, line 20
<ns3:spppGetResponse <ns3:spppGetResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>success</msg> <msg>success</msg>
</overallResult> </overallResult>
<resultObj xsi:type="ns2:SedGrpOfferType"> <resultObj xsi:type="ns2:SedGrpOfferType">
<ns2:rant>iana-en:222</ns2:rant> <ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar> <ns2:rar>iana-en:223</ns2:rar>
<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
<ns2:sedGrpOfferKey <ns2:sedGrpOfferKey
xsi:type="ns3:SedGrpOfferKeyType"> xsi:type="ns3:SedGrpOfferKeyType">
<sedGrpKey> <sedGrpKey>
<rant>iana-en:222</rant> <rant>iana-en:222</rant>
<name>SED_GRP_SSP2_1</name> <name>SED_GRP_SSP2_1</name>
<type>SedGrp</type> <type>SedGrp</type>
</sedGrpKey> </sedGrpKey>
<offeredTo>iana-en:111</offeredTo> <offeredTo>iana-en:111</offeredTo>
</ns2:sedGrpOfferKey> </ns2:sedGrpOfferKey>
<ns2:status>offered</ns2:status> <ns2:status>offered</ns2:status>
skipping to change at page 76, line 20 skipping to change at page 77, line 20
<ns3:spppGetResponse <ns3:spppGetResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>success</msg> <msg>success</msg>
</overallResult> </overallResult>
<resultObj xsi:type="ns2:EgrRteType"> <resultObj xsi:type="ns2:EgrRteType">
<ns2:rant>iana-en:222</ns2:rant> <ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar> <ns2:rar>iana-en:223</ns2:rar>
<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
<ns2:egrRteName>EGR_RTE_01</ns2:egrRteName> <ns2:egrRteName>EGR_RTE_01</ns2:egrRteName>
<ns2:pref>50</ns2:pref> <ns2:pref>50</ns2:pref>
<ns2:regxRewriteRule> <ns2:regxRewriteRule>
<ns2:ere>^(.*)$</ns2:ere> <ns2:ere>^(.*)$</ns2:ere>
<ns2:repl>sip:\1@sbe1.ssp1.example.com</ns2:repl> <ns2:repl>sip:\1@sbe1.ssp1.example.com</ns2:repl>
</ns2:regxRewriteRule> </ns2:regxRewriteRule>
<ns2:ingrSedGrp xsi:type="ns3:ObjKeyType"> <ns2:ingrSedGrp xsi:type="ns3:ObjKeyType">
<rant>iana-en:222</rant> <rant>iana-en:222</rant>
<name>SED_GRP_SSP2_1</name> <name>SED_GRP_SSP2_1</name>
<type>SedRec</type> <type>SedRec</type>
skipping to change at page 85, line 14 skipping to change at page 86, line 14
11. Security Considerations 11. Security Considerations
SPP Protocol over SOAP is used to query and update session peering SPP Protocol over SOAP is used to query and update session peering
data and addresses, so the ability to access this protocol should be data and addresses, so the ability to access this protocol should be
limited to users and systems that are authorized to query and update limited to users and systems that are authorized to query and update
this data. Because this data is sent in both directions, it may not this data. Because this data is sent in both directions, it may not
be sufficient for just the client or user to be authenticated with be sufficient for just the client or user to be authenticated with
the server. The identity of the server should also be authenticated the server. The identity of the server should also be authenticated
by the client, which is often accomplished using the TLS certificate by the client, which is often accomplished using the TLS certificate
exchange and validation described in [RFC2818]. SPP Protocol over exchange and validation described in [RFC2818].
SOAP messages may include sensitive information, routing data, lists
of resolvable addresses, etc. So when used in a production setting
and across non-secure networks, SPP Protocol over SOAP should only be
used over communications channels that provide strong encryption for
data privacy.
11.1. Integrity, Privacy, and Authentication
The SPP Protocol over SOAP binding relies on an underlying secure
transport for integrity and privacy. Such transports are expected to
include TLS/HTTPS. In addition to the application level
authentication imposed by an SPPF server, there are a number of
options for authentication within the transport layer and the
messaging envelope. These include TLS client certificates, HTTP
Digest Access Authentication, and digital signatures within SOAP
headers.
At a minimum, all conforming SPP Protocol over SOAP implementations
MUST support HTTPS.
11.2. Vulnerabilities 11.1. Vulnerabilities
The above protocols may have various vulnerabilities, and these may Section 5 describes the use of HTTP and TLS as the underlying
be inherited by SPP Protocol over SOAP. SPP Protocol over SOAP transport protocols for SPP Protocol over SOAP. These underlying
itself may have vulnerabilities because an authorization model is not protocols may have various vulnerabilities, and these may be
inherited by SPP Protocol over SOAP. SPP Protocol over SOAP itself
may have vulnerabilities because an authorization model is not
explicitly specified in the current specification. explicitly specified in the current specification.
Sections 5 and 10.1 describe requirements for HTTPS support using During a TLS handshake, non-anonymous TLS servers can optionally
TLS. Non-anonymous TLS servers can optionally request a certificate request a certificate from a TLS client; that option is not a
from a TLS client; that option is not a requirement for this requirement for this protocol. This presents a denial of service
protocol. This presents a denial of service risk in which risk in which unauthenticated clients can consume server CPU
unauthenticated clients can consume server CPU resources by creating resources by creating TLS sessions. The risk is increased if the
TLS sessions. The risk is increased if the server supports client- server supports client-initiated renegotiation. This risk can be
initiated renegotiation. This risk can be mitigated by disabling mitigated by disabling client-initiated renegotiation on the server
client-initiated renegotiation on the server and by ensuring that and by ensuring that other means (such as firewall access control
other means (such as firewall access control lists) are used to lists) are used to restrict unauthenticated client access to servers.
restrict unauthenticated client access to servers.
In conjunction with the above, it is important that SPP Protocol over In conjunction with the above, it is important that SPP Protocol over
SOAP implementations implement an authorization model that considers SOAP implementations implement an authorization model that considers
the source of each query or update request and determines whether it the source of each query or update request and determines whether it
is reasonable to authorize that source to perform that specific query is reasonable to authorize that source to perform that specific query
or update. or update.
11.3. Deployment Environment Specifics
Some deployments of SPP Protocol over SOAP could choose to use
transports without encryption. This presents vulnerabilities but
could be selected for deployments involving closed networks or
debugging scenarios. However, the vulnerabilities of such a
deployment could be a lack of integrity and privacy of the data
transported in this type of deployment.
12. IANA Considerations 12. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. conforming to a registry mechanism described in [RFC3688].
URN assignments requested are: urn:ietf:params:xml:ns:sppf:soap:1 URN assignments requested are: urn:ietf:params:xml:ns:sppf:soap:1
13. Acknowledgements 13. Acknowledgements
This document is a result of various discussions held by the DRINKS This document is a result of various discussions held by the DRINKS
skipping to change at page 89, line 12 skipping to change at page 89, line 12
Shockey, Samuel Melloul, Scott Hollenbeck, Sumanth Channabasappa, Shockey, Samuel Melloul, Scott Hollenbeck, Sumanth Channabasappa,
Syed Ali, and Vikas Bhatia . Syed Ali, and Vikas Bhatia .
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.draft-ietf-drinks-spp-framework] [I-D.draft-ietf-drinks-spp-framework]
Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz, Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz,
"Session Peering Provisioning Framework", "Session Peering Provisioning Framework",
draft-ietf-drinks-spp-framework-02 (work in progress), draft-ietf-drinks-spp-framework-03 (work in progress),
July 2012. October 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
 End of changes. 20 change blocks. 
72 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/