tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7652

 
 
 

Port Control Protocol (PCP) Authentication Mechanism

Part 2 of 2, p. 22 to 34
Prev RFC Part

 


prevText      Top      ToC       Page 22 
6.  Processing Rules

6.1.  Authentication Data Generation

   After a successful EAP authentication process, every subsequent
   PCP message within the PA session MUST carry an authentication tag
   that contains the digest of the PCP message for data origin
   authentication and integrity protection.

   o  Before generating a digest for a PA message, a device needs to
      first locate the PCP SA according to the session identifier and
      then get the transport key.  Then, the device appends a
      PA_AUTHENTICATION_TAG option for PCP Auth at the end of the
      PCP Auth message.  The length of the Authentication Data field is
      decided by the MAC algorithm adopted in the session.  The device
      then fills the Key ID field with the key ID of the transport key
      and sets the Authentication Data field to zero.  After this, the
      device generates a digest for the entire PCP message (including
      the PCP header and PA_AUTHENTICATION_TAG option) using the
      transport key and the associated MAC algorithm, and inserts the
      generated digest into the Authentication Data field.

   o  Similar to generating a digest for a PA message, before generating
      a digest for a common PCP message, a device needs to first locate
      the PCP SA according to the session identifier and then get the
      transport key.  Then, the device appends the AUTHENTICATION_TAG
      option at the end of the common PCP message.  The length of the
      Authentication Data field is decided by the MAC algorithm adopted
      in the session.  The device then uses the corresponding values

Top      Up      ToC       Page 23 
      derived from the SA to fill the Session ID field, the Sequence
      Number field, and the Key ID field, and sets the Authentication
      Data field to zero.  After this, the device generates a digest for
      the entire PCP message (including the PCP header and
      AUTHENTICATION_TAG option) using the transport key and the
      associated MAC algorithm, and inserts the generated digest into
      the Authentication Data field.

6.2.  Authentication Data Validation

   When a device receives a common PCP message with an
   AUTHENTICATION_TAG option for common PCP messages, the device needs
   to use the Session ID transported in the option to locate the proper
   SA and then find the associated transport key (using the key ID in
   the option) and the MAC algorithm.  If no proper SA or transport key
   is found or the sequence number is invalid (see Section 6.5), the PCP
   device stops processing the PCP message and silently discards the
   message.  After storing the value of the Authentication field of the
   AUTHENTICATION_TAG option, the device fills the Authentication field
   with zeros.  Then, the device generates a digest for the message
   (including the PCP header and AUTHENTICATION_TAG option) with the
   transport key and the MAC algorithm.  If the value of the newly
   generated digest is identical to the stored one, the device can
   ensure that the message has not been tampered with, and the
   validation succeeds.  Otherwise, the PCP device stops processing the
   PCP message and silently discards the message.

   Similarly, when a device receives a PA message with a
   PA_AUTHENTICATION_TAG option for PCP authentication, the device needs
   to use the Session ID transported in the Opcode to locate the proper
   SA and then find the associated transport key (using the key ID in
   the option) and the MAC algorithm.  If no proper SA or transport key
   is found or the sequence number is invalid (see Section 6.4), the PCP
   device stops processing the PCP message and silently discards the
   message.  After storing the value of the Authentication field of the
   PA_AUTHENTICATION_TAG option, the device fills the Authentication
   field with zeros.  Then, the device generates a digest for the
   message (including the PCP header and PA_AUTHENTICATION_TAG option)
   with the transport key and the MAC algorithm.  If the value of the
   newly generated digest is identical to the stored one, the device can
   ensure that the message has not been tampered with, and the
   validation succeeds.  Otherwise, the PCP device stops processing the
   PCP message and silently discards the message.

