2.3.8 IP Configuration Security (icos)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-02-07


Bernard Aboba <aboba@internaut.com>
Jari Arkko <Jari.Arkko@piuha.net>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Thomas Narten <narten@us.ibm.com>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

Internet layer configuration is defined as the configuration required
to support the operation of the Internet layer. This includes IP
address configuration, default gateway(s), name server configuration,
boot configuration (TFTP, NFS), service location and directory
configuration, mobility configuration, and time server configuration

Configuration is typically performed insecurely today. For example,
DHCP is rarely secured due to the need for keys to be set up between
clients and servers. In other cases, such as in Mobile IPv6, tools for
secure configuration exist and their use is required, but there are
deployment barriers.

As a result, Internet Area working groups are exploring alternative
solutions. These include use of EAP for use for key derivation, and
configuration. For example, the DHC WG has considered employment of
EAP-derived keys for use with DHCP security, as defined in RFC 3118
and 3315. The MIPv6 WG, in investigating the bootstrapping problem,
has considered proposals involving use of IKEv2 with EAP, as well as
utilization of link layer EAP exchanges for configuration.

The SEND working group defined a certificate-based authorization for
routers, where hosts prefer a router that has a certificate traceable
to a trusted root configured for the host. SEND also defined zero
configuration mechanism for secure IP address configuration, based on
Cryptographically Generated Addresses (CGAs).

This BOF will provide an overview of Internet layer secure
configuration needs, discussing the architectural issues and potential
solutions under discussion. The purpose of the BOF is to discuss a
common topic that touches several existing Working Groups, and it is
not expected that a new working group will be formed as a result.

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

IETF62 IP Configuration Security (ICOS) BoF
Thursday March 10th, 2005, 13:00-15:00

BoF chairs: Bernard Aboba and Jari Arkko
Slides: http://www.drizzle.com/~aboba/IETF62/icos/
Scribes: Pasi Eronen and Vijay Devarapalli

Jari Arkko: Background and Introduction

Jari bashed the agenda, and explained the history, goals, and non-goals of this BoF.

There is a lot of interest in securing IP layer configuration in various IETF groups, many of them have proposals based on EAP. Figure out what the problem is and see if anything needs to be done.

Scope for the BoF: Goal is primarily educational. Learn about problems, solutions and find others who have the same problem. This is a one-time discussion forum. Not planning to setup a WG. Relevant WGs have to come up with their own solutions.

Bernard Aboba: Securing Internet Configuration

What is IP Configuration?
Security Problems - two types of security problems.
- Secure IP configuration
- Secure Protocols
Threat Model
Required Security Services
- Data origin authentication and integrity/replay protection of IP address assignment & configuration parameters
- DoS protection
Architectural Principles
Less Is More
Lower Layer Independence
Higher Layer Independence
Internet Layer Reliance
Algorithm Support
- EAP is a media-independent framework for network access authentication. it can be defined to run over each link layer. if run over IP, no longer dependent on the link layer

Thomas Narten: Could you elaborate on the "EAP security model"?

Bernard: Some parts will be covered later.

Pasi Eronen: EAP often works with some link-specific mechanisms for per-packet authentication and encryption; just using EAP is not usually enough.

Someone: Fibre channel is T.11, not T.10, but I don't know how they feel about EAP.

Mobility Support
Potential Approaches
Provisioning issues
Initial provisioning

Bernard Aboba: EAP Applicability

EAP Usage Scenarios
- Peer and authenticator speak some other protocol, authenticator and AAA server speak AAA protocol
- Peer and authenticator speak EAP; authenticator and EAP server/AAA server speak EAP over AAA
- Peer and authenticator speak some other protocol, but use keys derived from a previous EAP conversation between the same EAP peer and EAP server
RFC 3748 Applicability Statement
Process for Analyzing New EAP Applications
Acceptable solution MUST... (Housley, IETF 56)
Acceptable solution MUST also...

Alper Yegin: Which system is referred by the "Compromise of a single NAS cannot compromise any other part of the system"?

Russ Housley: There are several ways how things could be implemented; in some of them, compromise of one NAS reveals a long-term secret that could be used to authenticate to another NAS. This should not happen. The compromise of a NAS should limit the damage to the contents on that NAS.

David Perkins: Slides did not mention keeping identity of the peer secret?

Russ Housley: It is desirable in some instances, but I chose not to make it a MUST here.

Bernard Aboba: It is a requirement to some people.

Ralph Droms: DHCP Security

Initial spec for DHCP included no security
Input from IAB/IESG led to supplemental security
More input led to security for relay agent options

