Subject: [AAA-WG]: Reviewed of proposed EAP text

From: Bernard Aboba <[email-masked]>
Date: Wed, 27 Jun 2001 14:39:00 -0700 (PDT)

> 4.0  Extensible Authentication Protocol Support
> 
>    The Extensible Authentication Protocol (EAP), described in [25],
>    provides a standard mechanism for support of extensible
>    authentication methods. Through the use of EAP, support for a number
>    of authentication schemes may be added, including smart and token
>    cards, Kerberos, Public Key, One Time Passwords, and others.
> 
>    This section describes the Command-Codes values and AVPs that are
>    required for an EAP payload to be encapsulated within the Diameter
>    protocol. Since authentication occurs between the EAP client and its
>    home Diameter server, end-to-end authentication is achieved, reducing
>    the possibility for fraudulent authentication, such as replay and
>    man-in-the-middle attacks. End-to-end authentication also provides
>    for mutual (bi-directional) authentication, which is not possible
>    with PAP and CHAP in a roaming PPP environment.
> 
>    The EAP conversation between the authenticating peer and the access
>    device begins with the negotiation of EAP within a link layer, such
>    as PPP or 802.1x. 

Actually, EAP isn't negotiated in 802.1X. So I'd just say "initiation of
EAP".

>    Once EAP has been negotiated, the access device
                    substitute "intitiated"

>    will typically send to the Diameter server a Diameter-EAP-Request
>    message with a NULL EAP-Payload AVP, signifying an EAP-Start. The
>    Port number and the identity of the access device (e.g. Origin-Host
>    or NAS-Identifier) MUST be included in the Diameter-EAP-Request
>    message.
> 
>    If the Diameter home server supports EAP, it MUST respond with a
>    Diameter-EAP-Answer message containing an EAP-Payload AVP that
>    includes an encapsulated EAP payload [25], and the Result-Code AVP
>    set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent
>    request is expected. The EAP payload is forwarded by the access
>    device to the EAP client.
> 
>    The initial Diameter-EAP-Answer in a multi-round exchange normally
>    includes an EAP-Request/Identity, requesting the EAP client to
>    identify itself. Upon receipt of the EAP client's EAP-Response [25],
>    the access device will then issue a second Diameter-EAP-Request
>    message, with the client's EAP payload encapsulated within the EAP-
>    Payload AVP.
> 
>    A preferred approach is for the access device to issue the EAP-
>    Request/Identity message to the EAP client, and forward the EAP-
>    Response/Identity packet, encapsulated within the EAP-Payload AVP, as
>    a Diameter-EAP-Request to the Diameter server. This alternative
>    reduces the number of Diameter message round trips, and is compatible
>    with roaming environments, since the Destination-Realm is needed by
>    Diameter agents for routing purposes. Note that this alternative
>    cannot be universally employed, as there are circumstances where a
>    user's identity is not needed (such as when authorization occurs
>    based on a calling or called phone number).

Actually, in this case doesn't the called or calling phone number end up
in the User-Name AVP?

> 
>    The conversation continues until the Diameter server sends a
>    Diameter-EAP-Answer with a Result-Code AVP indicating success or
>    failure, and an optional EAP-Payload. The Result-Code AVP is used by
>    the access device to determine whether service is to be provided to
>    the EAP client. The access device MUST NOT rely on the contents of
>    the optional EAP-Payload to determine whether service is to be
>    provided.

Good.

> 
>    A Diameter-EAP-Answer message containing an EAP-Payload of type EAP-
>    Success or EAP-Failure MUST NOT have the Result-Code AVP set to
>    DIAMETER_MULTI_ROUND_AUTH.
> 
Good.

>    If authorization was requested, a successful Diameter-EAP-Answer MUST
>    also include the appropriate authorization AVPs required for the
>    service requested (see sections 2.0, 6.0 and 7.0).
> 

Can a Diameter message with Result-Code = DIAMETER_MULTI_ROUND_AUTH
also contain such AVPs? I would not prohibit this, necessarily. 