Top      Up      ToC       Page 24 
6.3.  Retransmission Policies for PA Messages

   Because EAP relies on the underlying protocols to provide reliable
   transmission, after sending a PA message, a PCP client/server
   MUST NOT send out any subsequent messages until it has received a
   PA message with a proper sequence number from the peer.  If no such
   message is received, the PCP device will resend the last message
   according to retransmission policies.  This specification uses the
   retransmission policies specified in Section 8.1.1 of the base PCP
   specification [RFC6887].  In base PCP, such retransmission policies
   are only applied by PCP clients.  However, in this specification,
   such retransmission policies are also applied by the PCP servers.  If
   the "maximum retransmission" duration (in seconds) has elapsed and no
   expected response is received, the device will terminate the session
   and discard the current SA.

   As discussed in Section 3.1.3, in order to avoid unnecessary
   retransmission, the device receiving a PA message MUST send a
   PA-Acknowledgement message to the sender of the PA message when it
   cannot send a PA response immediately.  The PA-Acknowledgement
   message is used to indicate the receipt of the PA message.  When the
   sender receives the PA-Acknowledgement message, it will stop the
   retransmission.

   Note that the last PA messages transported within the phases of
   session initiation, session re-authentication, and session
   termination do not have to follow the above policies, since the
   devices sending out those messages do not expect any further
   PA messages.

   When a device receives a retransmitted last incoming PA message from
   its session partner, it MUST try to answer it by sending the last
   outgoing PA message again.  However, if the duplicate message has the
   same sequence number but is not bitwise identical to the original
   message, then the device MUST discard it.  In order to perform this
   function, the device may need to maintain the last incoming message
   and the associated outgoing messages.  In this case, if no outgoing
   PA message has been generated for the received duplicate PA message
   yet, the device needs to send a PA-Acknowledgement message.  The rate
   of replying to duplicate PA messages MUST be limited to provide
   robustness against denial-of-service (DoS) attacks.  The details of
   rate limiting are outside the scope of this specification.

Top      Up      ToC       Page 25 
6.4.  Sequence Numbers for PCP Auth Messages

   PCP uses UDP to transport signaling messages.  As an unreliable
   transport protocol, UDP does not guarantee ordered packet delivery
   and does not provide any protection from packet loss.  In order to
   ensure that the EAP messages are exchanged in a reliable way, every
   PCP message exchanged during EAP authentication must carry a
   monotonically increasing sequence number.  During a PA session, a PCP
   device needs to maintain two sequence numbers for PA messages: one
   for incoming PA messages and one for outgoing PA messages.  When
   generating an outgoing PA message, the device adds the associated
   outgoing sequence number to the message and increments the sequence
   number maintained in the SA by 1.  When receiving a PA message from
   its session partner, the device will not accept it if the sequence
   number carried in the message does not match the incoming sequence
   number maintained in the device.  After confirming that the received
   message is valid, the device increments the incoming sequence number
   maintained in the SA by 1.

   The above rules are not applicable to PA-Acknowledgement messages
   (i.e., PA messages containing a RECEIVED_PAK option).  A
   PA-Acknowledgement message does not transport any EAP message and
   only indicates that a PA message is received.  Therefore, reliable
   transmission of PA-Acknowledgement messages is not required.  For
   instance, after sending out a PA-Acknowledgement message, a device
   generates an EAP response.  In this case, the device does not have to
   confirm whether the PA-Acknowledgement message has been received by
   its session partner or not.  Therefore, when receiving or sending out
   a PA-Acknowledgement message, the device MUST NOT increase the
   corresponding sequence number stored in the SA.  Otherwise, loss of a
   PA-Acknowledgement message will cause a mismatch in sequence numbers.

   Another exception is the message retransmission scenario.  As
   discussed in Section 6.3, when a PCP device does not receive any
   response from its session partner, it needs to retransmit the last
   outgoing PA message, following the retransmission procedure specified
   in Section 8.1.1 of [RFC6887].  The original message and duplicate
   messages MUST be bitwise identical.  When the device receives such a
   duplicate PA message from its session partner, it MUST send the last
   outgoing PA message again.  In such cases, the maintained incoming
   and outgoing sequence numbers will not be affected by the message
   retransmission.

