INTERNET-DRAFT J. Rosenberg IPTEL Working Group dynamicsoft draft-ietf-iptel-trip-authen-00.txt H. Salama December 2000 Cisco Systems Expires: June 2001 Authentication Attribute for TRIP 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 This document defines a new TRIP attribute, the Authentication attribute. The Authentication attribute carries signatures for one, or more, of the attributes carried in the same UPDATE message. The purpose of these signatures is to guarantee the integrity of the data being advertised across multiple TRIP hops. Introduction TRIP (Telephony Routing over IP) [1] is a protocol for routing VoIP calls and locating egress gateways to non-IP networks for these calls. TRIP [1] uses IPSec [2] to provide security between peer LSs (TRIP Location Servers). This draft proposes a mechanisms to secure the data advertised acress multiple TRIP LS hops. In some situations, LSs may wish to verify the originator of an Rosenberg, Salama [Page 1]
Internet Draft TRIP Authentication December 2000 attribute and that the contents of that attribute have not been altered by other intermediate LSs. The Authentication attribute carries signatures so that a receiving LS may validate particular attributes. This is very useful for data being advertised across multiple hops. If an LS trusts its peers, this doesn't imply that it trusts the peer's peer. It is therefore beneficial to define a mechanism for signing attributes and guaranteeing the integrity of data advertised over multiple hops. Attribute Definition TRIP allows the originator of a particular attribute to include a signature so that the receiver may validate the originator and contents of the attribute. The Authentication attribute includes a list of signatures for all signed attributes in the UPDATE message. The authentication attribute has the following properties: Mandatory: False. Required Flags: Well-known. Potential Flags: None. TRIP Type Code: TBD. Authentication Syntax The Authentication attribute contains a list of Attribute Signatures. Each attribute signature has the following format. 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 +---------------+---------------+--------------+----------------+ | Attribute Signature Length | Originating ITAD | +---------------+---------------+--------------+----------------+ | Originating LS Name Length | Originating LS Name. (variable) +---------------+---------------+--------------+----------------+ | Attr Code | Auth Mech | Authentication Data. (variable) +---------------+---------------+--------------+----------------+ Figure 1: Attribute Signature Syntax The Attribute Signature Length is the length of the entire attribute signature in octets, including the length field. The Originating ITAD indiactes the ITAD number of the originating LS. The originating LS Name Length is the length of the originating LS's name in octets. The Originating LS Name is either a legal Internet host domain name Rosenberg, Salama [Page 2]
Internet Draft TRIP Authentication December 2000 or an IPv4 address using the textual representation defined in Section 2.1 of RFC 1123 [3] or an IPv6 address using the textual representation defined in Section 2.2 of RFC 2373 [4]. The receiving LS uses the Originating LS Name to retrieve the Originating LS's public key from DNS. The Attribute code indicates the attribute this signature covers, and the Authentication Mechanism indicates the algorithm used to compute the Authentication Data. TRIP Defines the following Authentication Mechanisms: 0 - Reserved 1 - DSA 2 - RSA 3 - 247 - Available 248 - 249 - For Private Use 250 - 255 - Reserved The US Government Digital Signature Algorithm (DSA) the RSA Algorithm are discussed in [5]. For interoperability purposes, any LS which supports the Authentication attribute MUST implement the DSA algorithm. Support for any other authentication mechanism is optional. Additional Authentication Mechanisms can be registered with IANA in the future. The Authentication Mechanism is performed over the following fields to compute the Authentication Data. The fields are considered in this order. 1. Value of the ReachableRoutes attribute. 2. Value of the attribute given by the Attribute Code. Route Origination and Authentication An LS MAY include the signature attribute with routes that it originates, covering any subset of the attributes of the route. Route Selection and Authentication An LS MAY be required (via configuration or some other means) to verify the authenticity of certain attributes. An LS MAY use attribute authentication when calculating the preference of a route. Possible uses of the Authentication attribute include: - Ignoring routes that do not contain authentication for a particular attribute. Rosenberg, Salama [Page 3]
Internet Draft TRIP Authentication December 2000 - Ignoring routes that for which attribute verification cannot be performed due to unsupported authentication mechanisms or invalid authentication data. Other uses are also possible. Aggregation and Authentication Aggregation and Authentication are mutually exclusive. Since attribute signatures cover the routes in the ReachableRoutes field, aggregating routes together eliminates the validity of signatures. Authentication attributes MUST NOT be propagated on aggregated routes. The relative importance of authentication and aggregation is an administrative decision. Route Dissemination and Authentication The Authentication attribute MUST be examined before propagating to other LSs. For any attributes that have been changed by the local LS, the LS should strip the Attribute Signature (if they exist) from the Authentication attribute. The LS MAY insert its own signatures into the Authentication attribute if it desires to do so. The LS MAY propagate Attribute Signatures for attributes that it does not alter. The decision to add or propagate attribute signatures is a local policy decision. IANA Considerations Authentication Mechanism numbers 3 through 247 are available for assignment through IANA (iana@iana.org). A request for assigning a new Authentication mechanism should include a brief background on the mechanism and a justification for the need to assign a number for it. Security Considerations The draft proposes a mechanism to secure TRIP data advertises across multiple LS hops. References [1] J. Rosenberg, H. Salama, and M. Squire, 'Telephony Routing over IP,' IETF Internet Draft, draft-ietf-iptel-trip-o4.txt, work in Rosenberg, Salama [Page 4]
Internet Draft TRIP Authentication December 2000 progress, November 2000. [2] S. Kent and R. Atkinson, 'Security Architecture for the Internet Protocol,' IETF RFC 2401, November 1998. [3] R. Braden, 'Requirements for Internet Hosts -- Application and Support,' IETF RFC 1123, October 1989. [4] R. Hinden and S. Deering, 'IP Version 6 Addressing Architecture,' IETF RFC 2373, July 1998. [5] Bruce Schneier, 'Applied Cryptography: Protocols, Algorithms, and Source Code in C,' Second Edition, 1996, John Wiley and Sons, ISBN 0-471-11709-9. Author's Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 973-952-5000 email: jdrosen@dynamicsoft.com Hussein F. Salama Cisco Systems Mail Stop SJ-6/3 170 W. Tasman Drive San Jose, CA 95134 408-527-7147 email: hsalama@cisco.com Rosenberg, Salama [Page 5]
