alternatives for carrying eap lower layer information

[Jari Arkko <jari.arkko@piuha.net>]

Hello folks,

In San Diego we discussed draft-mariblanca-aaa-eap-lla-01.txt. This
draft is used in conjunction with EAP authentication, and provides a
new attribute that tells the AAA server the name of the protocol that
carried the EAP protocol. For instance, 802.1X, IKEv2, or PEAP.

While I sensed that people in the room saw the need for carrying
this information (useful for policy and in some cases also security
purposes), there was a big discussion on whether existing
attributes are sufficient, whether just a new value would
be needed in an existing attribute, or whether a completely
new attribute is needed.

This e-mail attempts to summarize the possible alternatives
and their pros and cons. Comments on this are appreciated.
Did we miss any alternative? Which alternative do people
prefer?

Best Regards,

Jari and David

----

Introduction
------------

The alternatives are:

- Existing values in the NAS-Port-Type attribute

- New values in the NAS-Port-Type attribute

- New values in the Service-Type attribute

- New attribute specifically for expressing the lower
  layer for EAP

The aspects that we would like to consider are:

- Ability to differentiate between carrying EAP over, say, 802.1X or
  IKEv2 without requiring knowledge of what NAS-Identifiers are what
  type of devices.

- Ability to differentiate between carryig an EAP method on its own or
  embedded within another EAP exchange, such as in PEAP.

- Code (or dictionary) impact. For instance, it may be that a new
  value in an existing attribute is easier to support than a new
  attribute. Note that a code change is always required on the NAS
  side, to make the NAS send the new information. However, it may not
  be needed on the server side.

- Administrative ease of update, e.g., IETF Consensus for new
  attributes or new Service-Type values. Designated Expert for new
  values in other attributes.

- Extensibility. How well does the approach support potential
  new uses of EAP?

- Conservative allocation of new code points, such as enumerated
  values, assuming EAP usage becomes more popular in the future.

- Support of both RADIUS and Diameter.

Next we will look in more detail at each of the alternatives
and their properties:

1. Existing values in the NAS-Port-Type attribute
-------------------------------------------------

This value could be used to distinguish IKEv2 and 802.1X as follows:

  NAS-Port-Type = (5) Virtual => IKEv2
  NAS-Port-Type = (19) Wireless - IEEE 802.11 => 802.1X

It does not seem possible to differentiate between plain and tunneled
EAP methods. Similarly, it does not seem possible to differentiate
between IKEv2 and some other protocol that establishes a virtual
tunnel and uses EAP. Extensibility is limited to certain types
of EAP usage.

2. New values in the NAS-Port-Type attribute
--------------------------------------------

A variation of the above alternative: new NAS-Port-Type values could
be defined to make it clearer what virtual protocol is used:
Virtual-IKEv2, Virtual-Somethingelse, etc. New link layer types
or PANA could also be supported. For instance,

  NAS-Port-Type = (19) Wireless - IEEE 802.11 => 802.1X
  NAS-Port-Type = (TBD) Virtual-IKEv2 => IKEv2
  NAS-Port-Type = (TBD) PANA => PANA

The new values can be allocated through Designated Expert. No new RFC
is required. Code/dictionary impact is minimal.

However, this would still not be able to differentiate plain and
tunneled EAP methods. Extensibility is better than in the previous
approach, but still limited to port types where exactly one EAP
encapsulation is used.

Finally, we're not quite sure if the port type are intended for an
extensive listing of what kind of virtual operation is going on; RFC
2865 says "This Attribute indicates the type of the physical port of
the NAS which is authenticating the user."

3. New values in Service-Type attribute
---------------------------------------

A new value could be used to distinguish between "Framed" (most
current network access methods) and, say, "IKEv2".  However, if 802.11
uses the "Framed" value, it seems odd to introduce a different value
for "PANA", so differentation between PANA and 802.1X seems hard.
Similarly, differentiating between plain and tunneled EAP methods is
not possible. Finally, the proliferation of new Service-Type values
does not seem desirable, so future protocols that use EAP (other than
IKEv2) might not fit into this model.

IETF Consensus and a new RFC would be required for this.

Code impact is likely bigger than in the other alternatives, because
of the role of the Service-Type. It is likely that a dictionary
extension is insufficient.

4. New attribute EAP-lower-layer
--------------------------------

In this alternative, a new attribute would indicate the protocol used
for carrying EAP. This would be orthogonal to the service or port type
attributes, although only some combinations would make sense.

It would be possible to differentiate between different network access
protocols employing EAP (PPP/802.1X/PANA), between different virtual
protocols (IKEv2/whatever), and also between tunneled and non-tunneled
EAP usage.

IETF Consensus and a new RFC would be required for this.

Code/dictionary impact would be small, although bigger than in
allocating just a new value in NAS-Port-Type.

A code change would be needed in all NASes, however, and not just the
virtual ones supporting IKEv2. Alternatively, the omission of the new
attribute would be taken to mean something. For instance, lack of the
lower layer attribute could be taken to mean "unknown" or something
based on the current port type or framed protocol attributes.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>