Top      Up      ToC       Page 26 
6.5.  Sequence Numbers for Common PCP Messages

   When transporting common PCP messages within a PA session, a PCP
   device needs to maintain a sequence number for outgoing common
   PCP messages and a sequence number for incoming common PCP messages.
   When generating a new outgoing PCP message, the PCP device updates
   the Sequence Number field in the AUTHENTICATION_TAG option with the
   outgoing sequence number maintained in the SA and increments the
   outgoing sequence number by 1.

   When receiving a PCP message from its session partner, the PCP device
   will not accept it if the sequence number carried in the message is
   smaller than the incoming sequence number maintained in the device.
   This approach can protect the PCP device from replay attacks.  After
   confirming that the received message is valid, the PCP device will
   update the incoming sequence number maintained in the PCP SA with the
   sequence number of the incoming message.

   Note that the sequence number in the incoming message may not exactly
   match the incoming sequence number maintained locally.  As discussed
   in the base PCP specification [RFC6887], if a PCP client is no longer
   interested in the PCP transaction and has not yet received a
   PCP response from the server, then it will stop retransmitting the
   PCP request.  After that, the PCP client might generate new
   PCP requests for other purposes, using the current SA.  In this case,
   the sequence number in the new request will be larger than the
   sequence number in the old request and so will be larger than the
   incoming sequence number maintained in the PCP server.

   Note that, as discussed in the base PCP specification [RFC6887], a
   PCP client needs to select a nonce in each MAP or PEER request, and
   the nonce is sent back in the response.  However, it is possible for
   a client to use the same nonce in multiple MAP or PEER requests, and
   this may cause a potential risk of replay attacks.  This attack is
   addressed by using the sequence number in the PCP response.

6.6.  MTU Considerations

   EAP methods are responsible for MTU handling, so no special
   facilities are required in PCP to deal with MTU issues.
   Specifically, EAP lower layers indicate to EAP methods and
   Authentication, Authorization, and Accounting (AAA) servers the MTU
   of the lower layer.  EAP methods such as EAP-TLS [RFC5216], TEAP
   [RFC7170], and others that are likely to exceed reasonable MTUs
   provide support for fragmentation and reassembly.  Others, such as
   EAP - Generalized Pre-Shared Key (EAP-GPSK) [RFC5433], assume that
   they will never send packets larger than the MTU and use small EAP
   packets.

Top      Up      ToC       Page 27 
   If an EAP message is too long to be transported within a single
   PA message, it will be divided into multiple sections and sent within
   different PA messages.  Note that the receiver may not be able to
   know what to do in the next step until it has received all the
   sections and reconstructed the complete EAP message.  In this case,
   in order to guarantee reliable message transmission, after receiving
   a PA message, the receiver replies with a PA-Acknowledgement message
   to notify the sender to send the next PA message.

