Skip to main content

Session Peering Provisioning (SPP) Protocol over SOAP
RFC 7878

Document Type RFC - Proposed Standard (August 2016)
Authors Kenneth Cartwright , Vikas Bhatia , Jean-Francois Mule , Alexander Mayrhofer
Last updated 2016-08-17
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
IESG Responsible AD Ben Campbell
Send notices to (None)
RFC 7878
>
       <sedGrpKey>
        <rant>iana-en:226</rant>
        <name>SED_SSP4_SBE1_Offered</name>
        <type>SedGrp</type>
       </sedGrpKey>
       <offeredTo>iana-en:222</offeredTo>
      </rejectSedGrpOffer>

     </urn:spppBatchRequest>
    </soapenv:Body>
   </soapenv:Envelope>

   The Registry completes the request successfully and returns a
   favorable response.

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppBatchResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <serverTransId>tx_12354</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppBatchResponse>
    </S:Body>
   </S:Envelope>

Cartwright, et al.           Standards Track                   [Page 79]
RFC 7878                 SPP Protocol over SOAP              August 2016

11.  Security Considerations

   The base security considerations of SPPP outlined in Section 9 of
   [RFC7877] also apply to SPPP over SOAP implementations.
   Additionally, the following must be considered:

   SPPP over SOAP is used to query and update session peering data and
   addresses, so the ability to access this protocol should be 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 be
   sufficient for just the client or user to be authenticated with the
   server.  The identity of the server should also be authenticated by
   the client, which is often accomplished using the TLS certificate
   exchange and validation described in [RFC2818].

11.1.  Vulnerabilities

   Section 5 describes the use of HTTP and TLS as the underlying
   substrate protocols for SPPP over SOAP.  These underlying protocols
   may have various vulnerabilities, and these may be inherited by SPPP
   over SOAP.  SPPP over SOAP itself may have vulnerabilities because an
   authorization model is not explicitly specified in this document.

   During a TLS handshake, TLS servers can optionally request a
   certificate from a TLS client; that option is not a requirement for
   this protocol.  This presents a denial-of-service risk in which
   unauthenticated clients can consume server CPU resources by creating
   TLS sessions.  The risk is increased if the server supports client-
   initiated renegotiation.  This risk can be mitigated by disabling
   client-initiated renegotiation on the server and by ensuring that
   other means (such as firewall access control lists) are used to
   restrict unauthenticated client access to servers.

   In conjunction with the above, it is important that SPPP over SOAP
   implementations implement an authorization model that considers the
   source of each query or update request and determines whether it is
   reasonable to authorize that source to perform that specific query or
   update.

Cartwright, et al.           Standards Track                   [Page 80]
RFC 7878                 SPP Protocol over SOAP              August 2016

12.  IANA Considerations

   This document uses URNs to describe XML Namespaces and XML Schemas.
   According to [RFC3688], IANA has performed the following URN
   assignment:

      URN: urn:ietf:params:xml:ns:sppf:soap:1

      Registrant Contact: IESG

      XML: See Section 9 of [RFC7878]

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <http://www.rfc-editor.org/info/rfc3688>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <http://www.rfc-editor.org/info/rfc7231>.

   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Authentication", RFC 7235,
              DOI 10.17487/RFC7235, June 2014,
              <http://www.rfc-editor.org/info/rfc7235>.

Cartwright, et al.           Standards Track                   [Page 81]
RFC 7878                 SPP Protocol over SOAP              August 2016

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

   [RFC7877]  Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz,
              "Session Peering Provisioning Framework (SPPF)", RFC 7877,
              DOI 10.17487/RFC7877, August 2016,
              <http://www.rfc-editor.org/info/rfc7877>.

   [SOAPREF]  Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP
              Version 1.2 Part 1: Messaging Framework (Second Edition)",
              W3C Recommendation REC-SOAP12-part1-20070427, April 2007,
              <http://www.w3.org/TR/soap12-part1/>.

13.2.  Informative References

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <http://www.rfc-editor.org/info/rfc5321>.

   [W3C.REC-xml-20081126]
              Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E.,
              and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", W3C Recommendation REC-xml-20081126, November
              2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.

   [WSDLREF]  Christensen, E., Curbera, F., Meredith, G., and S.
              Weerawarana, "Web Services Description Language (WSDL)
              1.1", W3C Note NOTE-wsdl-20010315, March 2001,
              <http://www.w3.org/TR/2001/NOTE-wsdl-20010315>.

Acknowledgements

   This document is a result of various discussions held with the IETF
   DRINKS working group, specifically the protocol design team, with
   contributions from the following individuals, in alphabetical order:
   Syed Ali, Vikas Bhatia, Kenneth Cartwright, Sumanth Channabasappa,
   Lisa Dusseault, Deborah A.  Guyton, Scott Hollenbeck, Otmar Lendl,
   Manjul Maharishi, Mickael Marrache, Alexander Mayrhofer, Samuel
   Melloul, Jean-Francois Mule, Peter Saint-Andre, David Schwartz, and
   Richard Shockey.

Cartwright, et al.           Standards Track                   [Page 82]
RFC 7878                 SPP Protocol over SOAP              August 2016

Authors' Addresses

   Kenneth Cartwright
   TNS
   10740 Parkridge Boulevard
   Reston, VA  20191
   United States

   Email: kcartwright@tnsi.com

   Vikas Bhatia
   TNS
   10740 Parkridge Boulevard
   Reston, VA  20191
   United States

   Email: vbhatia@tnsi.com

   Jean-Francois Mule
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   United States

   Email: jfmule@apple.com

   Alexander Mayrhofer
   nic.at GmbH
   Karlsplatz 1/2/9
   Wien  A-1010
   Austria

   Email: alexander.mayrhofer@nic.at

Cartwright, et al.           Standards Track                   [Page 83]