Internet Draft

Submitted to MPLS Working Group                       Peter De Schrijver
INTERNET DRAFT                                              Yves T'Joens
<draft-schrijvp-mpls-ldp-end-to-end-auth-00.txt>                 Alcatel

                                                           February 2000
                                                    Expires August, 2000

                   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 August 2000                   [Page 1]

Internet Draft draft-schrijvp-mpls-ldp-end-to-end-auth-00  February 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 Terminology


2.2 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.3 LDP challenge based authentication TLVs

To implement this two new TLV's and one new status code are necessary.



De Schrijver, et al.      Expires August 2000                   [Page 2]

Internet Draft draft-schrijvp-mpls-ldp-end-to-end-auth-00  February 2000


2.3.1 LDP challenge 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 (TBD)           |      Length                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                           Challenge                           |
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Challenge ID                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.3.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.4 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.



De Schrijver, et al.      Expires August 2000                   [Page 3]

Internet Draft draft-schrijvp-mpls-ldp-end-to-end-auth-00  February 2000


3. Digital signature based authentication for LDP

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 August 2000                   [Page 4]

Internet Draft draft-schrijvp-mpls-ldp-end-to-end-auth-00  February 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                        |
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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-
   06.txt, October 1999.


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

   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 August 2000                   [Page 5]