7.  IANA Considerations

   The following PCP Opcode has been allocated from the Standards Action
   range of the "PCP Opcodes" registry (which is maintained in
   <http://www.iana.org/assignments/pcp-parameters>):

      3 AUTHENTICATION.

   The following PCP result codes have been allocated from the Standards
   Action range of the "PCP Result Codes" registry (which is maintained
   in <http://www.iana.org/assignments/pcp-parameters>):

      14 INITIATION: The client includes this PCP result code in its
      request to the server for authentication.

      15 AUTHENTICATION_REQUIRED: This error response is sent to the
      client if EAP authentication is required.

      16 AUTHENTICATION_FAILED: This error response is sent to the
      client if EAP authentication failed.

      17 AUTHENTICATION_SUCCEEDED: This success response is sent to the
      client if EAP authentication succeeded.

      18 AUTHORIZATION_FAILED: This error response is sent to the client
      if EAP authentication succeeded but authorization failed.

      19 SESSION_TERMINATED: This PCP result code indicates to the
      partner that the PA session must be terminated.

      20 UNKNOWN_SESSION_ID: This error response is sent from the
      PCP server if there is no known PA session associated with the
      Session ID sent in the PA request or common PCP request from the
      PCP client.

      21 DOWNGRADE_ATTACK_DETECTED: This PCP result code indicates to
      the client that the server detected a downgrade attack.

Top      Up      ToC       Page 28 
      22 AUTHENTICATION_REQUEST: The server indicates to the client that
      the PA message contains an EAP request.

      23 AUTHENTICATION_REPLY: The client indicates to the server that
      the PA message contains an EAP response.

   The following PCP options have been allocated from the Standards
   Action range (the registry for PCP options is maintained in
   <http://www.iana.org/assignments/pcp-parameters>):

7.1.  NONCE

   Name:  NONCE.

   Value:  4.

   Purpose:  See Section 5.3.

   Valid for Opcodes:  AUTHENTICATION.

   Length:  4 octets.

   May appear in:  Request and response.

   Maximum occurrences:  1.

7.2.  AUTHENTICATION_TAG

   Name:  AUTHENTICATION_TAG.

   Value:  5.

   Purpose:  See Section 5.4.

   Valid for Opcodes:  MAP, PEER, ANNOUNCE.

   Length:  variable.

   May appear in:  Request and response.

   Maximum occurrences:  1.

Top      Up      ToC       Page 29 
7.3.  PA_AUTHENTICATION_TAG

   Name:  PA_AUTHENTICATION_TAG.

   Value:  6.

   Purpose:  See Section 5.5.

   Valid for Opcodes:  AUTHENTICATION.

   Length:  variable.

   May appear in:  Request and response.

   Maximum occurrences:  1.

7.4.  EAP_PAYLOAD

   Name:  EAP_PAYLOAD.

   Value:  7.

   Purpose:  See Section 5.6.

   Valid for Opcodes:  AUTHENTICATION.

   Length:  variable.

   May appear in:  Request and response.

   Maximum occurrences:  1.

7.5.  PRF

   Name:  PRF.

   Value:  8.

   Purpose:  See Section 5.7.

   Valid for Opcodes:  AUTHENTICATION.

   Length:  4 octets.

   May appear in:  Request and response.

   Maximum occurrences:  as many as fit within maximum PCP message size.

Top      Up      ToC       Page 30 
7.6.  MAC_ALGORITHM

   Name:  MAC_ALGORITHM.

   Value:  9.

   Purpose:  See Section 5.8.

   Valid for Opcodes:  AUTHENTICATION.

   Length:  4 octets.

   May appear in:  Request and response.

   Maximum occurrences:  as many as fit within maximum PCP message size.

7.7.  SESSION_LIFETIME

   Name:  SESSION_LIFETIME.

   Value:  10.

   Purpose:  See Section 5.9.

   Valid for Opcodes:  AUTHENTICATION

   Length:  4 octets.

   May appear in:  Response.

   Maximum occurrences:  1.

7.8.  RECEIVED_PAK

   Name:  RECEIVED_PAK.

   Value:  11.

   Purpose:  See Section 5.10.

   Valid for Opcodes:  AUTHENTICATION.

   Length:  4 octets.

   May appear in:  Request and response.

   Maximum occurrences:  1.

Top      Up      ToC       Page 31 
7.9.  ID_INDICATOR

   Name:  ID_INDICATOR.

   Value:  12.

   Purpose:  See Section 5.11.

   Valid for Opcodes:  AUTHENTICATION.

   Length:  variable.

   May appear in:  Response.

   Maximum occurrences:  1.

8.  Security Considerations

   As described in this specification, after a successful EAP
   authentication process is performed between two PCP devices, an MSK
   will be exported.  The MSK will be used to derive the transport keys
   to generate MAC digests for subsequent PCP message exchanges.
   However, before a transport key has been generated, the PA messages
   exchanged within a PA session have little cryptographic protection,
   and if there is no already-established security channel between two
   session partners, these messages are subject to man-in-the-middle
   attacks and DoS attacks.  For instance, the initial PA-Server and
   PA-Client message exchange is vulnerable to spoofing attacks, as
   these messages are not authenticated and integrity protected.  In
   addition, because the PRF and MAC algorithms are transported at this
   stage, an attacker may try to remove the PRF and MAC options
   containing strong algorithms from the initial PA-Server message and
   force the client to choose the weakest algorithms.  Therefore, the
   server needs to guarantee that all the PRF and MAC algorithms for
   which it provides support are strong enough.

   In order to prevent very basic DoS attacks, a PCP device SHOULD
   generate state information as little as possible in the initial
   PA-Server and PA-Client message exchanges.  The choice of EAP method
   is also very important.  The selected EAP method must (1) be
   resilient to attacks that are possible in an insecure network
   environment, (2) provide user-identity confidentiality and protection
   against dictionary attacks, and (3) support session-key
   establishment.

   When a PCP proxy [RFC7648] is located between a PCP server and
   PCP clients, the proxy may perform authentication with the PCP server
   before it processes requests from the clients.  In addition,

Top      Up      ToC       Page 32 
   re-authentication between the PCP proxy and PCP server will not
   interrupt the service that the proxy provides to the clients, since
   the proxy is still allowed to send common PCP messages to the
   PCP server during that period.

9.  References

9.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>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <http://www.rfc-editor.org/info/rfc3629>.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <http://www.rfc-editor.org/info/rfc3748>.

   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
              384, and HMAC-SHA-512 with IPsec", RFC 4868,
              DOI 10.17487/RFC4868, May 2007,
              <http://www.rfc-editor.org/info/rfc4868>.

   [RFC5281]  Funk, P. and S. Blake-Wilson, "Extensible Authentication
              Protocol Tunneled Transport Layer Security Authenticated
              Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
              DOI 10.17487/RFC5281, August 2008,
              <http://www.rfc-editor.org/info/rfc5281>.

   [RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
              P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
              DOI 10.17487/RFC6887, April 2013,
              <http://www.rfc-editor.org/info/rfc6887>.

   [RFC7170]  Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
              "Tunnel Extensible Authentication Protocol (TEAP) Version
              1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
              <http://www.rfc-editor.org/info/rfc7170>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <http://www.rfc-editor.org/info/rfc7296>.

Top      Up      ToC       Page 33 
   [RFC7613]  Saint-Andre, P. and A. Melnikov, "Preparation,
              Enforcement, and Comparison of Internationalized Strings
              Representing Usernames and Passwords", RFC 7613,
              DOI 10.17487/RFC7613, August 2015,
              <http://www.rfc-editor.org/info/rfc7613>.

   [RFC7648]  Perreault, S., Boucadair, M., Penno, R., Wing, D., and S.
              Cheshire, "Port Control Protocol (PCP) Proxy Function",
              RFC 7648, DOI 10.17487/RFC7648, September 2015,
              <http://www.rfc-editor.org/info/rfc7648>.

9.2.  Informative References

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
              March 2008, <http://www.rfc-editor.org/info/rfc5216>.

   [RFC5433]  Clancy, T. and H. Tschofenig, "Extensible Authentication
              Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
              RFC 5433, DOI 10.17487/RFC5433, February 2009,
              <http://www.rfc-editor.org/info/rfc5433>.

   [RFC5448]  Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
              Extensible Authentication Protocol Method for 3rd
              Generation Authentication and Key Agreement (EAP-AKA')",
              RFC 5448, DOI 10.17487/RFC5448, May 2009,
              <http://www.rfc-editor.org/info/rfc5448>.

Acknowledgements

   Thanks to Dan Wing, Prashanth Patil, Dave Thaler, Peter Saint-Andre,
   Carlos Pignataro, Brian Haberman, Paul Kyzivat, Jouni Korhonen,
   Stephen Farrell, and Terry Manderson for their valuable comments.

Top      Up      ToC       Page 34 
Authors' Addresses

   Margaret Cullen
   Painless Security
   356 Abbott Street
   North Andover, MA  01845
   United States

   Phone: +1 781 405 7464
   Email: margaret@painless-security.com
   URI:   http://www.painless-security.com


   Sam Hartman
   Painless Security
   356 Abbott Street
   North Andover, MA  01845
   United States

   Email: hartmans@painless-security.com
   URI:   http://www.painless-security.com

   Dacheng Zhang
   Beijing, China
   China

   Email: zhang_dacheng@hotmail.com


   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com