Commercial National Security Algorithm (CNSA) Suite Profile for SSH
draft-becker-cnsa2-ssh-profile-02

Network Working Group                                          A. Becker
Internet-Draft                                                   C. Wynn
Obsoletes: 9212 (if approved)                                        NSA
Intended status: Informational                            29 August 2025
Expires: 2 March 2026

  Commercial National Security Algorithm (CNSA) Suite Profile for SSH
                   draft-becker-cnsa2-ssh-profile-02

Abstract

   This document defines a base profile of SSH for use with the US
   Commercial National Security Algorithm (CNSA) 2.0 Suite, a
   cybersecurity advisory published by the United States Government
   which outlines quantum-resistant cryptographic algorithm policy for
   US national security applications.

   This profile applies to the capabilities, configuration, and
   operation of all components of US National Security Systems that
   employ SSH.  It is also appropriate for all other U.S.  Government
   systems that process high-value information.

   This memo is not an IETF standard, and has not been shown to have
   IETF community consensus.  This profile is made publicly available
   for use by developers and operators of these and any other system
   deployments.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on 2 March 2026.

Becker & Wynn             Expires 2 March 2026                  [Page 1]
Internet-Draft              CNSA2 SSH Profile                August 2025

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The Commercial National Security Algorithm Suite  . . . . . .   3
   4.  CNSA 2.0 Compliance . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  CNSA 2.0 Suite  . . . . . . . . . . . . . . . . . . . . .   4
   5.  Transport Layer . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  SSH_MSG_KEXINIT Overview  . . . . . . . . . . . . . . . .   5
     5.2.  Key Exchange  . . . . . . . . . . . . . . . . . . . . . .   5
     5.3.  Server Host Authentication  . . . . . . . . . . . . . . .   7
     5.4.  Encryption  . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  User Authentication . . . . . . . . . . . . . . . . . . . . .   8
   7.  Confidentiality and Data Integrity  . . . . . . . . . . . . .   9
   8.  Rekeying  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   This document specifies a profile of SSH [RFC4253] to comply with the
   National Security Agency's (NSA) Commercial National Security
   Algorithm (CNSA) 2.0 Suite [cnsafaq].  This profile applies to the
   capabilities, configuration, and operation of all components of US
   National Security Systems (NSS) [SP80059] that employ SSH.  This
   profile is also appropriate for all other US Government systems that
   process high-value information, and is made publicly available for
   use by developers and operators of these and any other system
   deployments.

Becker & Wynn             Expires 2 March 2026                  [Page 2]
Internet-Draft              CNSA2 SSH Profile                August 2025

   This document does not define any cryptographic algorithm, and does
   not specify how to use any cryptographic algorithm not currently
   supported by SSH; instead, it profiles CNSA 2.0-compliant conventions
   for SSH, and uses algorithms already specified for use in SSH that
   are also allowed by the CNSA Suite 2.0.  This document applies to all
   CNSA Suite solutions that make use of SSH.

   The reader is assumed to have familiarity with [RFC4253],
   [I-D.harrison-sshm-mlkem], [I-D.sfluhrer-ssh-mldsa].

   This memo is not an IETF standard, and has not been shown to have
   IETF community consensus.

   [ED NOTE: This document uses guidance from [I-D.harrison-sshm-mlkem],
   and [I-D.sfluhrer-ssh-mldsa] to specify use of ML-KEM and ML-DSA in
   SSH, respectively.  We note that the drafts are not yet RFCs, and we
   may need to adjust this text accordingly based on the progress of
   these documents.]

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.  Normative language does not apply beyond
   the scope of this profile.

   This is a profile of SSH [RFC4253].  Therefore, the requirements
   language in this memo may be different than that found in the
   underlying standards.

   All references to "CNSA" in this document refer to CNSA 2.0
   [cnsafaq], unless stated otherwise.

3.  The Commercial National Security Algorithm Suite

   The CNSA Suite is the set of approved commercial algorithms that can
   be used by vendors and IT users to meet cybersecurity and
   interoperability requirements for NSS.  The initial suite of CNSA
   Suite algorithms, Suite B, established a baseline for use of
   commercial algorithms to protect classified information.  The
   following suite, CNSA 1.0, served as a bridge between the original
   set and a fully quantum-resistant cryptographic capability.  The
   current suite, CNSA 2.0, seeks to provide fully quantum-resistant
   protection [cnsafaq].