>    Unless the access device interprets the EAP-Response/Identity packet
>    returned by the authenticating peer, it will not have access to the
>    user's identity. Therefore, the Diameter Server SHOULD return the
>    user's identity by inserting it in the User-Name attribute of
>    subsequent Diameter-EAP-Answer packets. Without the user's identity,
>    the Session-Id AVP MAY be used for accounting and billing, however
>    operationally this MAY be very difficult to manage.
> 
>    A home Diameter server MAY request EAP re-authentication by issuing
>    the Re-Auth-Request [2] message to the Diameter client.
> 
>    Should an EAP authentication session be interrupted due to a home
>    server failure, the session MAY be directed to an alternate server,
>    but the authentication session will have to be restarted from the
>    beginning.
> 
>    If a response is received with the Result-Code set to
>    DIAMETER_COMMAND_UNSUPPORTED [2], it is an indication that the
>    Diameter server in the home domain does not support EAP. If possible,
>    the access device MAY attempt to negotiate another authentication
>    protocol, such as PAP or CHAP. An access device SHOULD be cautious
>    when determining whether a less secure authentication protocol will
>    be used, since this could be a result of a bidding down attack.
> 
> 
> 4.1  Alternative uses
> 
>    Currently the conversation between the backend authentication server
>    and the Diameter server is proprietary because of lack of
>    standardization. In order to increase standardization and provide
>    interoperability between Diameter vendors and backend security
>    vendors, it is recommended that Diameter-encapsulated EAP be used for
>    this conversation.
> 
>    This has the advantage of allowing the Diameter server to support EAP
>    without the need for authentication-specific code within the Diameter
>    server. Authentication-specific code can then reside on a backend
>    authentication server instead.
> 
>    In the case where Diameter-encapsulated EAP is used in a conversation
>    between a Diameter server and a backend authentication server, the
>    latter will typically return an Diameter-EAP-Answer/EAP-Payload/EAP-
>    Success message without inclusion of the expected authorization AVPs
>    required in a successful response. This means that the Diameter
>    server MUST add these attributes prior to sending an Diameter-EAP-
>    Answer/EAP-Payload/EAP-Success message to the access device.
> 
> 4.2  Command-Codes Values
> 
>    This section defines new Command-Code [2] values that MUST be
>    supported by all Diameter implementations conforming to this
>    specification. The following Command Codes are defined in this
>    section:
> 
>       Command-Name             Abbrev.    Code       Reference
>       --------------------------------------------------------
>       Diameter-EAP-Answer       DEA       268          4.2.2
>       Diameter-EAP-Request      DER       268          4.2.1
> 
> 
> 
> 4.2.1  Diameter-EAP-Request (DER) Command
> 
>    The Diameter-EAP-Request (DER) command, indicated by the Command-Code
>    field set to 268 and the 'R' bit set in the Command Flags field, is
>    sent by a Diameter client to a Diameter server and conveys an EAP-
>    Response [25] from the EAP client. The Diameter-EAP-Request MUST
>    contain one EAP-Payload AVP, which contains the actual EAP payload.
>    An EAP-Payload AVP with no data MAY be sent to the Diameter server to
>    initiate an EAP authentication session.
> 
>    The DER message MAY be the result of a multi-round authentication
>    exchange, which occurs when the DEA is received with the Result-Code
>    AVP set to DIAMETER_MULTI_ROUND_AUTH. A subsequent DER message MUST
>    include any State AVPs that were present in the DEA. For re-
>    authentication, it is recommended that the Identity request be
>    skipped in order to reduce the number of authentication round trips.
>    This is only possible when the user's identity is already known by
>    the home Diameter server.
> 
> 
>    Message Format
> 
>       <Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
>                                  < Session-Id >
>                                  { Auth-Application-Id }
>                                  { Origin-Host }
>                                  { Origin-Realm }
>                                  { Destination-Realm }
>                                  { Service-Type }
>                                  { EAP-Payload }
>                                  [ Destination-Host ]
>                                  [ Authorization-Lifetime ]
>                                  [ Session-Timeout ]
>                                  [ User-Name ]
>                                  [ Idle-Timeout ]
>                                  [ NAS-IP-Address ]
>                                  [ NAS-Identifier ]
>                                  [ State ]
>                                  [ Origin-State-Id ]
>                                  [ NAS-Key-Binding ]
>                                * [ AVP ]
>                                * [ Proxy-Info ]
>                                * [ Route-Record ]
> 

