[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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

   The list of Internet-Draft Shadow Directories can be accessed at


   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.


   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

        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.


   [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

Author's Addresses

   Jonathan Rosenberg
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936
   email: jdrosen@dynamicsoft.com

   Hussein F. Salama
   Cisco Systems
   Mail Stop SJ-6/3
   170 W. Tasman Drive
   San Jose, CA 95134
   email: hsalama@cisco.com

Rosenberg, Salama                                               [Page 5]