eap Mailing List: AD Review of EAP POTP

[Bernard Aboba (bernard_aboba]

---------- Forwarded message ----------
Date: Wed, 31 May 2006 00:48:39 +0300
From: Jari Arkko <jari.arkko [at] piuha.net>
To: magnus [at] rsasecurity.com
Subject: AD review of EAP POTP

Magnus,

I have done my AD review on your document.

Overall, I was quite happy with the document -- its well
written and seems clear. Some comments below, however.

I would suggest that you will revise the
document where necessary and resubmit, at which time we
can initiate the actual processing, and also call the document
into the attention of the IETF community (e.g. EAP/EMU folks).

Russ: it would be great if you too could review this, or organize
a review in the secdir. The most interesting focus for the review
would be the crypto parts.

----

> Even though the authenticator in practice may function as a client
> with respect to the backend authentication server, relaying
> authentication credentials et cetera as needed, both servers are,
> unless explicitly mentioned, collectively denoted as "the EAP server"
> here.

This seems to re-define the term "EAP Server" in a manner
inconsistent with RFC 3748. Please modify to avoid
confusion.

> 4.1 overview

Comment only - take this into account if you find a good way to do it:
It was unable to convince myself that this description covers all the
cases. But perhaps it doesn't have to, its an overview.  Maybe it is
written in too normative style to begin with.

> They MUST also
> consider the validity of certain algorithm combinations.

Be more specific.

> If the authentication of the peer fails, the EAP server SHOULD
> send another EAP-Request containing an OTP TLV and a Server-Info
> TLV with the N bit set to indicate that no session resumption is
> possible.  The EAP server MAY also send an EAP-Failure message,
> possibly preceded by an EAP-Request of type Notification (2).

This is correct, but I presume that if EAP Failure is sent, that's the
end of the EAP operation and we do not try again. I'm hoping that
that's what you mean here, because otherwise it would be in violation
of RFC 3748.

> Sessions MUST NOT be maintained longer than the security of the
> exchange which created the session permits.  E.g. if it is estimated
> that an attacker could be successful in brute-force searching for the
> OTP in 24 hours, then EAP-POTP session lifetimes should be clearly
> less than this value.

This MUST NOT is problematic, because its hard to evaluate
the security of the exchange in exact terms; I would suggest
"NOT RECOMMENDED to" be used instead.

> The MSK may be used as an ISK_i, for some i, as described in Section
> 2.5 of [14].  It may also be used as a basis for an AAA-Key (see
> [15]) when setting up security associations between peers, or as a
> starting point for derivation of MPPE [16] keys (see Appendix C).

> The EMSK is reserved for future use.

I would prefer just saying "The use of the MSK and EMSK is
defined in [RFC 3748] and [eap-keying]." instead of the
two paragraphs above. Its certainly meant to be so that
whatever MSK is used for, the MSK from EAP POTP can be
used for that as well.

> Instead, when a peer cannot continue an EAP-POTP session either due
> to the server not being able to authenticate itself or due to some
> other reason

There's something wrong in this sentence. Maybe you meant ... the
peer is unable to authenticate the server or ..."?

Also, it would be very useful to spell out the "some other reason"
part in more detail, so that people can implement this.

> The EAP Identity method MUST NOT be used within an EAP-POTP session.

This may be more confusing than helpful. You do
allow EAP Identity at the beginning (Sect 4.1)
and RFC 3748 Section 2.1 already prohibits other
use of EAP Identity.

> Reserved
>
>    Reserved for future use.  This octet MUST be set to zero for this
>    version.

And ignored upon reception? Multiple places in the document.

> In an 802.1x EAP over LAN (EAPOL) environment, the P bit MUST be
> set, or, alternatively, the EAP-POTP method MUST be carried out
> inside an authenticated tunnel such as those provided by [14] or
> [17].

This seems somewhat weird recommendation. Why LAN and not Wireless
LAN? What about all the other scenarios where protection would be
needed? Also, how does the EAP method know what purpose it is being
run for...  I would suggest saying something different, e.g.  "It is
RECOMMENDED that the protected mode of EAP-POTP (or an authenticated
tunnel [14]) is used for authentication in wireless environment. And
the statement would be more appropriate in the security considerations
than in the bit-level description.

> In an EAP-Request, the T bit, when set, indicates that the OTP to
> calculate MUST NOT include a user PIN.
>
> In an EAP-Response, the T bit, when set, indicates that the OTP
> was calculated without the use of a user PIN.  The T bit MUST be
> set in a response if and only if the EAP-Request which triggered
> the response contained an OTP TLV with the T bit set.

Isn't there a policy question on the client's side, whether
the client wants to use his authentication token without
his personal authorization via a PIN? Perhaps the client should
be allowed to decline this. I think it can already via an
empty response, but it would be good to confirm this explicitly
in the spec.

> Authentication Data
>
> EAP-Request: In an EAP-Request, the Authentication Data, when
>    present, contains an optional "challenge".

I found the optionality of this field and the use of
the C bit confusing. What if C=1 and datalen=0 or
C=0 and datalen>0?

> The following applies to the auth_id component:
> (snip)
>  -  For IP-based EAP, "auth_id" SHALL either be the empty
>     string or the IPv4 or IPv6 address of the authenticator
>     in binary format (4 respectively 16 octets).  As an
>     example, the IPv4 address "10.129.13.15" would be
>     represented as (in hex) 0A 81 0D 0F, whereas the IPv6
>     address "0A0A:0B0B:0C0C:0D0D:0E0E:0F0F:1010:1111" would
>     be represented as (in hex) 0A 0A 0B 0B 0C 0C 0D 0D 0E 0E
>     0F 0F 10 10 11 11.

Which IP address? What if the authenticator has an
"outer" IP address as an IKEv2 gateway having a public
IP address and an "inner" address, as in the same
gateway having dot ten address in the corporate
network?

> At least one of the User Identifier TLV and the Token Key Identifier
> TLV MUST be present in the session's first EAP-Response of type
> POTP-X that also carries an OTP TLV unless a suitable identity has
> been provided in a preceding EAP-Response of type Identity (1).

This MUST seems too strong, see Section 2 of RFC 3748
for cases where other means may be used to determine
the identity of the client. This should still be
allowed even in EAP-POTP.

>  This document is a description of a general EAP method for OTP
>  tokens.  It also defines EAP method 32 as a profile of the general
>  method.  It has no actions for IANA.  Extending the set of EAP-POTP
>  TLVs or the set of EAP-POTP cryptographic algorithms shall be seen as
>  revisions of the protocol and hence requiring an RFC that updates, or
>  obsoletes this document.

I'd prefer seeing a new namespace created for EAP-POTP TLVs,
with a specific policy (e.g. Specification Required and
IESG Approval).

> This TLV type may be sent by EAP servers as well as by peers and
> SHOULD be supported by all entities conforming to this specification
> (it need not be supported if an entity never will have a need to
> continue a POTP-X conversation after exchange of the Confirm TLV).

A peer would not necessarily know if the server wants it
to continue. Should this be mandatory?

While an expert review per se is not needed
for this submission (given the already existing
allocation), I have also reviewed the document
from this perspective -- see below.

> 1. Does the method document its security properties
> in sufficient manner, as required by Section 7.2
> of RFC 3748?
>
> 1a. Mechanism. Is the mechanism explained?

Yes.

> 1b. Security claims. Are the claimed and not claimed
> properties listed?

Yes.

> 1c. Justifications for the claims? Is an explanation or
> reference provided to each of the claims?

Yes.

> 1d. Key strength. Is the key strength documented?

Only the parameters that affect it are specified.
For a more useful security considerations section,
at least an example should be provided.

> 1e. Description of key hierarchy. Is the key hierarchy
> documented?

Yes.

> [Optional, at least for now: does it conform to EAP
> keying framework?]

Yes.

> 1f. Indication of vulnerabilities. Are the known vulnerabilities
> documented?

Yes.

> [Note: it seems unreasonable to require the documentation
> of unknown vulnerabilities :-) The "known" may of course be
> "known to reviewer" or "known to author" or "known to the
> community", but that appears to be best we can do.]
>
> 2. Compliance with EAP packet formats
>
> 2a. Does the method comply with the packet formats
> defined in Section 4 of RFC 3748?

Yes.

> 3. Compliance with EAP behaviour
>
> 3a. Does the method comply with Success/Failure usage
> as defined in Sections 2, 2.2, and 4.2?

Yes.

> 3b. Does the method comply with sequence usage as defined
> in Section 2.1 of RFC 3748?

Yes.

> 3c. Does the method comply with request/response processing
> rules as defined in Section 4.1 of RFC 3748?

Yes.

> 3d. Does the method comply with retransmission rules
> as defined in Section 4.3 of RFC 3748?

Yes.

> 3e. Does the method comply with the usage defined for
> Identity, as defined in Section 5.1 of RFC 3748?

Yes.

> 3f. Does the method comply with the usage defined for
> Notification, as defined in Section 5.2 of RFC 3748?

Yes.

> 3g. Does the method comply with the usage defined for
> Nak and Expanded-Nak as defined in Section 5.3 of RFC 3748?

Yes.

> 3h. Does the method comply with the MIC usage requirements
> from Sections 3.1, 7.5, and 7.8 of RFC 3748?

Part 1: No. MIC checking is not sufficiently required
in Section 4.10.15, and the entire Protected TLV is
optional.

Part 2: Yes. Section 7.5 recommends covering all EAP fields,
but EAP-POTP does not do this. However, the explanation
appears sufficient grounds for going against the
recommendation.

> 4. Compliance with IANA requirements
>
> 4a. Does the method comply with EAP-based IANA requirements
> defined in Section 6 of RFC 3748? That is, if it requests
> the allocation of new numbers in the EAP namespace [not
> applicable if the numbers have already been allocated],
> is the type of the document and process appropriate for the
> desired action?

Yes.

> 4b. Does the method comply with other IANA requirements in
> the IETF standards track RFCs? For instance, does the
> method attempt to allocate TLS extensions (which would
> only be possible for standards track RFCs)?

Yes (complies).