Skip to main content

Survey of Current Security Work in the IETF, October 2003
statement-iab-2003-10-14-security-survey-00

Document Type IAB Statement
Title Survey of Current Security Work in the IETF, October 2003
Published 2003-10-14
Metadata last updated 2023-08-09
State Active
Send notices to (None)
statement-iab-2003-10-14-security-survey-00

Survey of Current Security Work in the IETF

Abstract

This document contains the results of an IAB survey on security work in the IETF.

Authors

James Kempf Charlie Kaufman
DoCoMo
USA Labs Microsoft
kempf@docomolabs-usa.com    charliek@microsoft.com

1. Introduction

This document contains a summary of the security survey sent out by the IAB in June, 2003. The goal of the survey was to obtain information about what kinds of security work were being done in IETF Working Groups, in order to find any commonalities between work at different layers. The survey took the form of an email sent to the wgchairs@ietf.org mailing list containing a series of questions about security work in different Working Groups.

2. Survey Results

This section presents the results of the survey, by Working Group.

2.1 Next Steps In Signaling

No security protocol work is being done by NSIS, though there are a few security threats and analysis documents. They are available as Working Group drafts through the NSIS Web page.

2.2 ZEROCONF

The ZEROCONF Working Group chair provided the following general information about use of security in the protocol:

IPv4 link-local auto configuration protocol: IPv4 addresses are generated randomly. ARP maps these to L2 addresses which are *not* chosen randomly. No authentication is provided or attempted.

The following contains answers to the survey:

Identification of remote endpoints by IP address, Link layer address
Authentication of remote endpoints IP addresses, Link Layer addresses (Endpoints are not authenticated. The IP address and link layer addresses returned by ARP are assumed to be correct.)
Data protection none
Provisioning or configuration of security information none

2.3 SRVLOC

SRVLOC is currently officially dormant and does not meet at IETF meetings, though there is active discussion on the mailing list. The last Working Group chair before the group went dormant provided the following general information about use of security in the protocol:

SLP allows applications to generate ‘service urls‘ which identify services. Each service URL is also coupled with a ‘service type’ string, a list of attributes and also optionally a SLP ‘security parameter index’ string. Authentication is done over the parameters listed above by matching a public/private key pair to the security parameter index string. The producer of the service information signs, the consumer of the service information verifies the signatures before accepting the service information. This can only be done if the signer and verifier have the needed keys and/or certificates or can get them. SLP does not provide for key or certificate distribution or discovery.

The following contains answers to the survey:

