Internet Draft Submitted to MPLS Working Group Peter De Schrijver INTERNET DRAFT Yves T'Joens <draft-schrijvp-mpls-ldp-end-to-end-auth-01.txt> Alcatel July 2000 Expires January, 2001 End to end authentication for LDP Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This draft defines extensions to LDP to allow end to end authentication between the LER initiating a LSP and the LER terminating a LSP. The extensions require ordered control LDP and can also be applied to CR-LDP. 1. Introduction This draft proposes 2 extensions to allow the terminating LER of an LSP to authenticate the initiating LER. The first extension is a challenge based authentication method. The second authentication method is based on digital signatures. De Schrijver, et al. Expires January 2001 [Page 1] Internet Draft draft-schrijvp-mpls-ldp-end-to-end-auth-01 July 2000 1.1 Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Challenge based authentication for LDP This section describes a challenge based authentication method for LDP. The authenticator sends a nonce to the authenticee. The authenticee encrypts this nonce using a shared secret and sends it back to the authenticator. The authenticator can then check if the authenticee knows the shared secret. 2.1 LDP challenge based authentication scenario overview LER A LSR 1 LER B | | | | LDP Request | LDP Request | |------------>----------|----------->-----------| | | | | LDP Notify | LDP Notify | | authentication failed | authentication failed | | challenge | challenge | |------------<----------|-----------<-----------| | | | | LDP Request | LDP Request | | encrypted challenge | encrypted challenge | |------------>----------|----------->-----------| | | | | LDP map | LDP map | | authentication ok | authentication ok | |------------<----------|-----------<-----------| LER A sends a LDP request to LSR 1 destined for LER B without any authentication information. LER B will reply with a notify message indicating the authentication failed. This message will also include a new nonce. LER A will now retry the LSP setup by sending a LDP request containing the the encrypted nonce. LER B will verify the encrypted nonce and reply with a LDP map message indicating the authentication was successfull. 2.2 LDP challenge based authentication TLVs To implement this two new TLV's and one new status code are necessary. 2.2.1 LDP challenge TLV De Schrijver, et al. Expires January 2001 [Page 2] Internet Draft draft-schrijvp-mpls-ldp-end-to-end-auth-01 July 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| Challenge (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Challenge | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2.2 LDP challenge response TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| Challenge response (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Challenge Response | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Username | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.3 Procedures 1) In response to an unauthenticated LDP request message, the authenticator sends a LDP notify message to the authenticee containing a challenge TLV. The challenge TLV contains a nonce and a Challenge ID, which will be send back by the authenticee. It is used by the authenticator to correlate the response. 2) In response to a LDP notify message indicating authentication is required, the authenticee should send a LDP request with a challenge response containing the authenticee's name to identify the shared secret used to encrypt the challenge and the challenge ID to allow the authenticator to correlate this response. 3. Digital signature based authentication for LDP De Schrijver, et al. Expires January 2001 [Page 3] Internet Draft draft-schrijvp-mpls-ldp-end-to-end-auth-01 July 2000 This section describes a digital signature based end-to-end authentication method for LDP. Each LER signs the messages it sends. This allows the receiver to verify the sender's identity. 3.1 Scenario overview LER A LSR 1 LER B | | | | LDP Request | LDP Request | | Digital signature | Digital signature | |------------>----------|----------->-----------| | | | | LDP map | LDP map | | authentication ok | authentication ok | |------------<----------|-----------<-----------| 3.2 LDP digital signature based authentication TLV's To implement LDP digital signature based authentication two new TLV's are necessary. 1 TLV to carry the digital certificate identifying the sender and 1 TLV to carry the signature consisting of a secure hash of the "fixed part" of the message encrypted using the private key. The "fixed part" of the message consists of aal fields carried unmodified from ingress LER to egress LER. For a Label Request and Label mapping messages these fields are : Message Type and the FEC TLV. The message receiver can then verify the integrity of these fields by recalculating the secure hash over the fixed part and comparing it with the received hash. 3.2.1 Digital certificate TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Certificate (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Certificate type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Certificate data | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.2 Digital signature TLV De Schrijver, et al. Expires January 2001 [Page 4] Internet Draft draft-schrijvp-mpls-ldp-end-to-end-auth-01 July 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Signature (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Signature data | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 Open Issues 4.1 Status TLV As currently defined in [LDP] the status TLV cannot be easily extended. More specifically every LSR must understand all status codes to be able to take the correct action. Example : assume we introduce a new status code to signal authentication failure as described in 2.3 in the LERs. If the LSRs don't understand this new status code, they won't be able to take the correct action when a notification message is received in response to a label request. 6. IANA Considerations New values for the challenge and challenge response TLV type fields have to be assigned. Also a new status code needs to be defined to identify authentication failure. 7. Security Considerations Security considerations are treated in the document. 8. References [LDP] Andersson, et al., "LDP Specification", draft-ietf-mpls-ldp- 07.txt, June 2000. 9. Contacts Peter De Schrijver Alcatel Corporate Research Center Francis Wellesplein 1, 2018 Antwerp, Belgium Phone : +32 3 240 8569 E-mail : peter.de_schrijver@alcatel.be De Schrijver, et al. Expires January 2001 [Page 5] Internet Draft draft-schrijvp-mpls-ldp-end-to-end-auth-01 July 2000 Yves T'joens Alcatel Corporate Research Center Francis Wellesplein 1, 2018 Antwerp, Belgium Phone : +32 3 240 7890 E-mail : yves.tjoens@alcatel.be De Schrijver, et al. Expires January 2001 [Page 6]