idnits 2.17.1 draft-ietf-radext-crypto-agility-requirements-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 May 2011) is 4743 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-radext-dynamic-discovery-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADEXT Working Group D. Nelson (Editor) 3 INTERNET-DRAFT Elbrys Networks, Inc. 4 Category: Informational 5 Expires: November 2, 2011 6 1 May 2011 8 Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) 9 draft-ietf-radext-crypto-agility-requirements-06.txt 11 Abstract 13 This memo describes the requirements for a crypto-agility solution 14 for Remote Authentication Dial-In User Service (RADIUS). 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 2, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.2 Requirements Language . . . . . . . . . . . . . . . . . . . 3 71 1.3. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.4 Publication Process . . . . . . . . . . . . . . . . . . . . 4 73 2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 4 74 3. The Current State of RADIUS Security . . . . . . . . . . . . . 5 75 4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 76 4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 6 77 4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 6 78 4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 8 79 4.4. Interoperability and Change Control . . . . . . . . . . . . 9 80 4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 9 81 4.6. Applicability of Automated Key Management Requirements . . 9 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 87 8.2. Informative References . . . . . . . . . . . . . . . . . 11 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 92 1.1. General 94 This memo describes the requirements for a crypto-agility solution 95 for Remote Authentication Dial-In User Service (RADIUS). This memo, 96 when approved, reflects the consensus of the RADIUS Extensions 97 (RADEXT) Working Group of the IETF as to the features, properties and 98 limitations of the crypto-agility work item for RADIUS. It also 99 defines the term "crypto-agility" as used in this context, and 100 provides the motivations for undertaking and completing this work. 102 The requirements defined in this memo have been developed based on e- 103 mail messages posted to the RADEXT WG mailing list, which may be 104 found in the archives of that list. The purpose of framing the 105 requirements in this memo is to formalize and memorialize them for 106 future reference, and to bring them explicitly to the attention of 107 the IESG and the IETF Community, as we proceed with this work. 109 1.2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 A RADIUS crypto-agility solution is not compliant with this 116 specification if it fails to satisfy one or more of the MUST or MUST 117 NOT statements. A solution that satisfies all the MUST, MUST NOT, 118 SHOULD, and SHOULD NOT statements is said to be "unconditionally 119 compliant"; one that satisfies all the MUST and MUST NOT statements 120 but not all the SHOULD or SHOULD NOT requirements is said to be 121 "conditionally compliant". 123 1.3. The Charge 125 At the IETF-66 meeting, the RADEXT WG was asked by members of the 126 Security Area Directorate to undertake the action item to prepare a 127 formal description of a crypto-agility work item, and corresponding 128 milestones in the RADEXT Charter. After consultation with one of the 129 Security Area Directors, Russ Housley, text was initially proposed on 130 the RADEXT WG mailing list on October 26, 2006. That text reads as 131 follows: 133 The RADEXT WG will review the security requirements for crypto- 134 agility in IETF protocols, and identify the deficiencies of the 135 existing RADIUS protocol specifications against these 136 requirements. Specific attention will be paid to RFC 4962 137 [RFC4962]. 139 The RADEXT WG will propose one or more specifications to remediate 140 any identified deficiencies in the crypto-agility properties of 141 the RADIUS protocol. The known deficiencies include the issue of 142 negotiation of substitute algorithms for the message digest 143 functions, the key-wrap functions, and the password-hiding 144 function. Additionally, at least one mandatory to implement 145 cryptographic algorithm will be defined in each of these areas, as 146 required. 148 1.4. Publication Process 150 RADIUS [RFC2865] is a widely deployed protocol that has attained 151 Draft Standard status based on multiple independent interoperable 152 implementations. Therefore it is desirable that a high level of 153 interoperability be maintained for crypto-agility solutions. 155 To ensure that crypto-agility solutions published on the standards 156 track are well specified and interoperable, the RADEXT WG has adopted 157 a two phase process for standards-track publication of crypto-agility 158 solutions. 160 In the initial phase, crypto-agility solutions adopted by the working 161 group will be published as Experimental. These documents should 162 contain a description of the implementations and experimental 163 deployments in progress, as well as an evaluation of the proposal 164 against the requirements described in this document. 166 The working group will then select proposals to advance on the 167 standards track. Criteria to be used include evaluation of the 168 proposal against the requirements, summary of the experimental 169 deployment experience and evidence of multiple interoperable 170 implementations. 172 2. A Working Definition of Crypto-Agility 174 A generalized definition of crypto-agility was offered up at the 175 RADEXT WG session during IETF-68. Crypto-Agility is the ability of a 176 protocol to adapt to evolving cryptography and security requirements. 177 This may include the provision of a modular mechanism to allow 178 cryptographic algorithms to be updated without substantial disruption 179 to fielded implementations. It may provide for the dynamic 180 negotiation and installation of cryptographic algorithms within 181 protocol implementations (think of Dynamic-Link Libraries (DLL)). 183 In the specific context of the RADIUS protocol and RADIUS 184 implementations, crypto-agility may be better defined as the ability 185 of RADIUS implementations to automatically negotiate cryptographic 186 algorithms for use in RADIUS exchanges, including the algorithms used 187 to integrity protect and authenticate RADIUS packets and to hide 188 RADIUS Attributes. This capability covers all RADIUS message types: 189 Access-Request/Response, Accounting-Request/Response, CoA/Disconnect- 190 Request/Response, and Status-Server. Negotiation of cryptographic 191 algorithms MAY occur within the RADIUS protocol, or within a lower 192 layer such as the transport layer. 194 Since RADIUS is a request/response protocol, the ability to negotiate 195 cryptographic algorithms within a single RADIUS exchange is 196 inherently limited. While a RADIUS request can provide a list of 197 supported cryptographic algorithms which can selected for use within 198 a response, prior to the receipt of a response, the cryptographic 199 algorithms utilized to provide security services within the request 200 will need to be determined a-priori. 202 Proposals MUST NOT introduce new capabilities negotiation features 203 into the RADIUS protocol and crypto-agility solutions SHOULD NOT 204 require changes to the RADIUS operational model as defined in "RADIUS 205 Design Guidelines" [RFC6158] Section 3.1 and Appendix A.4. 206 Similarly, a proposal SHOULD focus on the crypto-agility problem and 207 nothing else. For example, proposals SHOULD NOT require new 208 attribute formats and SHOULD be compatible with the guidance provided 209 in [RFC6158] Section 2.3. 211 Acceptable solutions for determining the mechanisms to be used within 212 a request include manual configuration as well as backward compatible 213 negotiation techniques such as those described in Section 4.3. 214 Solutions for determining the mechanisms to be used in a response 215 include manual configuration and "advertise and select" mechanisms 216 (e.g. selection within the response from mechanisms advertised in a 217 request). 219 3. The Current State of RADIUS Security 221 RADIUS packets, as defined in [RFC2865], are protected by an MD5 222 message integrity check (MIC), within the Authenticator field of 223 RADIUS packets other than Access-Request [RFC2865] and Status-Server 224 [RFC5997]. The Message-Authenticator Attribute utilizes HMAC-MD5 to 225 authenticate and integrity protect RADIUS packets. 227 While RADIUS does not support confidentiality of entire packets, 228 various RADIUS attributes support encrypted (also known as "hidden") 229 values, including: User-Password (defined in [RFC2865] Section 5.2), 230 Tunnel-Password (defined in [RFC2868] Section 3.5), and various 231 Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE- 232 Recv-Key attributes (defined in [RFC2548] Section 2.4). Generally 233 speaking, the hiding mechanism uses a stream cipher based on a key 234 stream from an MD5 digest. Attacks against this mechanism are 235 described in "RADIUS Support for EAP" [RFC3579] Section 4.3.4. 237 "Updated Security Considerations for the MD5 Message-Digest and the 238 HMAC-MD5 Algorithms" [RFC6151] discusses security considerations for 239 use of the MD5 and HMAC-MD5 algorithms. While the advances in MD5 240 collisions do not immediately compromise the use of MD5 or HMAC-MD5 241 for the purposes used within RADIUS absent knowledge of the RADIUS 242 shared secret, the progress toward compromise of MD5's basic 243 cryptographic assumptions has resulted in the deprecation of MD5 244 usage in a variety of applications. As noted in [RFC6151] Section 2: 246 MD5 is no longer acceptable where collision resistance is required 247 such as digital signatures. It is not urgent to stop using MD5 in 248 other ways, such as HMAC-MD5; however, since MD5 must not be used 249 for digital signatures, new protocol designs should not employ 250 HMAC-MD5. 252 4. The Requirements 254 4.1. Overall Solution Approach 256 RADIUS crypto-agility solutions are not restricted to utilizing 257 technology described in existing RFCs. Since RADIUS over IPsec is 258 already described in "RADIUS and IPv6" [RFC3162] Section 5 and 259 [RFC3579] Section 4.2, this technique is already available to those 260 who wish to use it. Therefore, it is expected that proposals will 261 utilize other techniques. 263 4.2. Security Services 265 Proposals MUST support the negotiation of cryptographic algorithms 266 for per-packet integrity/authentication protection. Proposals also 267 MUST support per-packet replay protection for all RADIUS message 268 types. Crypto-agility solutions MUST specify mandatory-to-implement 269 cryptographic algorithms for each defined mechanism. 271 Crypto-agility solutions MUST avoid security compromise, even in 272 situations where the existing cryptographic algorithms utilized by 273 RADIUS implementations are shown to be weak enough to provide little 274 or no security (e.g. in event of compromise of the legacy RADIUS 275 shared secret). Included in this would be protection against bidding 276 down attacks. In analyzing the resilience of a crypto-agility 277 solution, it can be assumed that RADIUS requesters and responders can 278 be configured to require the use of new secure algorithms in the 279 event of a compromise of existing cryptographic algorithms or the 280 legacy RADIUS shared secret. 282 Guidance on acceptable algorithms can be found in [NIST-SP800-131A]; 283 it is RECOMMENDED that mandatory-to-implement cryptographic 284 algorithms be chosen from among those classified as "Acceptable" with 285 no known deprecation date. 287 It is RECOMMENDED that solutions provide support for confidentiality, 288 either by supporting encryption of entire RADIUS packets or by 289 encrypting individual RADIUS attributes. Proposals supporting 290 confidentiality MUST support the negotiation of cryptographic 291 algorithms for encryption. 293 Solutions providing for encryption of entire RADIUS packets need not 294 also provide support for encryption of individual RADIUS attributes. 295 Solutions providing for encryption of individual RADIUS attributes 296 are REQUIRED to provide support for improving the confidentiality of 297 existing encrypted (sometimes referred to as "hidden") attributes as 298 well as encrypting attributes (such as location attributes) that are 299 currently transmitted in cleartext. 301 In addition to the goals referred to above, [RFC4962] Section 2 302 describes additional security requirements, which translate into the 303 following requirements for RADIUS crypto-agility solutions: 305 Strong, fresh session keys 306 RADIUS crypto-agility solutions are REQUIRED to generate fresh 307 session keys for use between the RADIUS client and server. In 308 order to prevent the disclosure of one session key from aiding an 309 attacker in discovering other session keys, RADIUS crypto-agility 310 solutions are RECOMMENDED to support Perfect Forward Secrecy (PFS) 311 with respect to session keys negotiated between the RADIUS client 312 and server. 314 Limit key scope 315 In order to enable a NAS and RADIUS server to exchange confidential 316 information such as keying material without disclosure to third 317 parties, it is RECOMMENDED that a RADIUS crypto-agility solution 318 support X.509 certificates for authentication between the NAS and 319 RADIUS server. Manual configuration as well as automated discovery 320 mechanisms such as NAI-based Dynamic Peer Discovery [RADYN] can be 321 used to enable direct NAS-RADIUS server communications. Support 322 for end-to-end confidentiality of RADIUS attributes is not 323 required. 325 For compatibility with existing operations, RADIUS crypto-agility 326 solutions SHOULD also support pre-shared key credentials. However, 327 support for direct communications between the NAS and RADIUS server 328 is not required when pre-shared key credentials are used. 330 4.3. Backwards Compatibility 332 Solutions MUST demonstrate backward compatibility with existing 333 RADIUS implementations. That is, an implementation that supports 334 both crypto-agility and legacy mechanisms MUST be able to talk with 335 legacy RADIUS clients and servers (using the legacy mechanisms). 337 While backward compatibility is needed to ease the transition between 338 legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is 339 only appropriate prior to the compromise of those mechanisms. After 340 legacy mechanisms have been compromised, secure algorithms MUST be 341 used, so that backward compatibility is no longer possible. 343 In order to enable a request to be handled both by legacy as well as 344 crypto-agile implementations, a request can be secured with legacy 345 algorithms and in addition attributes providing security services 346 using more secure algorithms can be included. This approach allows a 347 RADIUS packet to be processed by legacy implementations as well as by 348 crypto-agile implementations, and does not result in additional 349 response delays. 351 In this approach to backward compatibility, legacy mechanisms are 352 initially used between crypto-agile implementations. However, if the 353 responder indicates support for crypto-agility, future requests can 354 omit use of legacy mechanisms. 356 Probing techniques can be used avoid the use of legacy algorithms 357 between crypto-agile implementations. An initial request can omit 358 use of legacy mechanisms, and if a response is received, then the 359 recipient can be assumed to be crypto-agile and future requests to 360 that recipient can utilize secure mechanisms. Similarly, the 361 responder can assume that the requester supports crypto-agility and 362 can prohibit use of legacy mechanisms in future requests. 364 If a response is not received, in the absence of information 365 indicating responder support for crypto-agility (such as pre- 366 configuration or previous receipt of a crypto-agile response), a new 367 request can be composed utilizing legacy mechanisms. 369 Since legacy implementations not supporting crypto-agility will 370 silently discard requests not protected by legacy algorithms rather 371 than returning an error, repeated requests may be required to 372 distinguish lack of support for crypto-agility from packet loss or 373 other failure conditions. As a result, probing techniques can delay 374 initial communication between crypto-agile requesters and legacy 375 responders. This can be addressed by upgrading the responders (e.g. 376 RADIUS servers) first. 378 4.4. Interoperability and Change Control 380 Proposals MUST indicate a willingness to cede change control to the 381 IETF. 383 Crypto-agility solutions MUST be interoperable between independent 384 implementations based purely on the information provided in the 385 specification. 387 4.5. Scope of Work 389 Crypto-agility solutions MUST apply to all RADIUS packet types, 390 including Access-Request, Access-Challenge, Access-Reject, Access- 391 Accept, Accounting-Request, Accounting-Response, Status-Server and 392 CoA/Disconnect messages. 394 Since it is expected that the work will occur purely within RADIUS or 395 in the transport, message data exchanged with Diameter SHOULD NOT be 396 affected. 398 Proposals MUST discuss any inherent assumptions about, or limitations 399 on, client/server operations or deployment and SHOULD provide 400 recommendations for transition of deployments from legacy RADIUS to 401 crypto-agile RADIUS. Issues regarding cipher-suite negotiation, 402 legacy interoperability and the potential for bidding down attacks, 403 SHOULD be among these discussions. 405 4.6. Applicability of Automated Key Management Requirements 407 "Guidelines for Cryptographic Key Management" [RFC4107] provides 408 guidelines for when automated key management is necessary. At the 409 IETF-70 meeting, and leading up to that meeting, the RADEXT WG 410 debated whether or not RFC 4107 would require a RADIUS Crypto-Agility 411 solution to feature Automated Key Management (AKM). The working 412 group determined that AKM was not inherently required for RADIUS 413 based on the following points: 415 o RFC 4107 requires AKM for protocols that involve O(n^2) keys. 416 This does not apply to RADIUS deployments, which require O(n) 417 keys. 419 o Requirements for session key freshness can be met without AKM, 420 for example, by utilizing a pre-shared key along with an exchange 421 of nonces. 423 o RADIUS does not require the encryption of large amounts of data in 424 a short time. 426 o Organizations already have operational practices to manage 427 existing RADIUS shared secrets to address key changes required 428 as a result of personnel changes. 430 o The crypto-agility solution can avoid use cryptographic modes of 431 operation such as a counter mode cipher that require frequent key 432 changes. 434 However, the same time, it is recognized that features recommended in 435 Section 4.2 such as support for perfect forward secrecy and direct 436 transport of keys between a NAS and RADIUS server can only be 437 provided by a solution supporting AKM. As a result, support for 438 Automated Key Management is RECOMMENDED within a RADIUS crypto- 439 agility solution. 441 Also, automated key management is REQUIRED for RADIUS crypto-agility 442 solutions that use cryptographic modes of operation that require 443 frequent key changes. 445 5. IANA Considerations 447 This document makes no request of IANA. 449 6. Security Considerations 451 Potential attacks against the RADIUS protocol are described in 452 [RFC3579] Section 4.1, and details of known exploits as well as 453 potential mitigations are discussed in [RFC3579] Section 4.3. 455 This specification describes the requirements for new cryptographic 456 protection mechanisms, including the modular selection of algorithms 457 and modes. Therefore, the subject matter of this memo is all about 458 security. 460 7. Acknowledgments 462 Thanks to all the reviewers and contributors, including Bernard 463 Aboba, Pasi Eronen, Joe Salowey and Glen Zorn. 465 8. References 467 8.1. Normative References 469 [NIST-SP800-131A] 470 Barker, E. and A. Roginsky, "Transitions: Recommendation for 471 Transitioning the Use of Cryptographic Algorithms and Key 472 Lengths", NIST SP-800-131A, January 2011. 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, March 1997. 477 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 478 Authentication Dial In User Service (RADIUS)", RFC 2865, June 479 2000. 481 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key 482 Management", BCP 107, RFC 4107, June 2005. 484 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 485 Authorization, and Accounting (AAA) Key Management", BCP 132, 486 RFC 4962, July 2007. 488 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for 489 the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, 490 March 2011. 492 [RFC6158] DeKok, A., "RADIUS Design Guidelines", BCP 158, RFC 6158, 493 March 2011. 495 8.2. Informative References 497 [RADYN] Winter, S. and M. McCauley, "NAI-based Dynamic Peer Discovery 498 for RADIUS over TLS and DTLS", Internet draft (work in 499 progress), draft-ietf-radext-dynamic-discovery-02, March 2010. 501 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 502 2548, March 1999. 504 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 505 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 506 Support", RFC 2868, June 2000. 508 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 509 3162, August 2001. 511 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 512 In User Service) Support For Extensible Authentication 513 Protocol (EAP)", RFC 3579, September 2003. 515 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote 516 Authentication Dialin User Service (RADIUS) Protocol", RFC 517 5997, August 2010. 519 Author's Address 521 David B. Nelson 522 Elbrys Networks, Inc. 523 282 Corporate Drive, Unit 1 524 Portsmouth, NH 03801 525 USA 527 Email: d.b.nelson@comcast.net