idnits 2.17.1 draft-ietf-iptel-trip-authen-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [4], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 111: '...cation attribute MUST implement the DS...' RFC 2119 keyword, line 124: '... An LS MAY include the signature att...' RFC 2119 keyword, line 129: '... An LS MAY be required (via configur...' RFC 2119 keyword, line 130: '... of certain attributes. An LS MAY use...' RFC 2119 keyword, line 148: '...ation attributes MUST NOT be propagate...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-iptel-trip-o4 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2373 (ref. '4') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Rosenberg 3 IPTEL Working Group dynamicsoft 4 draft-ietf-iptel-trip-authen-00.txt H. Salama 5 December 2000 Cisco Systems 6 Expires: June 2001 8 Authentication Attribute for TRIP 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as 'work in progress.' The list 22 of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document defines a new TRIP attribute, the Authentication 31 attribute. The Authentication attribute carries signatures for one, 32 or more, of the attributes carried in the same UPDATE message. The 33 purpose of these signatures is to guarantee the integrity of the data 34 being advertised across multiple TRIP hops. 36 Introduction 38 TRIP (Telephony Routing over IP) [1] is a protocol for routing VoIP 39 calls and locating egress gateways to non-IP networks for these 40 calls. TRIP [1] uses IPSec [2] to provide security between peer LSs 41 (TRIP Location Servers). This draft proposes a mechanisms to secure 42 the data advertised acress multiple TRIP LS hops. 44 In some situations, LSs may wish to verify the originator of an 45 attribute and that the contents of that attribute have not been 46 altered by other intermediate LSs. The Authentication attribute 47 carries signatures so that a receiving LS may validate particular 48 attributes. This is very useful for data being advertised across 49 multiple hops. If an LS trusts its peers, this doesn't imply that it 50 trusts the peer's peer. It is therefore beneficial to define a 51 mechanism for signing attributes and guaranteeing the integrity of 52 data advertised over multiple hops. 54 Attribute Definition 56 TRIP allows the originator of a particular attribute to include a 57 signature so that the receiver may validate the originator and 58 contents of the attribute. The Authentication attribute includes a 59 list of signatures for all signed attributes in the UPDATE message. 61 The authentication attribute has the following properties: 62 Mandatory: False. 63 Required Flags: Well-known. 64 Potential Flags: None. 65 TRIP Type Code: TBD. 67 Authentication Syntax 69 The Authentication attribute contains a list of Attribute Signatures. 70 Each attribute signature has the following format. 72 0 1 2 3 73 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 74 +---------------+---------------+--------------+----------------+ 75 | Attribute Signature Length | Originating ITAD | 76 +---------------+---------------+--------------+----------------+ 77 | Originating LS Name Length | Originating LS Name. (variable) 78 +---------------+---------------+--------------+----------------+ 79 | Attr Code | Auth Mech | Authentication Data. (variable) 80 +---------------+---------------+--------------+----------------+ 82 Figure 1: Attribute Signature Syntax 84 The Attribute Signature Length is the length of the entire attribute 85 signature in octets, including the length field. The Originating 86 ITAD indiactes the ITAD number of the originating LS. The originating 87 LS Name Length is the length of the originating LS's name in octets. 89 The Originating LS Name is either a legal Internet host domain name 90 or an IPv4 address using the textual representation defined in 91 Section 2.1 of RFC 1123 [3] or an IPv6 address using the textual 92 representation defined in Section 2.2 of RFC 2373 [4]. 94 The receiving LS uses the Originating LS Name to retrieve the 95 Originating LS's public key from DNS. 97 The Attribute code indicates the attribute this signature covers, and 98 the Authentication Mechanism indicates the algorithm used to compute 99 the Authentication Data. TRIP Defines the following Authentication 100 Mechanisms: 102 0 - Reserved 103 1 - DSA 104 2 - RSA 105 3 - 247 - Available 106 248 - 249 - For Private Use 107 250 - 255 - Reserved 109 The US Government Digital Signature Algorithm (DSA) the RSA Algorithm 110 are discussed in [5]. For interoperability purposes, any LS which 111 supports the Authentication attribute MUST implement the DSA 112 algorithm. Support for any other authentication mechanism is 113 optional. Additional Authentication Mechanisms can be registered with 114 IANA in the future. 116 The Authentication Mechanism is performed over the following fields 117 to compute the Authentication Data. The fields are considered in 118 this order. 119 1. Value of the ReachableRoutes attribute. 120 2. Value of the attribute given by the Attribute Code. 122 Route Origination and Authentication 124 An LS MAY include the signature attribute with routes that it 125 originates, covering any subset of the attributes of the route. 127 Route Selection and Authentication 129 An LS MAY be required (via configuration or some other means) to 130 verify the authenticity of certain attributes. An LS MAY use 131 attribute authentication when calculating the preference of a route. 132 Possible uses of the Authentication attribute include: 134 - Ignoring routes that do not contain authentication for a 135 particular attribute. 137 - Ignoring routes that for which attribute verification cannot be 138 performed due to unsupported authentication mechanisms or invalid 139 authentication data. 141 Other uses are also possible. 143 Aggregation and Authentication 145 Aggregation and Authentication are mutually exclusive. Since 146 attribute signatures cover the routes in the ReachableRoutes 147 field, aggregating routes together eliminates the validity of 148 signatures. Authentication attributes MUST NOT be propagated on 149 aggregated routes. The relative importance of authentication and 150 aggregation is an administrative decision. 152 Route Dissemination and Authentication 154 The Authentication attribute MUST be examined before propagating 155 to other LSs. For any attributes that have been changed by the 156 local LS, the LS should strip the Attribute Signature (if they 157 exist) from the Authentication attribute. The LS MAY insert its 158 own signatures into the Authentication attribute if it desires to 159 do so. The LS MAY propagate Attribute Signatures for attributes 160 that it does not alter. The decision to add or propagate 161 attribute signatures is a local policy decision. 163 IANA Considerations 165 Authentication Mechanism numbers 3 through 247 are available for 166 assignment through IANA (iana@iana.org). A request for assigning a 167 new Authentication mechanism should include a brief background on 168 the mechanism and a justification for the need to assign a number 169 for it. 171 Security Considerations 173 The draft proposes a mechanism to secure TRIP data advertises 174 across multiple LS hops. 176 References 178 [1] J. Rosenberg, H. Salama, and M. Squire, 'Telephony Routing over 179 IP,' IETF Internet Draft, draft-ietf-iptel-trip-o4.txt, work in 180 progress, November 2000. 182 [2] S. Kent and R. Atkinson, 'Security Architecture for the Internet 183 Protocol,' IETF RFC 2401, November 1998. 185 [3] R. Braden, 'Requirements for Internet Hosts -- Application and 186 Support,' IETF RFC 1123, October 1989. 188 [4] R. Hinden and S. Deering, 'IP Version 6 Addressing Architecture,' 189 IETF RFC 2373, July 1998. 191 [5] Bruce Schneier, 'Applied Cryptography: Protocols, Algorithms, and 192 Source Code in C,' Second Edition, 1996, John Wiley and Sons, ISBN 193 0-471-11709-9. 195 Author's Addresses 197 Jonathan Rosenberg 198 dynamicsoft 199 72 Eagle Rock Avenue 200 First Floor 201 East Hanover, NJ 07936 202 973-952-5000 203 email: jdrosen@dynamicsoft.com 205 Hussein F. Salama 206 Cisco Systems 207 Mail Stop SJ-6/3 208 170 W. Tasman Drive 209 San Jose, CA 95134 210 408-527-7147 211 email: hsalama@cisco.com