This reminds me. Is there an accounting AVP that includes the EAP
authentication type? I think we need one. 

> 
> 4.2.2  Diameter-EAP-Answer (DEA) Command
> 
>    The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code
>    field set to 268 and the 'R' bit cleared in the Command Flags field,
>    is sent by the Diameter server to the client for one of the following
>    reasons:
> 
>       1) The message is part of a multi-round authentication exchange,
>          and the server is expecting a subsequent Diameter-EAP-Request.
>          This is indicated by setting the Result-Code to
>          DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State
>          AVPs.
>       2) the EAP client has been successfully authenticated and
>          authorized, in which case the message MUST include the Result-
>          Code AVP indicating success, and SHOULD include an EAP-Payload
>          of type EAP-Success.  This event MUST cause the access device
>          to provide service to the EAP client.

Would delete the word "authorized", since EAP doesn't do authorization
per se. I think it is reasonable that a successful auth SHOULD include an
EAP-Success -- otherwise the AAA server would be granting access to
someone that the EAP module said was not authentic. 

>       3) The EAP client has not been successfully authenticated and/or
>          authorized, and the Result-Code AVP is set to indicate failure.
>          This message MAY include an EAP-Payload, but this AVP is not
>          used to determine whether service is to be provided.

I would say that it SHOULD include an EAP-Payload. We don't want to
encourage people not to include such a payload because the absence of one
will result in an IEEE 802.1X timeout. 

> 
>    If the message from the Diameter client included a request for
>    authorization, a successful response MUST include the authorization
>    AVPs that are relevant to the service being provided.
> 
>    Message Format
> 
>       <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
>                                 < Session-Id >
>                                 { Auth-Application-Id }
>                                 { Result-Code }
>                                 { Origin-Host }
>                                 { Origin-Realm }
>                                 { Destination-Host }
>                                 { Service-Type }
>                                 [ Error-Reporting-Host ]
>                                 [ EAP-Payload ]
>                                 [ User-Name ]
>                                 [ Idle-Timeout ]
>                                 [ Authorization-Lifetime ]
>                                 [ Session-Timeout ]
>                                 [ Origin-State-Id ]
>                               * [ NAS-Session-Key ]
>                               * [ AVP ]
>                               * [ Proxy-Info ]
>                               * [ Route-Record ]
> 
> 
> 4.3  EAP-Payload AVP
> 
>    The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used
>    to encapsulate the actual EAP payload [25] that is being exchanged
>    between the EAP client and the home Diameter server.
>

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 27 Jun 2001 14:58:50 -0700

Thanks for the review.

Comments below.

> Actually, in this case doesn't the called or calling phone number end up

not in Diameter. The User-Name isn't mandatory, as it is in RADIUS. 

> also contain such AVPs? I would not prohibit this, necessarily. 

ok.

> authentication type? I think we need one. 

ok

> someone that the EAP module said was not authentic. 

in EAP terms no, but in Diameter terms, the user was both authenticated, and
authorized for service. The above text doesn't speak directly about the EAP
message, but the Diameter answer message. So, I think leaving the authorized
is fine.

> will result in an IEEE 802.1X timeout. 

ok

Thanks for the comments. Were there any additional issues that weren't covered
with the new text? Can I close this issue?

Thanks,

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 27 Jun 2001 16:37:23 -0700 (PDT)

>Can we close this issue?

From my perspective, yes. Anyone else in the WG have comments on this?