Bernard: Is a confidentiality/encryption (for location information) also a concern on the first hop, or just between subsequent relay agents?

Ralph: Should be secured all the way.


Pasi Eronen: The requirement to keep the four-message exchange limits the kinds of credentials you can use.

Someone: I don't recall seeing for proposal that would require more than four packets, except possibly Kerberos had some complications.

Hannes Tschofenig: Some frameworks like EAP may require more than two roundtrips; that is why some people have proposed executing EAP as a separate step.

Threat Analysis
DHC WG has studied alternatives
Op-Ed (continued)
- DHC WG has invested time in developing authentication mechanisms, but no vendor has implemented any.

Alper: You said that there are no companies asking a solution for this problem, except the latest development with DSLs? Why is this so?

Ralph: One reason probably is reliable link layer authentication.

Bernard: In some cases, like secure boot, you can get away be securing the boot protocol, not configuration.

James Kempf: ARP spoofing has certainly occured in e.g. some conferences, maybe also DHCP spoofing.

Basavaraj Patil: Many mobile networks are reasonably closed and have link-layer authentication, clients can't talk to bogus DHCP servers in the first place.

Alper: (comment about using lower-layer security)

Someone: If we have secure higher-layer protocols, there is less need for securing DHCP because then the main risk is DoS, not stealing stuff or something.

Someone: There are complications with two DHCP servers overriding each other, for instance one IPv4 and another IPv6, or one local and another behind VPN

Someone: Linux installations that have DHCP server enabled by default have caused problems, accidentally bringing down the network.

Jari: Let's move to other presentations

James Kempf: Overview of the Mobile IPv6 Bootstrapping Problem

What Needs to be Dynamically Configured?
Bootstrapping in the Mobile IPv6 Standard
What's Missing?
What Needs to Be Configured?
What are the Security Problems and Measures?
Home Agent/Mobile Node SA Establishment
Home Address Discovery
IKE Security Credentials
How is EAP being Proposed as a Solution?
EAP Configuration Protocol Flow
IKEv2/MIP6 Protocol Flow
Analysis of EAP Solution
Problems solved by EAP
Problems not solved by EAP
Problems created by EAP for configuration

Sam Hartman: Why do you need pre-shared key if you're doing EAP-over-IKEv2?

James: MIP spec is IKEv1.

Sam: The key used for network access is different key than the one used for Mobile IP, right?

James: Yes.

Thomas Narten: Are you getting the home address via EAP or in the IKEv2 exchange?

James: Can be done either way.

Thomas: But the bootstrapping problem you are trying to solve (via EAP) is only discovery of a HA?

James: Yes. The other parameters can be configured using IKEv2 for example.

Pasi Eronen: You need a key distribution protocol to send the key from the AAA server to the home agent, right?

James: Yes, this is the first bullet on the slide.


Jim concluded by saying we need to figure if we can expand the narrow applicability of EAP to include MIP6 bootstrap information, for example, like the HA address.

Joe Salowey: I'm worried about term "configuration using EAP"; EAP does authenticated key exchange, and configuration is something else totally.

Jari Arkko: Secure Neighbor Discovery in IPv6

(no questions/comments during this presentation)

Hannes Tschofenig: NSIS Secure Configuration Issues

Establishment of a security association between End Host and QoS router before QoS setup. EAP is a possible solution.

(no questions/comments during this presentation)

Comments/questions part

Ted Lemon: There are two different problems, defining overall architecture how secure we secure network discovery, and second, individual tools we use in different situations. I think we need to think about the architecture more than we have, instead of low-level details. Also, what this looks like to the user.

Bernard: Some problems are classic configuration, some are more bootstrapping/enrollment problems in a roaming scenario.

Someone: Several different types of information, some more static, some more dynamic. We could make requirements for lower layer to provide some types of information.

Jari: One thing that is visible to the user is where you can use this stuff. Many proposals employ underlying network access authentication, like EAP, but only small part of network access actually uses EAP. If you cover only 5% of your problem space, then this does not make sense.

James: There are some classes of deployments where EAP seems to make sense.. but perhaps more cases where it does not, since you don't use EAP for network access authentication.

Hannes: I'd like to comment about enrolling and bootstrapping. In enroll WG we found that we do not know what those words exactly mean. But EAP seems to be useful for other cases than just network access, like IKEv2. Use EAP for authentication but allow use for other purposes too.