Becker & Wynn             Expires 2 March 2026                  [Page 3]
Internet-Draft              CNSA2 SSH Profile                August 2025

   This profile uses CNSA 2.0 compliant algorithms: ML-DSA-87 [FIPS204]
   for signing, and ML-KEM-1024 [FIPS203] for key establishment.  ML-
   DSA-87 and ML-KEM-1024 together with SHA384, SHA512, AES-256, LMS,
   and XMSS comprise the CNSA Suite 2.0.

   The NSA is authoring a set of RFCs, including this one, to provide
   updated guidance for using the CNSA 2.0 Suite in certain IETF
   protocols.  These RFCs can be used in conjunction with other RFCs and
   cryptographic guidance (e.g., NIST Special Publications) to properly
   protect Internet traffic and data-at-rest for US Government NSS.

4.  CNSA 2.0 Compliance

   The purpose of this document is to provide guidance for CNSA-
   compliant implementations of the Secure Shell (SSH) protocol
   [RFC4253].  Note that, while compliant Secure Shell implementations
   MUST follow the guidance in this document, that requirement does not
   in and of itself imply that a given implementation of Secure Shell is
   suitable for use in NSS.  An implementation must be validated by the
   appropriate authority before such usage is permitted.

4.1.  CNSA 2.0 Suite

   The choice of all but the user authentication methods is determined
   by the exchange of SSH_MSG_KEXINIT between the client and the server.
   The algorithms provided in the name-lists specified in
   SSH_MSG_KEXINIT are listed in order of preference.  CNSA-compliant
   implementations MUST list the following algorithms as the first (most
   preferred) algorithms in their respective name-lists.

   Key Exchange Algorithms:

      mlkem1024-sha384 (Section 3.1.3 [I-D.harrison-sshm-mlkem]),
      [FIPS203], [SHS]

   Public Key Algorithms:

      ML-DSA-87 (ssh-mldsa87) (Section 8 [I-D.sfluhrer-ssh-mldsa]),
      [FIPS204]

   Encryption Algorithms:

      AEAD_AES_256_GCM [RFC5647]

      aes256-gcm@openssh.com

   MAC Algorithms (both client_to_server and server_to_client):

Becker & Wynn             Expires 2 March 2026                  [Page 4]
Internet-Draft              CNSA2 SSH Profile                August 2025

      AEAD_AES_256_GCM [RFC5647]

   Any algorithms not appearing in the above list MUST NOT be negotiated
   for use in a CNSA-compliant implementation of SSH.

   The procedures for applying the negotiated algorithms are given in
   the following sections.

5.  Transport Layer

