idnits 2.17.1 draft-ietf-sidr-bgpsec-pki-profiles-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6487, but the abstract doesn't seem to directly say this. It does mention RFC6487 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6487, updated by this document, for RFC5378 checks: 2006-06-09) -- 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.) -- The document date (August 13, 2014) is 3516 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-sidr-bgpsec-algs-08 == Outdated reference: A later version (-05) exists of draft-ietf-sidr-rfc6485bis-01 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-09 -- Obsolete informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR Working Group M. Reynolds 3 Internet-Draft IPSw 4 Updates: 6487 (if approved) S. Turner 5 Intended status: Standards Track IECA, Inc. 6 Expires: February 14, 2015 S. Kent 7 BBN 8 August 13, 2014 10 A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, 11 and Certification Requests 12 draft-ietf-sidr-bgpsec-pki-profiles-08 14 Abstract 16 This document defines a standard profile for X.509 certificates for 17 the purposes of supporting validation of Autonomous System (AS) paths 18 in the Border Gateway Protocol (BGP), as part of an extension to that 19 protocol known as BGPSEC. BGP is a critical component for the proper 20 operation of the Internet as a whole. The BGPSEC protocol is under 21 development as a component to address the requirement to provide 22 security for the BGP protocol. The goal of BGPSEC is to design a 23 protocol for full AS path validation based on the use of strong 24 cryptographic primitives. The End-Entity (EE) certificates specified 25 by this profile are issued under Resource Public Key Infrastructure 26 (RPKI) Certification Authority (CA) certificates, containing the AS 27 Identifier Delegation extension, to routers within the Autonomous 28 System (AS). The certificate asserts that the router(s) holding the 29 private key are authorized to send out secure route advertisements on 30 behalf of the specified AS. This document also profiles the 31 Certificate Revocation List (CRL), profiles the format of 32 certification requests, and specifies Relying Party certificate path 33 validation procedures. The document extends the RPKI; therefore, 34 this documents updates the RPKI Resource Certificates Profile (RFC 35 6487). 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on February 14, 2015. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 1. Introduction 71 This document defines a profile for X.509 end-entity (EE) 72 certificates [RFC5280] for use in the context of certification of 73 Autonomous System (AS) paths in the Border Gateway Protocol Security 74 (BGPSEC) protocol. Such certificates are termed "BGPSEC Router 75 Certificates". The holder of the private key associated with a 76 BGPSEC Router Certificate is authorized to send secure route 77 advertisements (BGPSEC UPDATEs) on behalf of the AS named in the 78 certificate. That is, a router holding the private key may send to 79 its BGP peers, route advertisements that contain the specified AS 80 number as the last item in the AS PATH attribute. A key property 81 that BGPSEC will provide is that every AS along the AS PATH can 82 verify that the other ASes along the path have authorized the 83 advertisement of the given route (to the next AS along the AS PATH). 85 This document is a profile of [RFC6487], which is a profile of 86 [RFC5280], and it updates [RFC6487]. It establishes requirements 87 imposed on a Resource Certificate that is used as a BGPSEC Router 88 Certificate, i.e., it defines constraints for certificate fields and 89 extensions for the certificate to be valid in this context. This 90 document also profiles the Certificate Revocation List (CRL) and 91 certification requests. Finally, this document specifies the Relying 92 Party (RP) certificate path validation procedures. 94 1.1. Terminology 96 It is assumed that the reader is familiar with the terms and concepts 97 described in "A Profile for X.509 PKIX Resource Certificates" 98 [RFC6487], "BGPSEC Protocol Specification" 99 [I-D.ietf-sidr-bgpsec-protocol], "A Border Gateway Protocol 4 (BGP- 100 4)" [RFC4271], "BGP Security Vulnerabilities Analysis" [RFC4272], 101 "Considerations in Validating the Path in BGP" [RFC5123], and 102 "Capability Advertisement with BGP-4" [RFC5492]. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in 107 [RFC2119]. 109 2. Describing Resources in Certificates 111 Figure 1 depicts some of the entities in the RPKI and some of the 112 products generated by RPKI entities. IANA issues a Certification 113 Authority (CA) to a Regional Internet Registries (RIR). The RIR, in 114 turn, issues a CA certificate to an Internet Service Provider (ISP). 115 The ISP in turn issues End-Entity (EE) Certificates to itself as well 116 as CRLs. These certificates are referred to as "Resource 117 Certificates", and are profiled in [RFC6487]. The [RFC6480] 118 envisioned using Resource Certificates to generate Manifests 119 [RFC6486] and Route Origin Authorizations (ROAs) [RFC6482]. ROAs and 120 Manifests also include the Resource Certificates used to sign them. 122 +---------+ +------+ 123 | CA Cert |---| IANA | 124 +---------+ +------+ 125 \ 126 +---------+ +-----+ 127 | CA Cert |---| RIR | 128 +---------+ +-----+ 129 \ 130 +---------+ +-----+ 131 | CA Cert |---| ISP | 132 +---------+ +-----+ 133 / | | | 134 +-----+ / | | | +-----+ 135 | CRL |--+ | | +---| ROA | 136 +-----+ | | +-----+ 137 | | +----------+ 138 +----+ | +---| Manifest | 139 +-| EE |---+ +----------+ 140 | +----+ 141 +-----+ 143 Figure 1: RPKI and BGPsec Hierarchies 145 This document defines another type of Resource Certificate, which is 146 referred to as a "BGPSEC Router Certificate". The purpose of this 147 certificate is explained in Section 1 and falls within the scope of 148 appropriate uses defined within [RFC6484]. The issuance of BGPSEC 149 Router Certificates has minimal impact on RPKI CAs because the RPKI 150 CA certificate and CRL profile remain unchanged (i.e., they are as 151 specified in [RFC6487]). Further, the algorithms used to generate 152 RPKI CA certificates that issue the BGPSEC Router Certificates and 153 the CRLs necessary to check the validity of the BGPSEC Router 154 Certificates remain unchanged (i.e., they are as specified in 155 [I-D.ietf-sidr-rfc6485bis]). The only impact is that the RPKI CAs 156 will need to be able to process a profiled certificate request (see 157 Section 5) signed with algorithms found in 158 [I-D.ietf-sidr-bgpsec-algs]. The use of BGPSEC Router Certificates 159 in no way affects RPKI RPs that process Manifests and ROAs because 160 the public key found in the BGPSEC Router Certificate is only ever 161 used to verify the signature on the BGPSEC certificate request (only 162 CAs process these) and the signature on a BGPSEC Update Message 163 [I-D.ietf-sidr-bgpsec-protocol] (only BGPSEC routers process these). 165 Only the differences between this profile and the profile in 166 [RFC6487] are listed. Note that BGPSEC Router Certificates are EE 167 certificates and as such there is no impact on process described in 168 [RFC6916]. 170 3. Updates to RFC 6487 172 3.1. BGPSEC Router Certificate Fields 174 A BGPSEC Router Certificate is a valid X.509 public key certificate, 175 consistent with the PKIX profile [RFC5280], containing the fields 176 listed in this section. This profile is also based on [RFC6487] and 177 only the differences between this profile and the profile in 178 [RFC6487] are listed. 180 3.1.1. Subject 182 This field identifies the router to which the certificate has been 183 issued. Consistent with [RFC6487], only two attributes are allowed 184 in the Subject field: common name and serial number. Moreover, the 185 only common name encoding options that are supported are 186 printableString and UTF8String. For BGPSEC Router Certificates, it 187 is RECOMMENDED that the common name attribute contain the literal 188 string "ROUTER-" followed by the 32-bit AS Number [RFC3779] encoded 189 as eight hexadecimal digits and that the serial number attribute 190 contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) 191 encoded as eight hexadecimal digits. If more than one certificate 192 for an AS is issued (i.e., more than one router gets a certificate 193 for the AS and hence the private key is shared among more than one 194 router), the choice of the router ID used in Subject name is at the 195 discretion of the Issuer. Note that router IDs are not guaranteed to 196 be unique across the Internet, and thus the Subject name in a BGPSEC 197 Router Certificate issued using this convention also is not 198 guaranteed to be unique across different issuers. However, each 199 certificate issued by an individual CA MUST contain a Subject name 200 that is unique within that context. 202 3.1.2. Subject Public Key Info 204 Refer to section 3.1 of [I-D.ietf-sidr-bgpsec-algs]. 206 3.1.3. BGPSEC Router Certificate Version 3 Extension Fields 208 The following X.509 V3 extensions MUST be present (or MUST be absent, 209 if so stated) in a conforming BGPSEC Router Certificate, except where 210 explicitly noted otherwise. No other extensions are allowed in a 211 conforming BGPSEC Router Certificate. 213 3.1.3.1. Basic Constraints 215 BGPSEC speakers are EEs; therefore, the Basic Constraints extension 216 must not be present, as per [RFC6487]. 218 3.1.3.2. Extended Key Usage 220 BGPSEC Router Certificates MUST include the Extended Key Usage (EKU) 221 extension. As specified, in [RFC6487] this extension MUST be marked 222 as non-critical. This document defines one EKU for BGPSEC Router 223 Certificates: 225 id-kp OBJECT IDENTIFIER ::= 226 { iso(1) identified-organization(3) dod(6) internet(1) 227 security(5) mechanisms(5) pkix(7) kp(3) } 229 id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } 231 Relying Parties MUST require the extended key usage extension be 232 present in a BGPSEC Router Certificate. If multiple KeyPurposeId 233 values are included, the relying parties need not recognize all of 234 them, as long as the required KeyPurposeId value is present. BGPSEC 235 RPs MUST reject certificates that do not contain the BGPSEC Router 236 EKU even if they include the anyExtendedKeyUsage OID defined in 237 [RFC5280]. 239 3.1.3.3. Subject Information Access 241 This extension is not used in BGPSEC Router Certificates. It MUST be 242 absent. 244 3.1.3.4. IP Resources 246 This extension is not used in BGPSEC Router Certificates. It MUST be 247 absent. 249 3.1.3.5. AS Resources 251 Each BGPSEC Router Certificate MUST include the AS Resource 252 Identifier Delegation extension, as specified in section 4.8.11 of 253 [RFC6487]. The AS Resource Identifier Delegation extension MUST 254 include only one AS number, and the "inherit" element MUST NOT be 255 specified. 257 3.2. BGPSEC Router Certificate Request Profile 259 Refer to section 6 of [RFC6487]. The only differences between this 260 profile and the profile in [RFC6487] are: 262 o The ExtendedKeyUsage extension request MUST be included and the CA 263 MUST honor the request; 265 o The SubjectPublicKeyInfo and PublicKey fields are specified in 266 [I-D.ietf-sidr-bgpsec-algs]; and, 268 o The attributes field contains the ASN extension with exactly one 269 ASN. 271 o The request is signed with the algorithms specified in 272 [I-D.ietf-sidr-bgpsec-algs]. 274 3.3. BGPSEC Router Certificate Validation 276 The validation procedure used for BGPSEC Router Certificates is 277 identical to the validation procedure described in Section 7 of 278 [RFC6487]. The exception is that the constraints applied come from 279 this specification (e.g., in step 3: the certificate contains all the 280 field that must be present - refers to the fields that are required 281 by this specification). 283 {spt: should the algorithm fail if there's more than one in the 284 cert?} 286 The differences are as follows: 288 o BGPSEC Router Certificates MUST include the BGPSEC EKU defined in 289 Section 3.1.3.1. 291 o BGPSEC Router Certificates MUST NOT include the SIA extension. 293 o BGPSEC Router Certificates MUST NOT include the IP Resource 294 extension. 296 o BGPSEC Router Certificates MUST include the AS Resource Identifier 297 Delegation extension and only one AS number. 299 o BGPSEC Router Certificate MUST include the "Subject Public Key 300 Info" described in [I-D.ietf-sidr-bgpsec-algs] as it updates 301 [I-D.ietf-sidr-rfc6485bis]. 303 NOTE: The cryptographic algorithms used by BGPSEC routers are found 304 in [I-D.ietf-sidr-bgpsec-algs]. Currently, the algorithms specified 305 in [I-D.ietf-sidr-bgpsec-algs] and [I-D.ietf-sidr-rfc6485bis] are 306 different. BGPSEC RPs will need to support algorithms that are 307 needed to validate BGPSEC signatures as well as the algorithms that 308 are needed to validate signatures on BGPSEC certificates, RPKI CA 309 certificates, and RPKI CRLs. 311 4. Design Notes 313 The BGPSEC Router Certificate profile is based on the Resource 314 Certificate profile as specified in [I-D.ietf-sidr-rfc6485bis]. As a 315 result, many of the design choices herein are a reflection of the 316 design choices that were taken in that prior work. The reader is 317 referred to [RFC6484] for a fuller discussion of those choices. 319 One design choice made by this document is to include one AS number 320 per certificate. Simplicty is the driving rationale. If a router 321 supports more than one AS, the router can simply be issued another 322 certificate though the impact on the router is that additional secure 323 storage may be needed for additional private keys. 325 5. Security Considerations 327 The Security Considerations of [RFC6487] apply. 329 A BGPSEC certificate will fail RPKI validation, as defined in 330 [RFC6487], because the algorithm suite is different. Consequently, a 331 RP needs to identify the EKU before applying the correspondent 332 validation. 334 A BGPSEC Router Certificate is an extension of the RPKI [RFC6480] to 335 encompass routers. It is a building block of the larger BGPSEC 336 security protocol used to validate signatures on BGPSEC Signature- 337 Segment origination of Signed-Path segments 338 [I-D.ietf-sidr-bgpsec-protocol]. Thus its essential security 339 function is the secure binding of one or more AS numbers to a public 340 key, consistent with the RPKI allocation/assignment hierarchy. 342 6. IANA Considerations 344 None. 346 7. Acknowledgements 348 We would like to thanks Geoff Huston, George Michaelson, and Robert 349 Loomans for their work on [RFC6487], which this work is based on. In 350 addition, the efforts of Steve Kent and Matt Lepinski were 351 instrumental in preparing this work. Additionally, we'd like to 352 thank Roque Gagliano, Sandra Murphy, Geoff Huston, Randy Bush, and 353 Rob Austein for their reviews and comments. Finally, we'd like to 354 thank Russ Housley for assigning us an OID for the ASN.1 module. 356 8. References 358 8.1. Normative References 360 [I-D.ietf-sidr-bgpsec-algs] 361 Turner, S., "BGP Algorithms, Key Formats, & Signature 362 Formats", draft-ietf-sidr-bgpsec-algs-08 (work in 363 progress), July 2014. 365 [I-D.ietf-sidr-rfc6485bis] 366 Huston, G. and G. Michaelson, "The Profile for Algorithms 367 and Key Sizes for use in the Resource Public Key 368 Infrastructure", draft-ietf-sidr-rfc6485bis-01 (work in 369 progress), March 2014. 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, March 1997. 374 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 375 Addresses and AS Identifiers", RFC 3779, June 2004. 377 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 378 Protocol 4 (BGP-4)", RFC 4271, January 2006. 380 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 381 Housley, R., and W. Polk, "Internet X.509 Public Key 382 Infrastructure Certificate and Certificate Revocation List 383 (CRL) Profile", RFC 5280, May 2008. 385 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 386 X.509 PKIX Resource Certificates", RFC 6487, February 387 2012. 389 8.2. Informative References 391 [I-D.ietf-sidr-bgpsec-protocol] 392 Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- 393 sidr-bgpsec-protocol-09 (work in progress), July 2014. 395 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 396 4272, January 2006. 398 [RFC5123] White, R. and B. Akyol, "Considerations in Validating the 399 Path in BGP", RFC 5123, February 2008. 401 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 402 with BGP-4", RFC 5492, February 2009. 404 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 405 Secure Internet Routing", RFC 6480, February 2012. 407 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 408 Origin Authorizations (ROAs)", RFC 6482, February 2012. 410 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 411 Policy (CP) for the Resource Public Key Infrastructure 412 (RPKI)", BCP 173, RFC 6484, February 2012. 414 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 415 "Manifests for the Resource Public Key Infrastructure 416 (RPKI)", RFC 6486, February 2012. 418 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 419 Procedure for the Resource Public Key Infrastructure 420 (RPKI)", BCP 182, RFC 6916, April 2013. 422 Appendix A. ASN.1 Module 424 BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1) 426 security(5) mechanisms(5) pkix(7) id-mod(0) 428 id-mod-bgpsec-eku(84) } 430 DEFINITIONS EXPLICIT TAGS ::= 432 BEGIN 434 -- EXPORTS ALL -- 436 -- IMPORTS NOTHING -- 438 -- OID Arc -- 440 id-kp OBJECT IDENTIFIER ::= { 441 iso(1) identified-organization(3) dod(6) internet(1) 442 security(5) mechanisms(5) kp(3) } 444 -- BGPSEC Router Extended Key Usage -- 446 id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } 448 END 450 Appendix B. Example BGPSEC Router Certificate 452 Appendix C. Example BGPSEC Router Certificate Request 454 Appendix D. Change Log 456 Please delete this section prior to publication. 458 D.1. Changes from sidr-bgpsec-pki-profiles-07 to sidr-bgpsec-pki- 459 profiles-08 461 Changed references to RFC 6485 to [I-D.ietf-sidr-rfc6485bis] and 462 added OIDs for ASN.1 module. Certificate and certification request 463 restricted to contain one ASN. 465 D.2. Changes from sidr-bgpsec-pki-profiles-06 to sidr-bgpsec-pki- 466 profiles-07 468 Added text to multiple AS numbers in a single certificate. Updated 469 reference to RFC 6916. 471 D.3. Changes from sidr-bgpsec-pki-profiles-05 to sidr-bgpsec-pki- 472 profiles-06 474 Keep alive version. 476 D.4. Changes from sidr-bgpsec-pki-profiles-04 to sidr-bgpsec-pki- 477 profiles-05 479 Keep alive version. 481 D.5. Changes from sidr-bgpsec-pki-profiles-03 to sidr-bgpsec-pki- 482 profiles-04 484 In s2.1, removed the phrase "another BGPSEC Router Certificate (only 485 BGPSEC routers process these)" because the BGPSEC certificates are 486 only ever EE certificates and they're never used to verify another 487 certificate only the PDUs that are signed. 489 Added new s3.1.3.1 to explicitly state that EE certificates are only 490 ever EE certs. 492 D.6. Changes from sidr-bgpsec-pki-profiles-02 to sidr-bgpsec-pki- 493 profiles-03 495 Updated s3.3 to clarify restrictions on path validation procedures 496 are in this specification (1st para was reworded). 498 Updated s3.3 to point to s3.1.3.1 for BGPSEC EKU (thanks Tom). 500 D.7. Changes from sidr-bgpsec-pki-profiles-01 to sidr-bgpsec-pki- 501 profiles-02 503 Updated references. 505 D.8. Changes from sidr-bgpsec-pki-profiles-00 to sidr-bgpsec-pki- 506 profiles-01 508 Added an ASN.1 Module and corrected the id-kp OID in s3.1.3.1. 510 D.9. Changes from turner-bgpsec-pki-profiles-02 to sidr-bgpsec-pki- 511 profiles-00 513 Added this change log. 515 Amplified that a BGPSEC RP will need to support both the algorithms 516 in [I-D.ietf-sidr-bgpsec-algs] for BGPSEC and the algorithms in 517 [RFC6487] for certificates and CRLs. 519 Changed the name of AS Resource extension to AS Resource Identifier 520 Delegation to match what's in [RFC3779]. 522 D.10. Changes from turner-bgpsec-pki-profiles -01 to -02 524 Added text in Section 2 to indicate that there's no impact on the 525 procedures defined in [RFC6916]. 527 Added a security consideration to let implementers know the BGPSEC 528 certificates will not pass RPKI validation [RFC6487] and that keying 529 off the EKU will help tremendously. 531 D.11. Changes from turner-bgpsec-pki-profiles -00 to -01 533 Corrected Section 2 to indicate that CA certificates are also RPKI 534 certificates. 536 Removed sections and text that was already in [RFC6487]. This will 537 make it easier for reviewers to figure out what is different. 539 Modified Section 6 to use 2119-language. 541 Removed requirement from Section 6 to check that the AS # in the 542 certificate is the last number in the AS path information of each BGP 543 UPDATE message. Moved to [I-D.ietf-sidr-bgpsec-protocol]. 545 Authors' Addresses 547 Mark Reynolds 548 Island Peak Software 549 328 Virginia Road 550 Concord, MA 01742 551 USA 553 Email: mcr@islandpeaksoftware.com 555 Sean Turner 556 IECA, Inc. 557 Suite 106 558 Fairfax, VA 22031 559 USA 561 Phone: +1-703-628-3180 562 Email: turners@ieca.com 564 Steve Kent 565 Raytheon BBN Technologies 566 10 Moulton St. 567 Cambridge, MA 02138 568 USA 570 Email: kent@bbn.com