Alper: It's not clear what part of EAP the applicability statement is about, like EAP lower layer, EAP layer, EAP methods, etc. And if IETF says that EAP is not applicable, I hope we can give recommendation about what would be applicable. There are requirements about using AAA and EAP works fine with that.

Jari: I don't think the specific details of the current applicability statement are that important.

Pasi: We cant just say dont use EAP. we have in IETF mechanisms that can setup some parameters in a very elegant way. But they are not feasible in many realistic deployment scenarios. There are existing authentication frameworks like Kerberos and PKIX that could solve some of these problems nicely, but they don't support the kinds of credential people want to use, or don't play well with AAA. So people are using EAP as a general purpose authentication framework...

Ted: We should come up with user stories, like what happens from the user point of view? Then we can decide what the protocol should be able to do, and only after we can see whether EAP would be a good solution. I don't think we're at that position yet.

Hannes: (comment about user story vs. operator story)

Basavaraj Patil: There is very specific user story in MIP6, they want the capability to bootstrap, using EAP as a means of carrying configuration information.

Ted: I'm not saying that you shouldn't be doing that in MIP6, only what we should be doing here in this meeting. That is one user story, but we should have more.

Bernard: (comment about user stories)

Pasi: This a very specific user story; if you get full network access after L2 authentication, you could run MIP configuration independent of network access authentication. If you have IP, mapping topology independent home agent identifier to IP address could just use DNS.

Basavaraj Patil: (comment about MIP6/EAP bootstrapping)

Pasi: So this is at least partly an optimization in the number of roundtrips, rathen than providing new functionality?

James: The roundtrips are done at the time when the host is doing configuration anyway, so why not do it then.

Raj - MIP6 is one story. there are other examples like MIPv4, PANA, etc... More round trips when you first do access auth then run a protocol to configure parameters. if possible to optimize by carrying info in EAP, it saves round trips.

Someone: A couple of properties EAP has
1. allows you to authenticate without ties to IP address or MAC address. this makes it possible to run at any layer.
2. 3 party authentication. no other protocol has this property.
3. obtain keying material and some configuration parameters
4. a lot of methods, this is a boon, can be used with many protocols, methods can be dropped.
These are probably why EAP is being considered.

Uri Blumenthal: There are very few protocols that allow you to authenticate without tying it to the IP address, but you can do EAP at any layer. And EAP seems to offer three-party authentication, you can't simply take a two-party protocol and make it three-party easily. It is often convenient to be able to run your authentication and obtain configuration parameters at the same time.

Hannes: People have been worried about the use of EAP for different purposes, I think having this discussion here is useful.

Jari: Right, there is a lot of ongoing work and we should learn from each other.

Uri: Security of EAP also depends on methods, and profileration of methods may be good for its widespread use, but bad for analyzing security.

Someone: What is the reason why using EAP is not applicable for services, but only network access?

Basavaraj: In PANA WG we have discussed using EAP for accessing different types of services, or other networks than just the immediate network you're connecting to.

Ted: I don't care about details of specific solutions, I'm interested in high level problem what we're trying to accomplish, and I think we should be talking about that.

Sam: Although having a lot of EAP methods is complicated, deploying new credentials is also hard. I think the uses of EAP that were discussed here are close enough to network access that I could see the connection. But when EAP was expaned from PPP to other uses, a lot of new work was required; if we expand EAP to services in general, we need at least the same amount of work. We might want to check that there are no better solutions. So if you're using EAP for something totally else than network access authentication, please talk to me earlier rather than later.

Thomas: EAP seems to be a hot technology and people may expect that this leads to interoperability, but EAP does not provide that, only specific EAP methods do. So we have to be careful so that the work we do leads to interoperability, not just method-specific solutions.

Jari: I would like to talk about non-EAP solutions. We are too focused on EAP. I believe we need an overall architecture for a specific problem, such as Mobile IPv6 bootstrapping. I believe its doable by three separate components: (1) discovery, perhaps based on DNS, (2) ability to create a security association with a home agent, opportunistically, (3) an optional authentication with AAA, maybe using EAP. Lets not mix all these together, the result is too rigid.

Bernard Aboba: Obviously this is a hard problem, we have to obtain configuration, and we have to accomplish that in situations where we have IP connectivity, and without IP connectivity. Plus this also outside my local administrative domain. So it's no surprise we're scratching our heads.

Basavaraj Patil: (did not get this one down)



Background and Introduction
Securing Internet Configuration
EAP Applicability
Overview of the Mobile IPv6 Bootstrapping Problem
Secure Neighbor Discovery in IPv6
NSIS Secure Configuration Issues (with a focus on QoS signaling)