5.1.  SSH_MSG_KEXINIT Overview

   The server and client use the SSH_MSG_KEXINIT exchange [[RFC4253],
   Section 7.1] to negotiate the following name-lists:

      kex_algorithms

      server_host_key_algorithms

      encryption_algorithms (client_to_server and server_to_client)

      mac_algorithms (client_to_server and server_to_client

   The kex_algorithms name-list is used to negotiate key exchange
   algorithms and hash used in the exchange hash.  This is discussed
   further in Section 5.2.

   The server_host_key_algorithms name-list is used to identify the
   algorithms for which the server has host keys, and which the client
   is willing to accept.  This is discussed in Section 5.3.

   The encryption_algorithms and mac_algorithms name-lists are used to
   negotiate symmetric encryption and MAC algorithm.  These name-lists
   are discussed in more detail in Section 5.4.

5.2.  Key Exchange

   This document does not preclude implementations that contain
   algorithms other than those specified in CNSA 2.0, such as the
   mandatory-to-implement algorithms listed in the Key Exchange Method
   Names (also known as those containing "MUST" in the OK to Implement
   column).  However, algorithms that are not CNSA compliant must not be
   negotiated and used in a CNSA-compliant connection.

Becker & Wynn             Expires 2 March 2026                  [Page 5]
Internet-Draft              CNSA2 SSH Profile                August 2025

   A CNSA compliant connection MUST NOT allow the reuse of ephemeral/
   exchange values in a key exchange algorithm due to security concerns
   related to this practice.  In accordance with [SP80056A], an
   ephemeral private key shall be used in exactly one key establishment
   transaction and shall be destroyed (zeroized) as soon as possible.

   The key exchange algorithm and hash is determined by the
   kex_algorithms name-list exchanged in the SSH_MSG_KEXINIT packets
   [[RFC4253] Section 7.1], as described above.

   For CNSA compliant connections, the following MUST be negotiated in
   the kex_algorithms name-list of SSH_MSG_KEXINIT, and MUST be the
   first (most preferred) choice in the list:

      Key Exchange: ML-KEM-1024 MUST be used to establish a shared
      secret value between the client and the server.  Any algorithm
      other than ML-KEM-1024 MUST NOT be negotiated for key exchange in
      a CNSA-compliant connection.

      Hash Algorithm: The exchange hash MUST be generated using either
      SHA-384 or SHA-512, or the connection MUST be terminated.  Any
      algorithm other than SHA-384 or SHA-512 MUST NOT be negotiated for
      hashing in a CNSA-compliant connection.

   [ED NOTE: CNSA 2.0 compliance requires the use of ML-KEM-1024 for key
   establishment, and SHA-384 or SHA-512 for hashing.  [RFC9142] does
   not provide guidance for use of ML-KEM in SSH, but recently posted
   [I-D.harrison-sshm-mlkem] details guidance on the technical function
   necessary to include ML-KEM in SSH, including defining
   SSH_MSG_KEX_KEM_INIT and SSH_MSG_KEX_KEM_REPLY.  This document is
   subject to change as [I-D.harrison-sshm-mlkem] progresses.]

   The key exchange is started by the client and server sending an
   SSH_MSG_KEX_KEM_INIT message.  In SSH_MSG_KEX_KEM_INIT, both the
   client and server MUST include

      mlkem1024-sha384 [I-D.harrison-sshm-mlkem]

   in the kex_algorithms name-list, and mlkem1024-sha384 MUST be the
   first (most preferred) algorithm in the list.

   For use of ML-KEM, the client sends the public key output, PK, of the
   ML-KEM KeyGen algorithm in SSH_MSG_KEX_KEM_INIT
   [I-D.harrison-sshm-mlkem].

Becker & Wynn             Expires 2 March 2026                  [Page 6]
Internet-Draft              CNSA2 SSH Profile                August 2025

   The server then sends its reply, SSH_MSG_KEX_KEM_REPLY
   [I-D.harrison-sshm-mlkem], which includes the ciphertext output, CT,
   of the ML-KEM Encaps algorithm, and the server's ephemeral public
   host key (or certificate).  The exchange hash is then generated and
   signed by the server.

   Note that [I-D.harrison-sshm-mlkem] details several checks that must
   also be performed for the ML-KEM algorithm components.

5.3.  Server Host Authentication

   For server host authentication, the server sends the client the
   server_host_key_algorithms name-list packet of the SSH_MSG_KEXINIT
   message.  For CNSA compliant connections, ML-DSA-87 MUST be listed as
   the first (most preferred) algorithm in server_host_key_algorithms.

   The server generates the exchange hash H as defined in Section 5.2
   and signs it using its private host key.  CNSA 2.0 compliance
   requires the use of ML-DSA-87 for signatures.

   Authentication by the client is a two-step process of validating the
   presented public key and verifying the signature.  By default, the
   server sends a raw public key, but it could be an X.509 certificate.

   For CNSA compliant connections, servers MUST be authenticated using
   digital signatures.  The public key algorithm implemented MUST be ML-
   DSA-87.  Where possible, public keys SHOULD be validated with
   certificates, otherwise, the client MUST validate the presented
   public key through another secure, possibly offline, mechanism.

   CSNA compliant implementations MUST NOT employ a "Trust on First Use
   (TOFU)" security model where a client accepts the first public host
   key presented to it from a not-yet-verified server.  If raw public
   key format is used, the trust anchor MUST be securely distributed.

   Where X.509 certificates are used, they must comply with
   [I-D.jenkins-cnsa2-pkix-profile].

5.4.  Encryption

   One of the following sets MUST be used for the encryption_algorithms
   and mac_algorithms name-lists in SSH_MSG_KEXDH.  Either set MAY be
   used for each direction (client_to_server and server_to_client):

      encryption_algorithm_name_list := { AEAD_AES_256_GCM }

      mac_algorithm_name_list := { AEAD_AES_256_GCM }

Becker & Wynn             Expires 2 March 2026                  [Page 7]
Internet-Draft              CNSA2 SSH Profile                August 2025

   or

      encryption_algorithm_name_list := { aes256-gcm@openssh.com }

      mac_algorithm_name_list := {}

   For encryption, use of AES-GCM MUST meet the requirements in
   [SP80038D], with the additional requirements that all 16 octets of
   the authentication tag MUST be used as the SSH data integrity value,
   and that AES is used with a 256-bit key.  Use of AES-GCM in SSH
   should be done as described in [RFC5647], with the exception that
   AES-GCM need not be listed as the MAC algorithm when its use is
   implicit (such as in aes256-gcm@openssh.com).  In addition, the AES-
   GCM invocation counter is incremented mod 2^64:

      invocation_counter = invocation_counter + 1 mod 2^64

   CNSA compliant implementations MUST NOT repeat a counter value, and
   MUST ensure the counter is properly incremented after processing a
   binary packet.

6.  User Authentication

   The user authentication protocol for authenticating the client to the
   server is specified in [RFC4252].  For CNSA compliant connections,
   all users MUST be authenticated as outlined in [RFC4252], and SHOULD
   be authenticated using a public key method.

   Specifically, all users MUST be authenticated and SHOULD be
   authenticated using public key.  Users MAY be authenticated using
   passwords subject to requirements in this section.  CNSA compliant
   connections MUST NOT use other methods of authentication, including
   hostbased authentication, keyboard-interactive authentication, or
   "none".

   When authenticating with public key, CNSA compliant connects MUST use
   ML-DSA-87.

   The server MUST verify that the public key is a valid authenticator
   for the user.  Public key authentication is a two-step process of
   validating the public key and verifying the signature.  In order for
   the server to verify the client, it must have a copy of the client's
   public key in advance.  If possible, validation SHOULD be done using
   certificates.  Otherwise, the server must validate the public key
   through another secure, possibly offline, mechanism.  When
   certificates are used, the file can list the CA key preceded by the
   string "@cert-authority" instead of the user key.

Becker & Wynn             Expires 2 March 2026                  [Page 8]
Internet-Draft              CNSA2 SSH Profile                August 2025

   When algorithms are negotiated in SSH_MSG_KEXINIT, the SSH protocol
   defined in [RFC4253] does not require the server to declare its
   supported algorithms for user host key, and the server will reject
   public key authentication requests for key types it does not support.
   For CNSA compliant connections, the client MUST use ML-DSA-87.

   Recent OpenSSH implementations do require the server to declare its
   supported algorithms via mechanisms detailed in [RFC8308].  The
   client includes "ext-info-c" in the kex_algorithms field of the
   SSH_MSG_KEXINIT message, to indicate that it wants to negotiate an
   SSH extension.  In OpenSSH versions 9.5 and 9.6, "ext-info-c" is
   automatically appended and forces the server to list the user
   authentication methods it supports.  CNSA compliant servers MUST list
   ML-DSA-87.

   If authenticating by passwords, it is essential that passwords have
   sufficient entropy to protect against dictionary attacks.  During
   authentication, the password MUST be protected in the established
   encrypted communications channel.  Additional guidance on password
   requirements are provided in [SP80063].

7.  Confidentiality and Data Integrity

   Use of AES-GCM in SSH is detailed in [RFC5647].  CNSA compliant
   implementations MUST support AES-GCM as described in SECTION, to
   provide confidentiality and ensure data integrity.  No other
   confidentiality or data integrity algorithms are permitted.

   As specified in [RFC5647], all 16 octets of the authentication tag
   MUST be used as the SSH data integrity value of the SSH binary
   packet.

8.  Rekeying

   Section 9 of [RFC4253] allows either the server or the client to
   initiate a "key re-exchange ... by sending an SSH_MSG_KEXINIT packet"
   and to "change some or all of the [cipher] algorithms during the
   reexchange".  For CNSA compliant implementations, the same cipher
   suite MUST be employed when rekeying; that is, the cipher algorithms
   MUST NOT be changed when a rekey occurs.

9.  Security Considerations

   Most of the security considerations for this document are described
   in [RFC4253], [RFC5647], [RFC4252].  Additional security
   considerations for the use of ML-KEM in SSH can be found in
   [I-D.harrison-sshm-mlkem].

Becker & Wynn             Expires 2 March 2026                  [Page 9]
Internet-Draft              CNSA2 SSH Profile                August 2025

10.  IANA Considerations

   This document has no IANA actions

11.  References

11.1.  Normative References

   [cnsafaq]  National Security Agency, "The Commercial National
              Security Algorithm Suite 2.0 and Quantum Computing FAQ",
              December 2024, <https://media.defense.gov/2022/
              Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF>.

   [FIPS203]  National Institute of Standards and Technology (2024),
              "Module-Lattice-Based Key-Encapsulation Mechanism
              Standard", (Department of Commerce, Washington,
              D.C.), Federal Information Processing Standards
              Publication (FIPS), NIST FIPS 203,
              <https://doi.org/10.6028/NIST.FIPS.203>.

   [FIPS204]  National Institute of Standards and Technology (2024),
              "Module-Lattice-Based Digital Signature Standard",
              (Department of Commerce, Washington, D.C.), Federal
              Information Processing Standards Publication (FIPS), NIST
              FIPS 204, <https://doi.org/10.6028/NIST.FIPS.204>.

   [I-D.harrison-sshm-mlkem]
              Harrison, A., "Module-Lattice Key Exchange in SSH",
              January 2025, <https://datatracker.ietf.org/doc/draft-
              harrison-sshm-mlkem/>.

   [I-D.jenkins-cnsa2-pkix-profile]
              Jenkins, M. and A. Becker, "Commercial National Security
              Algorithm Suite Certificate and Certificate Revocation
              List Profile", January 2025,
              <https://datatracker.ietf.org/doc/draft-jenkins-cnsa2-
              pkix-profile/>.

   [I-D.sfluhrer-ssh-mldsa]
              Fluhrer, S., "SSH Support of ML-DSA", August 2025,
              <https://datatracker.ietf.org/doc/draft-sfluhrer-ssh-
              mldsa/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Becker & Wynn             Expires 2 March 2026                 [Page 10]
