Coverage and Relevance Assessment

Having taken into consideration the feedback of IETF representatives, it is possible to assess the coverage of the proposed set of protocols by examining the individual charters of the working groups of the IETF and by reviewing the Internet Architecture Board documents on the Security of the Internet, and the Requests for Comments devoted completely to security, namely [32,159,33,160,174].

Our set of candidate protocols includes almost all protocols recommended by the Internet Architecture Board (IAB) during a meeting on 3-5 March 1997 in Murray Hill, NJ (reported in [32]). The IAB recommendations were:

• ``Core Security Mechanisms'': The following mechanisms were designated as core in [32]:
  • IPsec, see Section 4.17.
  • ISAKMP/Oakley, see Section 4.17.
  • DNSsec, see Section 4.12.
  • Security/Multipart, [72], is the preferred way to add secured sections to MIME-encapsulated email, see Section 4.3 for a similar protocol, SIP-SMIME.
  • Signed keys in the DNS, see Section 4.12.
  • X.509v3, is the IETF standard for certificate profiles. It is not really a protocol, but the description of format and contents of certificates, together with their intended use. This is beyond the scope of AVISPA.
  • TLS, see Section 4.25.

• ``Useful but not Core Mechanisms'':
  • AFT/SOCKS, provides secured firewall traversal see [105,104]. The security is based on GSSAPI (which is beyond our scope) or username/password (which is insecure). Initially, other methods were proposed (based on challenge-response and on the Extensible Authentication Protocol (EAP), see Section 4.13), but those methods have been abandoned. Thus, we do not consider AFT/SOCKS.
  • RADIUS, see Protocol IPv6-RADIUS in Section 4.18.
  • Firewalls are beyond the scope of AVISPA.
  • GSS-API is a framework for negotiating security mechanisms and its security properties are those of the negotiated mechanisms.
  • PGP, the key distribution of PGP is insecure, and the sending of encrypted or signed messages (in this case mail) using public key infrastructure is secure.
  • Kerberos, see Section 4.19.
  • PKIX-CMP (formerly PKIX-3), ([10]) is the suite of Certificate Management Protocols for the IETF version of the X.509 Public Key Infrastructure (PKI). It defines protocol messages for all relevant aspects of certificate creation and management.
  • the various forms of per-hop authentication (OSPF, RSVP, RIPv2), see Section 4.5.
  • APOP, ([127], see Section 4.10).
  • OTP, see Section 4.14.
  • S/MIME, see Section 4.3, for a quite similar protocol, the Protocol SIP-SMIME.
  • SSH, see Section 4.23.
  • PFKey, see [116] is a generic key management API that can be used not only for IP Security, but also for other network security services. This is beyond the scope of AVISPA.
  • IPsec API (see [175]) provides a set of facilities which an IPsec implementation should provide to applications to allow them to both observe and influence how IPsec protects their communications. This is beyond the scope of AVISPA.
  • SASL is a framework for negotiating security mechanisms and its security properties are those of the negotiated mechanisms.
  • CRAM, see Protocol CRAM-MD5 in Section 4.10.
  • CHAP, see Protocol ChapV2 in Section 4.21.

The list is five years old (it was published as RFC in April 1998); an update would be of interest. For instance, perhaps today Security/Multipart would not be seen as ``core'' security mechanism, but rather CMS (Cryptographic Message Syntax, see [85,86,196]).

We will not model any of the protocols considered as ``not useful'' or unacceptable in [32], in particular any protocol where plaintext passwords are sent over unencrypted channels.

For an overview of the security mechanisms for the Internet see [33]. Our protocols also cover most of them. While there is partial overlap between this list and the previous one from [32], we include both lists for easy reference to the sources.

The mechanisms described in [33] are:

• One-Time Passwords, see Section 4.14.
• HMAC, is a generic security mechanism, (a hash) used in many other protocols. It is not a protocol in the sense of AVISPA.
• IPsec, see Section 4.17.
• TLS, see Section 4.25.
• SASL is a framework for negotiating an authentication and encryption mechanism to be used over a TCP stream. The properties are those of the negotiated mechanism.
• GSS-API, like SASL, is a framework for negotiating an security mechanisms and its security properties are those of the negotiated mechanism.
• DNSSEC, see Section 4.12.
• Security/Multipart, see Section 4.20.
• Digital Signatures are a generic security mechanism used in many other protocols and by itself, is secure.
• OpenPGP and S/MIME, see Section 4.3.
• Firewalls and Topology are beyond our scope, but related methods (``Return Routability'', in which some ``regions'' of the Internet are assumed to be secure) are discussed in Section 4.1.
• Kerberos, see Section 4.19.
• SSH, see Section 4.23.

Our protocols also cover most of the recommended authentication mechanisms for the Internet described in [159]:

• One-Time Password Systems
  • S/Key, see Section 4.14
  • OTP, see Section 4.14
  • SecureID is a simple proprietary protocol, based on a smart card, that produces a stream of passwords to be used only once. The sender and the receiver are synchronized. The strengths and weaknesses of the protocol are well known.

• Challenge-Response Systems
  • APOP, ([127]), see Section 4.10.
  • ACAP [132], very close to [100], discussed in Section 4.10 (Protocol CRAM-MD5).
  • HTTP Digest [69], is part of the SIP security, discussed in Section 4.3.
  • AKA, see Section 6.1.
  • CRAM-MD5, see Section 4.10.
  • Kerberos, see Section 4.19.
  • SIM is an insecure protocol, similar, but much simpler than Protocol AKA of Section 6.1.

• ``Zero Knowledge'' Password Proof Systems (See Section 4.16):
  • EKE
  • A-EKE
  • SPEKE
  • SRP

• Server Certificate Systems
  • Protocols over SSL/TLS; this is one variant of the protocols of Section 4.25.
  • IPsec (under some conditions), this is one variant of the protocols of Section 4.17.

• Mutual Public Key Systems
  • SSL/TLS (client auth mode), this is one variant of the protocols of Section 4.25.
  • IPsec IKE, this is one variant of the protocols of Section 4.17.
  • S/MIME, see Section 4.3

• Generic Authentication Systems. In general these are ``containers'' that pass further unspecified authentication information for negotiating security mechanisms. Their security properties are those of the negotiated mechanisms.
  • GSS-API
  • SASL
  • EAP

• Authentication Server Systems
  • Kerberos, see Section 4.19
  • RADIUS, see Protocol IPv6-RADIUS in Section 4.18
  • DIAMETER, see Protocol AAA-MIP in Section 4.1

Our list of protocols does not include two groups of insecure authentication mechanisms for the Internet discussed but not recommended in [159]:

• Passwords in the Clear
  • TELNET (basic authentication)
  • HTTP (basic authentication)
  • SASL (password mode)
  • RLOGIN
  • POP
  • IMAP

• Anonymous Key Exchange Mechanisms
  • SSH (password mode)
  • SSL/TLS (anonymous keying)

The other two RFCs solely dedicated to security ([160,174]) do not contain lists of protocols or mechanisms, but discuss the types of security properties that an Internet may want to have and the attacks that it may be subject to. We have gone through the two documents with great care and incorporated all relevant security properties into our list.