Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA

• Lightweight directory access protocol (LDAP), HTTP, SSH, TLS and, optionally, IPsec
rely upon asymmetric cryptography. However, the specific mechanism for doing this
varies widely between these protocols. LDAP and TLS, for example, natively use
X.509v3 conformant public key infrastructure (PKI) certificates. HTTP uses the
underlying provisions provided by TLS. TLS can function without the use of asymmetric
keys, but they are required if mutual authentication is supported. In the latter case, the
server must provide a PKI Server Certificate and the Client a PKI Identity Certificate.
IPsec only uses asymmetric keys for automated key management. The manual key
management alternative, by contrast, solely uses preplaced symmetric keys. On Linux
systems, SSH can be directly configured by running an internal Rivest Shamir Addleman
(RSA) algorithm within their daemon to create their asymmetric keys.
• Other approaches require that unique symmetric key instances be distributed between
each client-server pairing. This is the case for Domain Name System (DNS), dynamic
host configuration protocol (DHCP), network time protocol (NTP) and real-time protocol
(RTP). These symmetric keys must have been established at configuration time since
these protocols lack a mechanism to dynamically distribute these keys. Simple network
management protocol (SNMP) also requires unique symmetric key pairings between
network administrators and SNMP agents; however, these keys may be constructed from
the network administrator’s password. The key point is that a single SNMP agent, DNS,
DHCP, or RTP daemon within any given device has a large number of unique secret key
values that are used on a per-protocol basis that it must maintain and associate with the
appropriate remote peer. This represents substantial local key management complexity
that is often implemented in a manner that is difficult to subject to administrative
oversight.
4.6 NETWORK MANAGEMENT—NETWORK SECURITY CONCERN.
Network management is an inherently important and a difficult task. The difficulty of the task
becomes increasingly untenable the greater the size and diversity of the deployed network
devices being managed. This difficulty arises from subtle and not-so-subtle differences between
various implementations of the management protocol and the management schemas (i.e.,
management information and variables) supported by the various devices. For example, in 2001,
one of the authors of this document investigated industry support for the Distributed
Management Task Force’s (DMTF) 9 management schemas to examine their applicability to
create policy-based network management constructs. He learned that although the vast majority
of vendors claimed compliance with DMTF standards, upon closer inspection, it became
apparent that they were supporting different (noninteroperable) versions of the schemas from
each other. Most of the vendors had also introduced unique extensions to the schemas, and some
of them had substituted constructs of their own invention for elements within the standard
schemas. The net result was that a common management approach became increasingly
untenable the more the deployment included different vendors products. A similar observation
can be made concerning multivendor support for the SNMP’s management information base
9 DMTF; see http://www.dmtf.org/home
43