Identification of users or administrators by text string (An administrator or user could be identified in an attribute string passed by SLP.)
Identification of remote endpoints by DNS name, IP address, Link layer address, UID ( SLP identifies end points using URIs. These can contain DNS names or IP addresses. In some specialized URIs, even L2 addresses can be provided. In some cases a unique ID is used to identify services as well)
Identification of data in a hierarchy by text string (SLP uses text strings for attribute names. These strings can be registered with IANA in RFC 2609 service templates.)
Authentication of remote endpoints using cryptographic algorithms (DSA signatures in X.509 format)
Protecting data Other cryptographic mechanisms (Authenticates data, so that the consumer can check that the provider has signed it (and to do that, the provider must have a private key)
Provisioning/Configuration of security information By unspecified out of band mechanism (Does not provision security information. It assumes that keys and key names (SLP security parameter index strings) are configured in SLP agents).

2.4 BRIDGE

The BRIDGE Working Group is defining are MIBs, and the chair reported that the survey was not applicable, since BRIDGE relies on the security of SNMP for user authentication, encryption and other protection. The MIBs do not contain any security information.

2.5 DISMAN

Identification of users or administrators by text string in our MIBs, other mechanisms are possible in scripts executed under the control of those MIBs. Keeping VACM configuration simple is driving factor here.
Identification of remote endpoints by DNS, IP, and other mechanisms used in MIBs, other mechanisms are possible under script control.
Identification of data in a hierarchy by Don’t understand what you mean by SNMP here. My answer would have to be OID, but all of the above are possible in scripting environments supported by disman.
Authentication of users or administrators Authentication handled under SNMPv3, by whatever security model is being used.
Authentication of remote endpoints SNMPv3 USM security is user, rather than endpoint based. If someone were crazy enough to design an endpoint-based security model (and hook it into VACM), the disman MIBs would still work.
Protecting data SNMPv3 for transfer. Storage is out of scope.
Provisioning/Configuration of security information SNMPv3, using whatever security model, e.g., USM.

2.6 EAP

One of the Working Group chairs provided the following general comment on EAP applicability:

The "EAP Appropriate Use" policy formulated by Jeff Schiller at IETF 47 was that EAP is a mechanism created for use in situations where IP is not available (e.g. link layer authentication). It MUST NOT be used over the Internet without protection.

That policy is still in effect, and all RFCs relating to EAP conform to it so far. SASL is not much different for simple mechanisms, but is considerably better for complex ones since it runs over TCP and therefore can much more efficiently handle things like certificate exchanges. However, it has no way of handling man-in-the-middle attacks.

The following contains answers to the survey:

Identification of users or administrators by Text string, DN.EAP has a text-based user name field, but in most cases a NAI is sent. Some EAP methods also certs and as such the usual cert-based identities, such as DNs
are used.
Identification of remote endpoints by Text string, other. Being an old protocol for network access security, EAP does not have a very good representation of the network’s identity. However, a text string can be passed. ALso, in most cases this identification happens at a lower layer, e.g. WLAN
SSIDs identify the network. Also, some EAP methods use certs and as such again DNs
or other identifiers are used. It is not clear if this counts as identification of a remote endpoint.
Identification of data in a hierarchy Not relevant for EAP.
Authentication of users or administrators Passwords, cryptographic algorithms. Some of the EAP methods are password based. None of them are cleartext password-based.. All EAP methods are based on some sort of a cryptographic algorithm. Simple password algorithm, a more advanced shared secret algorithm, something stolen from TLS & cert world, etc. are some examples.
Authentication of remote endpoints See above.
Protecting data SSL and/or TLS (EAP TLS), IPsec ( Not typically, though EAP may be encapsulated in RADIUS/DIAMETER and protected by IPsec, or it may be used by IKEv2. But EAP as such does not make use of IPsec nor IKE), other specs (The question is unclear for EAP. Surely the use of TLS/XML etc. would also be a reference to other specs. What happens in many of the EAP methods is that data associated with the protocol run is protected using
HMACs or similar mechanisms).
Provisioning/Configuration of security information out of band mechanism, referencing another spec (Most of the time out-of-band applies. In some cases, EAP methods use authentication schemes that rely on standard credentials such as certs
or SIM cards; it is presumed that the provisioning of these can happen in the same way as is done for other applications. However, EAP itself does not talk about this.

2.7 IPSP

IPSP’s general approach is merely to set minimal requirements and allow the implementers to choose the specifics. All endpoints are assumed to be within a single security domain.

Identification of users or administrators naming deferred to site specific mechanism
Identification of remote endpoints by naming deferred to site specific mechanism
Identification of data in a hierarchy ??? not familiar with the concept of data identification, in this context; sorry
Authentication of users or administrators deferred to site-specific mechanisms
Authentication of remote endpoints deferred to site-specific mechanisms
Protecting data Transport protection is deferred to site-specific mechanisms; all methods suggested in your question are acceptable if used properly
  For IPsec, IPSP allows some IPsec keys to be configured, so these must be protected by the transport layer; we do not specify how the transport keys themselves are configured, this being rather chickenish-and
eggish.

2.8 IPV6OPS

Identification and authentication of users not applicable
Identification and authentication of endpoints IP Address
Protection of data not done
Provision/configuration of security information. typically uses DNS to look up a name, or relies on IP addresses.

2.9 PKIX

Identification of users or administrators DNS name, rfc822 name, DN
Identification of remote endpoints DNS name, IP address, rfc822 name, other
Identification of data in a hierarchy OID
Protecting data other cryptographic mechanisms
Provisioning/Configuration of security information specifies a protocol for doing this

2.10 SEND

Identification of remote endpoints IP address, Link layer address, other (Cryptographically Generated Addresses (CGAs) together with a digital signature are used.
Authentication of remote endpoints reference to RFC2461 and RFC2462, cryptographic algorithms (RSA by default, also Cryptographically Generated Addresses (which this protocol defines)).
Provisioning/Configuration of security information unspecified out of band mechanism

2.11 SEAMOBY

2.11.1 Candidate Access Router Discovery Protocol (CARD)

Identification of remote endpoints IP address
Authentication of remote endpoints reference to other specs
Protecting data IPsec
Provisioning/Configuration of security information unspecified out of band mechanism

2.11.2 Context Transfer Protocol (CTP)

Identification of remote endpoints IP address
Authentication of remote endpoints reference to other specs (IPsec
ESP in transport mode)
Protecting data IPsec (transport mode)
Provisioning/Configuration of security information unspecified out of band mechanism

3. Conclusions

This survey did not elicit the information that we were looking for, though it did give us some ideas about how a future survey could be better organized. By incorrectly anticipating the kinds of information we expected to get, we made it difficult for some respondents to make sense of the questions (and probably discouraged others from responding at all).

We should have had an explanation of what we were looking for and why, and an easy way for a respondent to say "there’s nothing going on in this working group that you would care about". Only after passing that hurdle should we have had more detailed questions.

More importantly, we should have worked with the Security ADs

to take advantage of their knowledge of what’s going on and hence how to phrase questions. Whether such a survey would be worthwhile should be discussed. We were trying to identify places where people were reinventing the wheel in the security space rather than leveraging the work of security working groups or where new security working groups might be useful to coordinate the efforts in this space. The survey was prompted by concerns expressed that this might be widespread. While the response we got was spotty, we did not find evidence to support the concern. It’s possible that this effort should either be abandoned or done under the auspices of some other group like the Security ADs or the Security Directorate.