The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] (draft) end-2-end auth proposal for LDP (design)
Hi all!
I'm brasiliam, excuse about english erros :)!
I' implementing a draft proposal discuted in dec/2001 by this wkg.
<draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt> - I attached it.
I try contact authors without success in the last weeks. (They
know about my implementation and give me very important help when
I start this project in a few months ago).
The implementation is very closed (I'm changing source forge
linux ldp-portable implementation).
(I have a doubt for a long time) but now at implementation level
I conclude that its impossible implement the proposal like its
explained. It need probably some estructural changes.
Please I need help from experts on LDP operation, so this list is the
best place :)!
Basically this is the proposal scenario:
LER A LSR 1 LSR n LER B
| | | |
| auth LDP Request | | auth LDP Request |
|------->-------------|------->---------|------->-------------|
| auth LDP MAP | | auth LDP MAP |
|--------<------------|-------<---------|----------<----------|
| | | |
I firts list my doubts and after I explain the proposal, OK:
I have 2 doubts. Doubt (1) is critical (2) only to confirm:
1) when LERA send the Request for some FEC: It don't know that
LERB will be the egress OK?.
But the proposal consider that LERA know the
remote peer LERB when send the label request, and use it to
choose the correspondent mac-function-secretkey shared by
LERA-LERB, it is not possible in my vision?
On alternative solution would be create some tlv with meaning to
return the egress LSRid for some FEC (a new feature into LDP).
I'm not sure if it justifiable. Someone have ideas?
2) the proposal list as requirement ONLY ordered-control, but is
considering one request for every map, so "on-demand-distribution"
is implicit, so it would be a requirement, OK?
I try to explain as clean possible how the proposal works:
Application Scenario:
authenticate the FIRST LSP between Ingress and Egress end-to-end;
- destinated for non-adjacent LSRs (LERA-LERB) (without e2e TCP/LDP
session), so TCP Md5 signature option not apply.
- it requires LDP ordered control
- define 2 new TLVs: Mac-Tlv and Nonce-Tlv
- macTlv = srcLSRID + macdigest of (labelrequest/labelmap fields)
- MAC function (Mac-TLV) provide authentication and Integrity protection
- defined MAC fuction is Hmac-sha1
- NonceTLV: a every increase nonce value provide anti-replay protection.
- no confidenciality its provided
- intermediary LSRs only bypass (authentication Tlvs) end-to-end cause,
f-bit=1 and u-bit=1 into the new TLVs.
- Each LSR need to have locally a list with possible peers as follow:
PEER-LSR-ID1 : key_identifierA : mac_keyA
PEER-LSR-ID1 : key_identifierB : mac_keyB
PEER-LSR-ID2 : key_identifier : mac_key
Obs: with "key Identifier" peers could use one
key for reqw and other for map, for example.
- LDP msgs used to transport authentication tlvs:
Label_Request
Label_Mapping
Ldp_notification ( status_code="authentication failed" )
- The use of authentication is a local police matter of the LSR (mutual
agreement between the 2 LSRs who want setup the LSP).
The Process:
=============
1)LERA encode a label_request, insert a "nonce tlv" and a "mac tlv" and
sent it to LERB.
a) The MAC Tlv need to be the last tlv of the pdu.
b) LERA can determine which mac-key to use cause it knows the
remote LSR entity with wich it is setting up the LSP.
HERE MY DOUBT????????????????????
(HOW LERA KNOW IT, Request is based on FECs not destLSR-ID)
- LSR1..LSRn bypass the authentication tlvs cause f-bit=1 and u-bit=1.
This intermediary LSRs can't change the tlvs oder into the LDP_PDU;
- LERB receive the PDU and verify the authentication tlvs:
- determine the originator LSR,
- thanks the "key Identifier" can determine the respective local mac-key
- apply the same MAC function and match against received mac value:
* if match successfull: a authenticated "label_mapping" is returned
to LERA
* if match fail: a authenticated "label_notify" with status
"authentication failed" is returned to LERA.
- If LERA could successfull authenticate the label_mapping, the LSP is
established.
============================= complementar information ================
- New defined TLVs for LDP:
1) MAC 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| MAC (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| LSR Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC authentication value |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit: the Unknown-bit must be set to '1' because intermediate LSRs
that do not know this new TLV should ignore it and process the rest
of the message.
F-bit: the Forward-bit must be set to '1' because intermediate LSRs
that do not know this new TLV should transparently relay this TLV to
the next LSR.
Length: this field indicates the total length in bytes of the
following fields.
Key Identifier: this field identifies the shared secret key
used by the MAC generator so that the receiver can determine which
shared secret key to use to verify the MAC value, in case both
entities share more than one such secret key.
LSR Identifier: this field contains an identifier of the authenticating
entity to be used by the LSR receiver in the MAC verification process.
MAC authentication value: this field contains the MAC value generated
as described in "MAC generation", bellow.
The MAC TLV must be the last TLV of the LDP message.
2) NONCE 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| Nonce (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Nonce value |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit and F-bit: must be set to '1', same as in MAC TLV.
Length: this field indicates the length in bytes of the nonce value
field.
Nonce value: this field contains a unique value that must increase
for every message exchanged between two LSRs. A timestamp value is
an example of such an increasing counter. Both sides must keep track
of the last value used by the partner to be able to verify the
increasing nature of the nonce value received.
The Nonce TLV must appear prior to the MAC TLV in any place of the LDP PDU.
MAC generation
3) MAC generation/Verify procedures
The input into the MAC generation algorithm depends on the type of
message.
For LDP Label Request and Label Mapping messages, the input is the byte
stream built as described in the following figure (the Adapted Length
represents the actual length of this byte stream, not the length of
the real LDP Request message).
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| Message type | Adapted Length |
+-+-----------------------------+-------------------------------+
| key Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| LSR Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce TLV |
| |
+---------------------------------------------------------------+
| |
| FEC TLV |
+---------------------------------------------------------------+
For LDP Notification messages, the input is the byte stream built as
described in the following figure.
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| Notification | Adapted Length |
+-+-----------------------------+-------------------------------+
| key Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| LSR Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce TLV |
| |
+---------------------------------------------------------------+
| |
| Status TLV |
+---------------------------------------------------------------+
4) New Notification message "Authentication Failed" Status Code
A new Status Code value is required in the LDP Notification message
Status TLV. This code is used by an LSR to announce that a
previously received LDP message has failed authentication.
The U-bit and F-bit in the Status TLV must be set to '1' so as to
enable transparent relay of the Status TLV by LSRs.
The E-bit in the Status Code field of the Status TLV can be set to
'0' or '1' depending on the local policy of the LSR.
The F-bit in the Status Code field of the Status TLV MUST be set to
'1', in alignment with the F-bit at the Status TLV level.
Thanks,
Morvan.
INTERNET DRAFT Jeremy De Clercq
<draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt> Olivier Paridaens
Yves T'Joens
Peter De Schrijver
Alcatel
February, 2001
Expires August, 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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "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.
Abstract
The Label Distribution Protocol (LDP), as currently defined, makes
use of the TCP MD5 Signature option to protect (authentication and
integrity) the LDP traffic between two adjacent LSRs. This document
specifies extensions to LDP to enable end-to-end authentication
between non-adjacent LSR's (ie not directly connected via a TCP
connection) that are setting up an LSP. Two mechanisms are defined
that also provide integrity protection of the information carried
within LDP messages and protect against the malicious replay of LDP
messages. Both proposed mechanisms require ordered control LDP and
can also be applied to CR-LDP.
1. Introduction
De Schrijver, et al Expires May 2001 [Page 1]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
In its current state, LDP specifies the use of the TCP MD5 Signature
option in order to provide integrity and authentication of LDP
messages (in addition to protecting the TCP dialog itself). This
mechanism, apart from being considered rather weak because it makes
use of a simple keyed MD5 function, can only be used between two
adjacent LSRs exchanging LDP messages over a TCP connection. It does
not cover situations where LSRs exchange LDP messages via other
intermediate LSRs for setting up an LSP. It can be noted that other
technologies such as IPsec or TLS could adequately be used in place
of the TCP MD5 Signature option in order to provide LSR hop-by-hop
security.
This document proposes two mechanisms to enable such non-adjacent
LSRs to authenticate LDP messages mutually exchanged. The first
solution makes use of a digital signature attached to each LDP
message. This mechanism enables not only the receiving LER to
authenticate the LDP message but also intermediate LSR's to do so.
In addition, the proposed solution also provides integrity protection
of the information carried within LDP messages and anti-replay of
previous messages. The second proposed solution makes use of a
Message Authentication Code (MAC) attached to each LDP message. It
enables the receiving LER to authenticate the LDP message but not
intermediaries. It also provides integrity protection and anti-
replay.
As described more precisely below, both the digital signature-based
and MAC-based solutions provide data integrity and can be used to
protect LDP messages in broadcast contexts (basic discovery
mechanism). Finally, they also protect against replay attacks by
inserting a sequence number in each LDP message.
The mechanism described herein does not provide end-to-end
confidentiality, as Labelling information is not considered of a
confidential nature.
It requires ordered control LDP and can be applied to CR-LDP.
An example scenario is when LER A wants to set up a LSP with LER B.
Both LERs A and B make use of a MPLS backbone (illustrated by LSR 1
and LSR n in the figure below). LER A and LER B individually trust
the MPLS backbone provider but yet require mutual authentication
between both of them to set up the LSP. LER A uses ordered control
LDP and sends a LDP request message to the first LSR on the path
towards LER B. LER A adds authentication information to the LDP
request message so that LER B can verify the identity of LER A
requesting a LSP. When LER B receives this new LDP request message,
it can verify the signature or MAC and hence authenticate LER A. If
authentication succeeds, LER B will generate a LDP Map message (which
De Schrijver, et al Expires May 2001 [Page 2]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
could itself also be signed or MAC'ed by LER B). If authentication
fails, a LDP Notification message will be sent to report this
authentication failure (notification which can itself be signed or
MAC'ed by LER B). The schema below illustrates this scenario, where
LER B positively authenticates the LDP Request message and returns an
authenticated LDP Map message.
LER A LSR 1 LSR n LER B
| | | |
| | | |
| signed LDP Request | | signed LDP Request |
|------->-------------|------->---------|------->-------------|
| | | |
| | | |
| | | |
| | | |
| signed LDP MAP | | signed LDP MAP |
|--------<------------|-------<---------|----------<----------|
| | | |
2. Conventions
The keywords "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].
3. Digital Signature authentication method
This authentication method is based on the use of a digital signature
that is attached to each LDP message exchanged between both LERs.
This method is bi-directional as each LER can append a signature to
each LDP message it sends.
The input into the signature algorithm is basically made of parts of
the LDP message that are not subject to change end-to-end, as further
described in section 3.2.
Anti-replay is provided through the use of a sequence number. This
sequence number is added by the message originator to the LDP message
within a (new) Nonce TLV. The nonce value should take the form of an
ever increasing value such as a timestamp. Because this Nonce TLV is
covered by the signature value (see section 3.2.1 for details), it
cannot be changed "en route" and its increasing nature prohibits
replaying the same or another message with that same Nonce TLV.
3.1. Digital signature-based authentication TLV's
De Schrijver, et al Expires May 2001 [Page 3]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
3.1.1. Signature TLV
A new TLV is defined to carry the digital signature value.
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| Signature (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | ID length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AlgID Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Algorithm Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Signature value |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit: the Unknown-bit must be set to '1' because intermediate LSR's
that do not know this new TLV should ignore it and process the rest
of the message.
F-bit: the Forward-bit must be set to '1' because intermediate LSR's
that do not know this new TLV should transparently relay this TLV to
the next LSR.
Length: this field indicates the total length in bytes of the
following fields.
ID type: this field indicates the type of identifier carried in the
Identifier field. Possible types are defined in 9.2.
ID Length: this field indicates the length in bytes of the Identifier
value.
Identifier: this field contains an identifier of the signing entity
to be used by the LSR receiver in the signature verification process
(to obtain the corresponding certificate if not present in the LDP
message).
AlgID Length: this field indicates the length in bytes of the
De Schrijver, et al Expires May 2001 [Page 4]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
Algorithm Identifier field.
Algorithm Identifier: this field contains the signature algorithm
identifier. Possible algorihtms are presented in section 9.1.
Signature value: this field contains the signature value generated as
described in section 3.2.1. Its length can be deduced from the TLV
Length field and other fields lengths.
3.1.2. Certificate TLV
A new TLV is defined to carry a certificate.
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| Certificate (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Type | |
+-+-+-+-+-+-+-+-+ |
| |
| Certificate Value |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit: the Unknown-bit must be set to '1' because intermediate LSR's
that do not know this new TLV should ignore it and process the rest
of the message.
F-bit: the Forward-bit must be set to '1' because intermediate LSR's
that do not know this new TLV should transparently relay this TLV to
the next LSR.
Length: this field indicates the length in bytes of the Cert Type and
Certificate Value fields.
Cert Type: this field indicates the type of certificate carried in
this TLV. Possible values are defined in RFC 2408 [RFC2408] section
3.9.
Certificate Value: this field contains the certificate value.
The Certificate TLV must appear anywhere in the LDP message prior to
the Signature TLV. Several Certificate TLV's may be inserted into
the LDP message if felt necessary for the LSR receiver to be able to
verify the signature. Such a list of Certificate TLV's SHOULD be
inserted in a continuous sequence of TLV's (ie no other TLV type
De Schrijver, et al Expires May 2001 [Page 5]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
should appear in between).
3.1.3. Nonce TLV
A new TLV is defined to carry a nonce value.
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| Nonce (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Nonce value |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit: the Unknown-bit must be set to '1' because intermediate LSR's
that do not know this new TLV should ignore it and process the rest
of the message.
F-bit: the Forward-bit must be set to '1' because intermediate LSR's
that do not know this new TLV should transparently relay this TLV to
the next LSR.
Length: this field indicates the length in bytes of the nonce value
field.
Nonce value: this field contains a unique value that must increase
for every message exchanged between two LSRs. A timestamp value is
an example of such an increasing counter. Both sides must keep track
of the last value used by the partner to be able to verify the
increasing nature of the nonce value received.
The Nonce TLV must appear prior to the Signature TLV but not
necessarily next to.
3.2. Digital signature-based authentication procedure
3.2.1. Sender
When sending a LDP message, the originating LER creates and inserts a
Nonce TLV. Certificate TLV's are also inserted if felt adequate to
ease the receiving LER's signature verification. The Signature TLV
is finally appended to the LDP message after having calculated the
signature value. The Identifier field in the Signature TLV is used
to carry the signer's identity so that the receiving LSR can match
the certificate used for signature verification with the signer's
De Schrijver, et al Expires May 2001 [Page 6]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
identity.
The input into the signature algorithm depends on the type of
message.
For LDP Request and Label Mapping messages, the input is the byte
stream built as described in the following figure (the Adapted Length
represents the actual length of this byte stream, not the length of
the real LDP Request message). The Nonce TLV prevents re-using the
signature value for another LDP message.
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| Message type | Adapted Length |
+-+-----------------------------+-------------------------------+
| Nonce TLV |
| |
+---------------------------------------------------------------+
| |
| FEC TLV |
+---------------------------------------------------------------+
For LDP Notification messages, the input is the byte stream built as
described in the following figure.
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| Notification | Adapted Length |
+-+-----------------------------+-------------------------------+
| Nonce TLV |
| |
+---------------------------------------------------------------+
| |
| Status TLV |
+---------------------------------------------------------------+
3.2.2. Receiver
Upon receiving a LDP message, the destination LER verifies the
signature value present in the Signature TLV. Verification of the
signature can be made easier thanks to the use of certificates in
Certificate TLVs if present. The LSR should take care of ensuring
that any certificate taken from a Certificate TLV is still valid by
consulting some up-to-date CRL (Certificate Revocation List).
The input into the signature verification algorithm is built
De Schrijver, et al Expires May 2001 [Page 7]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
similarly to what is described in section 3.2.1 above.
3.2.3. Intermediary
This mechanism enables intermediate LSR's to authenticate LDP
messages being relayed. The intermediate LSR can indeed easily
verify the digital signature attached to the LDP message as long as
it has a copy of the sender's public key or can find it in a
repository or LDP message itself.
3.3. Discussion
This mechanism relies on the use of asymmetric public-key signature
algorithms such as RSA and DSA. Each LSR must therefore possess its
own key pair. Some form of Public Key Infrastructure (PKI) is also
necessary to create certificates for LSRs public keys and distribute
those certificates. Depending on the scenarios, a minimal form of
PKI may be to distribute the certificates within the LDP messages
themselves, as the Certificate TLV allows it. LSR's must also be
preconfigured with the (possibly several) certification Authority
(CA) root key(s).
This mechanism does not require a prior shared knowledge between both
LSRs (apart from having a common CA or being able to find a
certification path between their two CAs).
From the sender's perspective, the anti-replay mechanism will work if
the sender can ensure that the nonce it is using increases over time
(at least during the lifetime of the public key certificate currently
in use). If the nonce is based on an increasing sequence number, this
requires the sender to store the sequence number value last used in
non volatile memory so that a correct sequence number is used after a
reboot. If the nonce is based on a timestamp value, there is normally
an internal time clock in the sender system that should work over
reboot phases. If the internal clock system is volatile, a mechanism
such as NTP can be used by the sender to reset a valid time after
reboot. This will enable to maintain an increasing timestamp after a
reboot. If it cannot be ensured that the nonce value increases over a
reboot of the sender, the receiver will reject all messages received
that have a nonce value less than the last one it itself had received
before the sender reboots.
From the receiver's perspective, the anti-replay mechanism will work
if it is able to realize that the nonce value increases with each LDP
message received. In case of receiver system failure so that the last
nonce value received is forgotten, there is a potential for replay
attacks. An attacker can indeed send replayed messages without the
receiver detecting it. The replay opportunity will end when the
De Schrijver, et al Expires May 2001 [Page 8]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
receiver has received the next message from the genuine sender, as
this will set the nonce to the correct value (higher than any
previously used). If both the sender and the receiver fail at the
same time and both forget the current nonce value, it is possible for
an attacker to replay old messages without being detected.
It is a matter of local policy for a LSR (and implicitly mutual
agreement between both LSRs) to decide whether to use end-to-end
authentication when sending/receiving LDP messages with a particular
partner.
4. Message Authentication Code authentication method
This authentication method is based on the use of a MAC which is
attached to each LDP message sent by a LSR entity. This method is
bi-directional (both LSR entities can attach a MAC to their LDP
messages). Both LSR entities must obviously share a secret value that
is used to generate and verify the MAC attached to each message. The
same or different shared secrets can be used for both directions.
The input into the MAC function is basically made of the LDP message
contents itself and the shared secret value. This therefore provides
both message integrity and authentication.
Anti-replay is provided through the use of a sequence number. This
sequence number is added by the message sender to the LDP message
within a (new) Nonce TLV. The nonce value should take the form of an
ever increasing value such as a timestamp. Because this Nonce TLV is
covered by the MAC authentication value (see section 4.2.1 for
details), it cannot be changed "en route" and its increasing nature
prohibits replaying the same or another message with that same Nonce
TLV.
Both LSR entities must be pre-configured with the shared secret
value(s) and the name of the MAC algorithm to be used. This document
makes provision for the use of HMAC-derived functions.
4.1. MAC-based authentication TLVs
4.1.1. MAC TLV
A new TLV is defined to carry the MAC value.
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| MAC (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
De Schrijver, et al Expires May 2001 [Page 9]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | ID length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC authentication value |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit: the Unknown-bit must be set to '1' because intermediate LSRs
that do not know this new TLV should ignore it and process the rest
of the message.
F-bit: the Forward-bit must be set to '1' because intermediate LSRs
that do not know this new TLV should transparently relay this TLV to
the next LSR.
Length: this field indicates the total length in bytes of the
following fields.
Key Identifier: this 4-bytes field identifies the shared secret key
used by the MAC generator so that the receiver can determine which
shared secret key to use to verify the MAC value, in case both
entities share more than one such secret key.
ID type: this field indicates the type of identifier carried in the
Identifier field. Possible types are defined in 9.2.
ID Length: this field indicates the length in bytes of the Identifier
value.
Identifier: this field contains an identifier of the authenticating
entity to be used by the LSR receiver in the MAC verification
process.
MAC authentication value: this field contains the MAC value generated
as described in section 4.2.1.
The MAC TLV must be appended to the tail of the LDP message by the
sender.
4.1.2. Nonce TLV
A nonce TLV, as described in section 3.1.3, is used to carry a nonce
De Schrijver, et al Expires May 2001 [Page 10]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
value.
The Nonce TLV must appear prior to the MAC TLV but not necessarily
next to.
4.2. MAC-based authentication procedure
4.2.1. Sender
Before sending a LDP message, the sender creates a Nonce TLV which
can be inserted at any place in the LDP message and a MAC TLV which
will be appended at the tail of the message (as the last TLV). The
sender can determine which shared secret and MAC algorithm to use as
it knows with which remote LSR entity it is setting up an LSP. There
is consequently no need to carry a selector of the MAC algorithm
within the MAC TLV. A list of possible MAC algorithms is provided in
section 9.2.
As a general rule, lifetime of the shared secret key used between the
two LSRs must be smaller than the time required for the Nonce field
value to cycle; otherwise, an old message can be replayed. A nonce
field of 8 bytes length should be sufficient.
The input into the MAC generation algorithm depends on the type of
message.
For LDP Request and Label Mapping messages, the input is the byte
stream built as described in the following figure (the Adapted Length
represents the actual length of this byte stream, not the length of
the real LDP Request message).
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| Message type | Adapted Length |
+-+-----------------------------+-------------------------------+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | ID length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce TLV |
| |
+---------------------------------------------------------------+
| |
| FEC TLV |
De Schrijver, et al Expires May 2001 [Page 11]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
+---------------------------------------------------------------+
For LDP Notification messages, the input is the byte stream built as
described in the following figure.
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| Notification | Adapted Length |
+-+-----------------------------+-------------------------------+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | ID length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce TLV |
| |
+---------------------------------------------------------------+
| |
| Status TLV |
+---------------------------------------------------------------+
4.2.2. Receiver
When receiving a LDP message, the receiver can determine the actual
message originator by looking at the Identifier field in the MAC TLV.
The receiving LSR entity can then determine which shared secret and
MAC function to use for verifying the MAC value thanks to the
combination of the Identifier and the Key Identifier fields.
The LDP message contents to be used as input into the MAC function is
built in the same way as in 4.2.1.
If verification of the MAC value fails, a LDP Notification message is
returned with a code "authentication failed".
4.3. Discussion
This method enables to provide integrity and authentication of every
message exchanged between both non-adjacent LSR entities. It also
provides an anti-replay mechanism.
Both entities must be pre-configured with the shared secret value(s)
and the MAC algorithm to be used for generating/verifying the MAC in
both directions.
De Schrijver, et al Expires May 2001 [Page 12]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
This mechanism requires that the order of TLV's within the LDP
message is not changed by intermediate LSR entities.
From the sender's perspective, the anti-replay mechanism will work if
the sender can ensure that the nonce it is using increases over time
(at least during the lifetime of the shared secret currently in use).
If the nonce is based on an increasing sequence number, this requires
the sender to store the sequence number value last used in non
volatile memory so that a correct sequence number is used after a
reboot. If the nonce is based on a timestamp value, there is normally
an internal time clock in the sender system that should work over
reboot phases. If the internal clock system is volatile, a mechanism
such as NTP can be used by the sender to reset a valid time after
reboot. This will enable to maintain an increasing timestamp after a
reboot. If it cannot be ensured that the nonce value increases over a
reboot of the sender, the receiver will reject all messages received
that have a nonce value less than the last one it itself had received
before the sender reboots. To avoid such a situation when the sender
cannot guarantee that the nonce has increased after a reboot, the
sender can start a process of changing the shared key in use (which
may be a burden if manual key management is used).
From the receiver's perspective, the anti-replay mechanism will work
if it is able to realize that the nonce value increases with each LDP
message received. In case of receiver system failure so that the last
nonce value received is forgotten, there is a potential for replay
attacks. An attacker can indeed send replayed messages without the
receiver detecting it. The replay opportunity will end when the
receiver has received the next message from the genuine sender, as
this will set the nonce to the correct value (higher than any
previously used). If both the sender and the receiver fail at the
same time and both forget the current nonce value, it is possible for
an attacker to replay old messages without being detected.
It is a matter of local policy for a LSR (and implicitly mutual
agreement between both LSRs) to decide whether to use end-to-end
authentication when sending/receiving LDP messages with a particular
partner.
5. New Notification message "Authentication Failed" Status Code
A new Status Code value is required in the LDP Notification message
Status TLV. This code is used by an LSR to announce that a
previously received LDP message has failed authentication.
The U-bit and F-bit in the Status TLV must be set to '1' so as to
enable transparent relay of the Status TLV by LSRs.
De Schrijver, et al Expires May 2001 [Page 13]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
The E-bit in the Status Code field of the Status TLV can be set to
'0' or '1' depending on the local policy of the LSR.
The F-bit in the Status Code field of the Status TLV MUST be set to
'1', in alignment with the F-bit at the Status TLV level.
6. Editor's notes
- the signature algorithm identifier could be defined as a simple
integer, but it then requires some IANA registration.
7. IANA considerations
This document defines the following new TLVs for which a type value
is to be allocated :
- Signature TLV (section 3.1.1) - Certificate TLV (section 3.1.2) -
Nonce TLV (section 3.1.3) - MAC TLV (section 4.1.1)
Further, a new Status Code value ("Authentication Failed") is
required in the LDP Notification message Status TLV (section 5).
Within the newly defined Signature TLV (section 3.1.1), two
namespaces are to be administered by the IANA.
-- The "ID Type" is a 8 bit identifier for which the following values
have been reserved
ID Type Value
0 IPv4 address
1 IPv6 address
2 FQDN Option numbers 0-127 can be assigned by
the IANA under the condition "Specification Required". Option numbers
128-254 are site specific, while 255 is reserved.
-- The "Algorithm Identifier" follows the definition and registration
as within [RFC2459] section 7.2.2
8. Security considerations
This specification entirely deals with security issues.
9. Algorithms and identifiers
9.1. Signature algorithms
Implementations MUST support the use of DSA-with-SHA1 algorithm. The
exact encoding of the resulting signature and the algorithm
identifier (id-dsa-with-sha1) can be found in [RFC2459] section
De Schrijver, et al Expires May 2001 [Page 14]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
7.2.2.
9.2. MAC algorithms
Implementations MUST support the use of HMAC-MD5-96 and HMAC-SHA-1-96
algorithms.
9.3. Identifiers types
The following types of signer's identifiers are defined.
Value Type
IPv4 address 0
IPv6 address 1
FQDN 2
References
[LDP] Andersson et al., "LDP Specification", RFC 3031, January 2001.
[RFC2119]Bradner S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[RFC2408]Maughan et al., "Internet Security Association and Key Manage-
ment Protocol", RFC 2408, November 1998.
[RFC2459]Housley et al., "Internet X.509 Public Key Infrastructure Cer-
tificate and CRL Profile", RFC 2459, January 1999.
Acknowledgments
The authors would like to thank Peter De Schrijver for having produced
an original version of this document.
Authors' Addresses
Jeremy De Clercq
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: jeremy.de_clercq@alcatel.be
Olivier Paridaens
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: olivier.paridaens@alcatel.be
De Schrijver, et al Expires May 2001 [Page 15]
I-D draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt Mar 2001
Yves T'joens
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: yves.tjoens@alcatel.be
Peter De Schrijver
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
De Schrijver, et al Expires May 2001 [Page 16]
|
|