Subject: comments on draft-ietf-pppext-eap-srp-03.txt

From: Lauri Tarkkala <[email-masked]>
Date: Thu, 22 Nov 2001 17:19:12 +0200

I was re-reading the draft on EAP SRP, and came across in my opinion
a possibly dubious overloading of the NAK type.

Below a quote from the relevant portions of the specification:

>2.1.  EAP SRP-SHA1 Packet Formats
>
>   All EAP SRP-SHA1 authentication is driven by the authenticator
>   (server).  The authenticatee (client) MUST NOT retransmit Response
>   messages, but SHOULD terminate the link if a Request is not received
>   within a reasonable time period.  The authenticator SHOULD silently
>   ignore unexpected Response messages.  The authenticatee MUST respond
>   using EAP Nak if any unknown Subtype or otherwise unacceptable mes-
>   sage is received.
>
>   Rationale:
>
>       Although the EAP Nak message is intended to signal only that a
>       given EAP Type is unknown to the authenticatee and that a
>       different Type should be used, its use here is still consistent
>       with that meaning.  If the authenticator attempts to use a
>       subtype unknown to the authenticatee, then authentication using
>       EAP SRP-SHA1 is itself not possible, and another Type should be
>       tried.

Consider now the case that the authenticatee is configured to attempt
authentication using only EAP-SRP, and the authenticator is running an
incompatible version and attempts to use a EAP-SRP subtype
not recognized by the authenticatee.

The authenticatee EAP-SRP implementation correctly recognizes the subtype
as unsupported, and is going to respond with a proper "NAK" message, but
as it stands, there is no way for it to inform the authenticator of
this.

It could send an EAP Nak with type "EAP-SRP" as the parameter, but
unfortunately this would, for obvious reasons, not solve the problem.
The only viable option is to let the authentication timeout, which
is not IMHO desirable. 

The EAP protocol identifies authentication methods using only the
"type" field. The protocol does not really offer any mechanisms
for differentiating between incompatible versions of authentication
methods. Indeed, if it did, the above scenario would not be a problem.

For EAP-SRP to stay within this thinking, the trivial solution is
to assign different EAP types to different versions of the EAP-SRP
protocol.

The trivial solutions that come to mind are:

- Update the newest EAP draft to specify that a EAP NAK message
  of length 4 bytes (meaning that the Type-Data field is empty)
  represents a "I cannot authenticate with any method" signal
  from the authenticator.

  This seems to actually have been the intent, as RFC2284 states:

>      unacceptable to the peer.  When sending a Nak in response to a
>      Request, the peer MAY indicate an alternative desired
>      authentication Type which it supports. An initial specification of

  Yet, later it specify the Type-Data field of the Nak-Reply message:

>      This field MUST contain a single octet indicating the desired
>     authentication type.

  The latest rfc2284bis drafts, have the same ambiguity.

- Remove the use of the EAP Nak type from the EAP-SRP protocol, and assume
  that if a new revision is made, it will assume another EAP type.

I feel that both "fixes" should be done.

Lauri

-- 
Lauri Tarkkala
SSH Communications Security Corp

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 Nov 2001 07:23:58 -0800 (PST)

>   The latest rfc2284bis drafts, have the same ambiguity.

Yes, they do, and this should be fixed in RFC 2284bis.

However, I'm not sure what is accomplished by allowing a "no types
supported" message. All EAP implementations  should be able to
successfully negotiate at least one method - EAP-MD5. So "no types
supported" would seem to be at variance with this. 

Wouldn't allowing a "no types supported" Nak in effect be removing the
necessity of implementing MD5? Wouldn't this cause interoperability
problems? Also, how would allowing a "no types supported" message address
this particular problem?

I'd note that this is not the only question that has arisen about the Nak
Type. We have also had the suggestion that a Nak packet be able to contain
multiple Type octets. 

>   that if a new revision is made, it will assume another EAP type.

I would agree with this suggestion.

---

From: Lauri Tarkkala <[email-masked]>
Date: Thu, 22 Nov 2001 19:05:27 +0200

> supported" would seem to be at variance with this. 

I feel that EAP should allow an authenticatee to specify a policy
for what protocols to use. If the user wishes to use only
authentication protocols that provide strong protection for
the authenticatee (such as EAP-SRP attempts to protect the secret
passphrase) or ones that perform authenticated key-exchange, then this
should be possible.

I personally do think that requiring all implementations to
support MD5-Challenge is a "good thing". Yet I do not think
that all users will wish to use it, if better alternatives
exist.

> problems? Also, how would allowing a "no types supported" message address

The "no types supported" problem in this case arose from the fact that
the authenticatee and authenticator implemented incompatible versions
of a protocol with the same EAP type and the user's policy would
not allow using a weaker protocol.

My proposal for a "no types supported" Nak basically was
for the reason that assuming that EAP authentiation types
would start being incompatible (yet retain the same EAP Type
values), then a mechanism for informing the server that "I do not
know how to proceed", would be good, as the other option
is for the client to let the authentication time out. This
thinking followed from the EAP-SRP draft.

The motivation for a "no types supported" Nak is, in a
sense, a fatal interoperability problem.

The reason for this may very well be, that the authenticatee
is not complying with the spec, and has not implemented
MD5, as you suggest above.

The best alternative (obviously) is to keep the EAP Types
unambgiuously specified, but I fear that this may not
happen in practice.

Lauri

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 Nov 2001 08:52:33 -0800 (PST)

> unambgiuously specified, but I fear that this may not

I think that this is indeed a better alternative, and the entire
"versioning" issue is best avoided by allocating new EAP Types. The one
potential wrinkle with this could occur if we start nearing exhaustion of
the EAP type space.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Nov 2001 13:07:07 +0200

>supported" would seem to be at variance with this. 

Support and allowed use may be different issues. It
could be that policy dictates you only allow FOOBAR,
not MD5 even if you perhaps support it in the code
base.

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 23 Nov 2001 08:17:41 -0800 (PST)

> not MD5 even if you perhaps support it in the code

If you only allow FOOBAR -- then you can Nak and indicate that type, no?