Internet-Draft              CNSA2 SSH Profile                August 2025

   [RFC4252]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
              January 2006, <https://www.rfc-editor.org/info/rfc4252>.

   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
              January 2006, <https://www.rfc-editor.org/info/rfc4253>.

   [RFC5647]  Igoe, K. and J. Solinas, "AES Galois Counter Mode for the
              Secure Shell Transport Layer Protocol", RFC 5647,
              DOI 10.17487/RFC5647, August 2009,
              <https://www.rfc-editor.org/info/rfc5647>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8308]  Bider, D., "Extension Negotiation in the Secure Shell
              (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
              2018, <https://www.rfc-editor.org/info/rfc8308>.

   [RFC9142]  Baushke, M., "Key Exchange (KEX) Method Updates and
              Recommendations for Secure Shell (SSH)", RFC 9142,
              DOI 10.17487/RFC9142, January 2022,
              <https://www.rfc-editor.org/info/rfc9142>.

   [SHS]      National Institute of Standards and Technology (NIST),
              "Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4,
              FIPS PUB 180-4, August 2015,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.

11.2.  Informative References

   [SP80038D] National Institute of Standards and Technology,
              "Recommendation for Block Cipher Modes of Operation:
              Galois/Counter Mode (GCM) and GMAC, NIST Special
              Publication 800-38D", Special Publication 800-38D, DOI
              10.6028/NIST.SP.800-38D, November 2007,
              <https://doi.org/10.6028/NIST.SP.800-38D>>.

   [SP80056A] National Institute of Standards and Technology,
              "Recommendation for Pair-Wise Key Establishment Schemes
              Using Discrete Logarithm Cryptography, Revision 3, NIST
              Special Publication 800-56A", Special Publication
              800-56A, DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
              <https://doi.org/10.6028/NIST.SP.800-56Ar3>>.

Becker & Wynn             Expires 2 March 2026                 [Page 11]
Internet-Draft              CNSA2 SSH Profile                August 2025

   [SP80059]  National Institute of Standards and Technology, "Guideline
              for Identifying an Information System as a National
              Security System", Special Publication 59, DOI
              10.6028/NIST.SP.800-59, August 2003,
              <https://csrc.nist.gov/publications/detail/sp/800-59/
              final>.

   [SP80063]  National Institute of Standards and Technology, "Digital
              Idenity Guidelines", Special Publication 800-63-3, DOI
              10.6028/NIST.SP.800-63-3, June 2017,
              <https://doi.org/10.6028/NIST.SP.800-63-3>>.

Authors' Addresses

   Alison Becker
   National Security Agency
   Email: aebecke@uwe.nsa.gov

   Casey Wynn
   National Security Agency
   Email: cwwynn@uwe.nsa.gov

Becker & Wynn             Expires 2 March 2026                 [Page 12]