Subject: Comments on draft-ietf-pppext-eap-srp-01.txt

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 7 Apr 2001 10:46:33 -0700

Find enclosed below a review of this specification.

Overall, I think that this work is quite promising,
although there are some incompatibilities with
RFC 2284. However, I believe that the spec can be
reworked so as to be compatible, at the cost of an
additional round-trip.

Section 1

"Unlike all of these protocols, SRP is resistant to man-in-the-middle
attacks."

Do you have a reference to a security analysis that describes the
man-in-the-middle vulnerabilities of MS-CHAPv2? I thought that
only MS-CHAPv1 had this problem.

Section 2

"Unlike CHAP, SRP-SHA1 requires more than one exchange to authenticate
the peer.  For this reason, the usual EAP Request/Response is insuf-
ficient, and two separate Request/Response messages are defined."

Actually, EAP methods are not restricted to a single Request/Response
sequence. RFC 2284, section 2 states:

"After the Link Establishment phase is complete, the authenticator
sends one or more Requests to authenticate the peer.  The Request
has a type field to indicate what is being requested....
The peer sends a Response packet in reply to each Request.  As
with the Request packet, the Response packet contains a type field
which corresponds to the type field of the Request.

The authenticator ends the authentication phase with a Success or
Failure packet."

So an EAP method can use as many request/response sequences as
necessary within a single method.

==================================================================

"The adaptation described in this document uses the EAP Identity
Request/Response mechanism to obtain C from the peer.  It then uses
two new message types -- EAP SRP-SHA1 Parts 1 and 2 -- to handle the
SRP authentication."

Using Identity request/response to obtain C is fine. But using
two EAP types to implement EAP SRP-SHA1 is unnecessary.
RFC 2284 states:

"In practice, within or associated with each PPP server, it is not
anticipated that a particular named user would be authenticated by
multiple methods.  This would make the user vulnerable to attacks
which negotiate the least secure method from among a set (such as PAP
rather than EAP).  Instead, for each named user there should be an
indication of exactly one method used to authenticate that user name.
If a user needs to make use of different authentication methods under
different circumstances, then distinct identities SHOULD be employed,
each of which identifies exactly one authentication method."

Because of this, existing EAP implementations are typically not
built to handle two-stage authentication techniques such as what
you describe. My recommendation would be to use only a single
method.

===================================================================

Section 2.6

"The PPP EAP SRP-SHA1 Success message MUST be sent by the authenticator
in response to a valid EAP SRP-SHA1 Part 2 Response packet, and
MUST NOT be retransmitted on an authenticator time-out."

Responsibility for re-transmission of EAP packets lies with the
authenticator. Thus, if a Response or Request is lost, the Request
is re-transmitted. The exception is EAP-Success messages which
are not ACK'd. RFC 2284 section 2.2.2 states:

"Implementation Note: Because the Success and Failure packets
are not acknowledged, they may be potentially lost.  A peer
MUST allow for this circumstance.  The peer can use a Network
Protocol packet as an alternative indication of Success.
Likewise, the receipt of a LCP Terminate-Request can be taken
as a Failure."

Note that this implies that on loss of the EAP-Success packet,
the authenticatee will need to look for alternative signs of
the authentication result. If the authenticator sends an NCP
packet, then it will conclude that it authentication has
succeeded. The authenticator will not know whether the
authenticatee has received the packet or not -- and thus,
whether the authenticatee has received the data that was
included within the Success packet. I believe that this is
one of the reasons why EAP Success packets do not contain
data.

===============================================================
Also within Section 2.6, you redefine the EAP-Success packet
described in RFC 2284 to appear as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |   Identifier  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Value M2                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         M2 (continued)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         M2 (continued)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         M2 (continued)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         M2 (continued)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I must admit that there have been many times where I have wished for
the ability to transmit data with an EAP Success packet. Unfortunately,
this usage of the EAP Success packet is not permitted according to
RFC 2284, Section 2.2,  which states:

   A summary of the Success and Failure packet format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length

      4

In other words, according to RFC 2284, an EAP Success packet MUST
NOT contain a type field or data. This is a result of the lack of
ACK'ing, as described above. Given that EAP Success messages
conforming to RFC 2284 do not contain data, existing implementations
will typically not pass anything contained beyond the length field
to the EAP method. There are also NAS devices that will not forward
such packets on to the client.

My recommendation is to add an additional round-trip to the protocol
and use the RFC 2284-defined EAP Success message. As much as I
would love to fix RFC 2284 to permit this usage, I think
that this would also require addressing the lack of ACKs for
Success and Failure messages, which would create a backward
compatiblity problem, so I can't see a way to make this work.

======================================================
Date: Tue, 20 Mar 2001 18:55:55 -0500 (EST)
From: James Carlson <[email-masked]>
To: pppext <[email-masked]>
Subject: Secure Remote Password interest

I asked this at the working group meeting today, and I'd like to put
it to the group at large: if there are folks out there looking at the
EAP SRP-SHA1 draft (draft-ietf-pppext-eap-srp-01.txt) please let me
know; either privately or on the list.

I have tested an implementation based on ANU ppp-2.4.0, and I'm
planning to release this under a BSD license (pending some document
signatures within Sun).  This could serve as a reference
implementation for testing purposes.

I've gotten reports from the open source community that there's user
interest, mostly because it fixes the CHAP shared secret problem.

--
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
Second Edition now available - http://people.ne.mediaone.net/carlson/ppp

---

From: James Carlson <[email-masked]>
Date: Wed, 11 Apr 2001 18:29:59 -0400 (EDT)

> only MS-CHAPv1 had this problem.

There's a good discussion of the weaknesses of MS-CHAPv2, but not the
man-in-the-middle attacks, here:

	http://www.counterpane.com/pptpv2-paper.html

I don't have references on the man-in-the-middle vulnerabilities, and
my statement was an overbroad generalization.  As Vern Schryver
pointed out in an earlier message, I should rework this section.  A
much bigger benefit of SRP is that it's highly resistant to
dictionary-based attacks, and none of the alternatives (including
MS-CHAPv2) are.

> sequence. RFC 2284, section 2 states:
[...]
> necessary within a single method.

What I mean here is that the *USUAL* use of Request/Response is not
enough, and that multiple Request/Response sequences are needed within
this single method.

I agree that this needs some work.

> you describe. My recommendation would be to use only a single

The multiple stages are a requirement of SRP.  There's no getting
around that.

I can, however, collapse this down to a single type, and I think I
probably should.  The new Request/Response type would have a
discriminator octet at the beginning of the payload, and use these
values:

	1 - Part 1 of authentication
	2 - Part 2
	3 - M2 transmittal

This also fixes the oddly-modified EAP Success message.

> compatiblity problem, so I can't see a way to make this work.

Agreed.

Many thanks for the comments!

---

From: James Carlson <[email-masked]>
Date: Wed, 11 Apr 2001 21:12:38 -0400 (EDT)

Bernard Aboba writes:
> > A much bigger benefit of SRP is that it's highly resistant to
> Yes, that is it's major advantage. That is particularly important in
> wireless applications, I think. 

In fact, one of the folks who contacted me off-list is involved in
LAN-type wireless effort, so I think that's a fair guess.  (My
interest was in tunneling, but the issues are somewhat similar.)

> You're welcome. I think that EAP-SRP should be on the Standards Track. Is
> that the plan?

Yes.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Apr 2001 18:01:15 -0700 (PDT)

> The new Request/Response type would have a

This seems like a reasonable way of going about it.