Internet DRAFT - draft-bhatia-zhang-pim-auth-extension
draft-bhatia-zhang-pim-auth-extension
Network Working Group M. Bhatia
Internet-Draft Alcatel-Lucent
Intended status: Experimental D. Zhang
Expires: September 29, 2013 Huawei
B. Joshi
Infosys Ltd.
March 28, 2013
In-Band Authentication Extension for Protocol Independent Multicast
draft-bhatia-zhang-pim-auth-extension-03
Abstract
Existing security mechanisms for the Protocol Independent Multicast -
Sparse Mode (PIM-SM) routing protocol mandates the use of IPsec to
provide message authenticity and integrity. This draft proposes an
embedded authentication mechanism to facilitate data origin
authentication and integrity verification for PIM packets in the
cases where IPsec cannot be applied.
Requirements Language
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].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 29, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bhatia, et al. Expires September 29, 2013 [Page 1]
Internet-Draft Authentication Extension for PIM March 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3
3. PIM Security Association . . . . . . . . . . . . . . . . . . . 5
4. PIM Packet Processing . . . . . . . . . . . . . . . . . . . . 6
4.1. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 6
4.2. Outbounding Packet Processing . . . . . . . . . . . . . . 7
4.3. Inbounding Packet Processing . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Register packet processing . . . . . . . . . . . . . . . . 9
5.2. Inter-Session Replay Attack Issue . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Bhatia, et al. Expires September 29, 2013 [Page 2]
Internet-Draft Authentication Extension for PIM March 2013
1. Introduction
[RFC5796] describes the methods of using the IP security (IPsec)
Encapsulating Security Payload (ESP) [RFC4303] or the Authentication
Header (AH) [RFC4302] (which is optional) to protect the authenticity
and integrity of the link-local messages of Protocol Independent
Multicast - Sparse Mode (PIM-SM)[RFC4601]. [RFC5796] mandates the
application of manual key management mechanisms and provide optional
support for an automated group key management mechanism. However,
the procedures for implementing automated group key management are
not specified.
It has been clarified in [I-D.bhatia-karp-pim-gap-analysis] that
without the support of automated group key management mechanisms, the
PIM packets protected by IPsec will be vulnerable to both inter-
session and inner-session replay attacks. In addition, the poor
scalability of manual keying may cause deployment issues in many
typical scenarios. This document proposes few changes in the PIM
header which helps in carrying authentication data along with the
usual PIM packet. The PIM packet contains all the essential
inforamtion for data origin authentication and message integrity
verification without the support of IPsec.
In this solution, it is assumed that manual keying is performed while
the automatic key management mechanisms are not precluded. A
strictly increasing sequence number is adopted to address the replay
attack issues. However, the work of addressing the scalability
issues imposed by manual keying is out of scope of this draft.
2. Proposed Solution
This document adds some more fields in PIM packet to carry the
authentication information. Figure 1 illustrates the format of a PIM
packet that carries authentication information.
Bhatia, et al. Expires September 29, 2013 [Page 3]
Internet-Draft Authentication Extension for PIM March 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|PIM Ver| Type |A| Reserved | PIM Message Length | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth
| Cryptographic Sequence Number (High Order 32 Bits) | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| |
~ PIM Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
Figure 1. Format of a PIM packet carrying authentication information
PIM Ver: PIM Version number is 2.
Type: Types for specific PIM messages. PIM types are defined in
[RFC4601].
Auth bit: If 'Auth' bit is 1, it means the PIM packet is carrying
authentication information. If 'Auth' bit is 0, it means the PIM
packet is not carrying authentication information and such a
packet should be handled as specified in [RFC4601].
Reserved: Set to zero on transmission. Ignored upon receipt.
PIM Message Length: A 16-bit field that contains the length of the
PIM message. This length does not include the length of the PIM
header, PIM auth header and authentication data.
Key ID: A 16-bit field that identifies the secret key and the
algorithm used to create the authentication data.
Auth Data Len: A 16-bit field that identifies the length of the
trailing authentication data field.
Cryptographic Sequence Number: A 64-bit strictly increasing
sequence number that is used to guard against replay attacks. The
64-bit sequence number MUST be incremented for every PIM packet
carrying authentication. Upon reception, the sequence number MUST
Bhatia, et al. Expires September 29, 2013 [Page 4]
Internet-Draft Authentication Extension for PIM March 2013
be greater than the sequence number in the last PIM packet
accepted from the PIM router sending the packet. Otherwise, the
PIM packet is considered a replayed packet and dropped. PIM
routers implementing this specification SHOULD use available
mechanisms to preserve the sequence number's strictly increasing
property for the deployed life of the PIM router (including cold
restarts). Techniques such as sequence number space partitioning
and non-volatile storage preservation can be used but are beyond
the scope of this specification.
PIM Message: PIM message as specified in [RFC4601].
Authentication Data: Variable length authentication data. This
field carries the digest for the protocol packet.
A PIM packet carrying authentication information does not need
checksum for integrity check. So 'checksum' field has been replaced
with 'PIM Message Length' in a PIM packet carrying authentication
information.
3. PIM Security Association
A PIM Security Association (SA) consists of a set of parameters for
PIM routers to correctly generate or verify PIM packets carrying
authentication information. In manual keying, it is the
responsibility of network operators to generate and deploy PIM SAs
amongst PIM routers appropriately to ensure the routers can exchange
PIM messages.
The parameters associated with a PIM SA:
o Key Identifier (Key ID) : A 16-bit unsigned integer which is used
to uniquely identify a PIM SA within a PIM domain.
o Authentication Algorithm: This parameter is used to indicate
authentication algorithm to be used with the PIM SA. The value of
this parameter can be implementation specific. The following
algorithms SHOULD be supported: HMAC-SHA-1, HMAC-SHA-256, HMAC-
SHA-384, and HMAC-SHA-512.
o Key: The value of this parameter denotes the cryptographic key
associated with the key ID. The length of this key is determined
by the algorithm specified in the PIM SA.
o Key Start Accept: The time after which a PIM router will accept a
packet if it is created with this PIM SA.
Bhatia, et al. Expires September 29, 2013 [Page 5]
Internet-Draft Authentication Extension for PIM March 2013
o Key Start Generate: The time after which a PIM router will begin
using this PIM SA for PIM packet generation.
o Key Stop Generate: The time after which a PIM router will stop
using this PIM SA for PIM packet generation.
o Key Stop Accept: The time after which a PIM router will refuse to
accept a packet if it is generated with this PIM SA.
4. PIM Packet Processing
4.1. Cryptographic Aspects
In the algorithm description below, the following nomenclature, which
is consistent with [FIPS-198], is used:
H is the specific hashing algorithm (e.g. SHA-256).
K is the Authentication Key for the PIM security association.
Ko is the cryptographic key used with the hash algorithm.
B is the block size of H, measured in octets rather than bits.
Note that B is the internal block size, not the hash size.
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in octets rather than bits.
XOR is the exclusive-or operation.
Opad is the hexadecimal value 0x5c repeated B times.
Ipad is the hexadecimal value 0x36 repeated B times.
Apad is a value which is the same length as the hash output or
message digest. If the packet is transported upon IPv6, the first 16
octets contain the IPv6 source address followed by the hexadecimal
value 0x878FE1F3 repeated (L-16)/4 times. If the packet is
transported upon IPv4, the first 4 octets contain the IPv4 source
address followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4
times.
1. Preparation of the Key
Bhatia, et al. Expires September 29, 2013 [Page 6]
Internet-Draft Authentication Extension for PIM March 2013
In this application, Ko is always L octets long.
If the Authentication Key (K) is L octets long, then Ko is equal
to K. If the Authentication Key (K) is more than L octets long,
then Ko is set to H(K). If the Authentication Key (K) is less
than L octets long, then Ko is set to the Authentication Key (K)
with zeros appended to the end of the Authentication Key (K) such
that Ko is L octets long.
2. First Hash
First, the PIM packet's Authentication Data field is filled with
the value Apad.
Then, a First-Hash, also known as the inner hash, is computed as
follows:
If the PIM packet is a Register packet
First-Hash = H(Ko XOR Ipad || (PIM Packet - Data Part))
else
First-Hash = H(Ko XOR Ipad || (PIM Packet))
The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets;
for SHA-384, 48 octets; and for SHA-512, 64 octets.
3. Second Hash
Then a second hash, also known as the outer hash, is computed as
follows:
Second-Hash = H(Ko XOR Opad || First-Hash)
4. Result
The resulting Second-Hash becomes the authentication data that is
added in the PIM packet. The length of the authentication data is
always identical to the message digest size of the specific hash
function H that is being used.
4.2. Outbounding Packet Processing
If embedded authentication is enabled, sender first finds an
appropriate PIM security association (SA) to be used for this packet.
Following processing is done:
Bhatia, et al. Expires September 29, 2013 [Page 7]
Internet-Draft Authentication Extension for PIM March 2013
o It first prepares the PIM header and PIM auth header as follows:
* PIM version is set to 2
* Type field is set to the PIM message type that is being sent.
* Auth bit is set to 1.
* Reserved field is set to 0.
* Key ID is set to the key-id from PIM SA
* Auth Data Len is set to the length of the Authentication Data
field which is determined based on the algorithm specified in
the selected SA.
* The sequence number for the selected SA is increased and the
new value is inserted into the Sequence Number field.
o It then populates the PIM message that is to be sent out. As
length of the PIM message is now known, it is updated in the PIM
header.
o The Authentication Data field is set to Apad and then sender
generates the authentication data as described in Section 4.1 for
the PIM packet. Calculate authentication data is inserted in the
Authentication data field.
After this PIM packet is sent out on the idenfitied interface.
4.3. Inbounding Packet Processing
A router identifies a received PIM packet is carrying authentication
data by examining the 'Auth' bit in the PIM header. If the 'Auth'
bit is 1, it means the PIM packet is carrying embedded authentication
information. Following processing is done:
o Find the PIM SA for the Key ID available in PIM auth header in the
PIM packet. If no valid PIM SA is found for this packet or the
PIM SA is not in its valid period, receiver MUST discard the
packet and SHOULD log an error event.
o If the cryptographic sequence number of the packet is less than or
equal to the last sequence number received from the same PIM
router, receiver MUST discard the packet and SHOULD log an error
event.
Bhatia, et al. Expires September 29, 2013 [Page 8]
Internet-Draft Authentication Extension for PIM March 2013
o Find the Auth data len expected from the PIM SA and compare it
against the Auth Data Len in the packet. If the two do not match,
receiver MUST discard the packet and SHOULD log an error event.
o Calculate the PIM message length using total packet length from IP
header and Auth Data Len from PIM Auth Header. Compare it with
the PIM message length in PIM header. If the two do not match,
receiver MUST discard the packet and SHOULD log an error event.
o Receiver stores the Authentication Data from packet locally. It
then fills the Authentication Data field with Apad. Then the
receiver calculates the authentication data for the PIM packet as
described in Section 4.1. The calculated authentication data is
then compared with the received authentication data in PIM packet.
If the two do not match, reciever MUST discard the packet and
SHOULD log an error event. If the two matches, PIM message is
passed for further processing.
5. Security Considerations
5.1. Register packet processing
The solution proposed in this draft only intends to secure PIM
singaling packets. The efforts for protecting data packets
transported among PIM routers is out of scope. Therefore, for a
register packet, only PIM header, PIM Auth Header, the B field and
the N field are secured while the Multicast data packet part is not
protected.
5.2. Inter-Session Replay Attack Issue
When a router is rebooted, the sequence number will be re-
initialzed. This will cause a problem. When a PIM router receive a
hello message with a changed GenID and an re-inialized sequence
number, it is difficult for the receiver to distinguish this message
from a replay attack. The soltuion proposed in this document is
subject to this problem. However, the experience in
[I-D.ietf-ospf-security-extension-manual-keying] can be used to
address this problem. In the solution proposed in
[I-D.ietf-ospf-security-extension-manual-keying], there is a reboot
counter maintained in non-volatile memory which is increased by 1
after every reboot. The reboot count value is set into the first 32
bits of the sequence number. Therefore, even after a restart, the
sequence number will still be increased.
Bhatia, et al. Expires September 29, 2013 [Page 9]
Internet-Draft Authentication Extension for PIM March 2013
6. Acknowledgements
We would like to thank Stig Venaas for his kind review and comments
on this document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[I-D.bhatia-karp-pim-gap-analysis]
Bhatia, M., "Analysis of Protocol Independent Multicast
Sparse Mode (PIM-SM) Security According to KARP Design
Guide", draft-bhatia-karp-pim-gap-analysis-00 (work in
progress), April 2011.
[I-D.ietf-ospf-security-extension-manual-keying]
Bhatia, M., Hartman, S., Zhang, D., and A. Lindem,
"Security Extension for OSPFv2 when using Manual Key
Management",
draft-ietf-ospf-security-extension-manual-keying-04 (work
in progress), February 2013.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and
Confidentiality in Protocol Independent Multicast Sparse
Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.
Bhatia, et al. Expires September 29, 2013 [Page 10]
Internet-Draft Authentication Extension for PIM March 2013
Authors' Addresses
Manav Bhatia
Alcatel-Lucent
Email: manav.bhatia@alcatel-lucent.com
Dacheng Zhang
Huawei
Email: zhangdacheng@huawei.com
Bharat Joshi
Infosys Ltd.
Email: bharat_joshi@infosys.com
Bhatia, et al. Expires September 29, 2013 [Page 11]
