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

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Jun 2001 14:33:36 -0700 (PDT)

Overall, this version of the draft is much improved. 

Here are some additional comments based on the -02 draft:

Page 1: 

"This document defines an authentication mechanism for EAP called SRP-SHA1
and allows the use of the Secure Remote Password (SRP) [3] protocol as a 
PPP link authentication method."

[BA - EAP is now being used as a link authentication method for IEEE 802
and possibly Bluetooth. Suggest that we look at generalizing the text to
cover these cases as well. For example in the above sentence "PPP" could
be deleted, enabling use of EAP SRP for authentication of other links,
too.]

Section 2.1, page 4: 

"All SRP 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 message is received."

I think this paragraph is at variance with text within RFC 2284. Recommendation 
is that an Alert message be added so as not to overload use of EAP Nak,
and reference RFC 2284 sections so as to ensure sync.

 For example, RFC 2284, section 2.2.1 states:

The Request packet is sent by the authenticator to the peer.  Each Request has a type 
field which serves to indicate what is being requested.  The authenticator MUST transmit 
an EAP packet with the Code field set to 1 (Request).  Additional Request packets MUST 
be sent until a valid Response packet is received, or an optional retry counter expires.  
Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish 
them from new Requests.  The contents of the data field is dependent on the Request type.  
The peer MUST send a Response packet in reply to a Request packet.  Responses MUST 
only be sent in reply to a received Request and never retransmitted on a timer.  The 
Identifier field of the Response MUST match that of the Request."

This seems to indicate that the authenticatee MUST transmit additional Request packets 
instead of silently ignoring unexpected Response messages. 

Also, RFC 2284, section 2.2.1 states:

"However, there is also a Nak Response Type for indicating that a Request type is
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 Types follows in a later section of this document."

So the purpose of the NAK message is to indicate an unacceptable Request type, not to 
indicate an unknown Subtype or otherwise unacceptable message. Currently a Nak message 
is only able to indicate the alternative desired authentication Type,
rather than indicating errors of other types. 

Section 2.1, page 4: 

"The Identifier SHOULD be changed for each Request message sent."  

This seems to conflicts with RFC 2284, section 2.2.1 which states: 

"The Identifier field is one octet.  The Identifier field MUST be the same if a Request 
packet is retransmitted due to a timeout while waiting for a Response.  Any new 
(non-retransmission) Requests MUST modify the Identifier field.  If a peer recieves 
a duplicate Request for which it has already sent a Response, it MUST resend its 
Response.  If a peer receives a duplicate Request before it has sent a Response to 
the initial Request (i.e. it's waiting for user input), it MUST silently 
discard the duplicate Request."

Recommend that the document copy the RFC 2284 text or refer to it. 

Section 2.2, page 5: 

"A single octet specifying the type of hash algorithm to be used with SRP.  
For SHA-1 based SRP as described in this document, this value MUST be set to 1.  
An authenticatee that does not support the hash algorithm specified by the 
authenticator MUST reply with EAP Nak to disable EAP SRP authentication."

Like the idea of supporting multiple hash algorithms. However, I
think you're overloading use of EAP Nak here; it's really only used to
negotiate alternative EAP methods, not as a general purpose error
indication.  I'd suggest defining an Alert message with EAP SRP that can
be used to transmit error conditions of various sorts. However this
wouldn't get you the negotiation capabilities that I think are needed (see
below). 

Since the hash type can now be varied, that perhaps the protocol should be 
entited simply "EAP SRP" instead of "EAP SRP-SHA1"?

Section 2.5, page 9:

"The above described SHA1 hash to produce the long-term private key x, as described in 
[3], SHOULD be used by default in EAP SRP-SHA1.  As an implementation open, however, 
the x value used above MAY instead be derived from any mutually-chosen hashing 
algorithm, provided that the security of that algorithm is acceptable to both 
authentication parties."

Given that an EAP Nak cannot suggest an alternative hash algorithm, only a
new EAP method, it's not clear how  the hash algorithm can be mutually 
chosen if there are multiple choices available. Perhaps multiple hash types need to be 
advertised by the authenticator, with one chosen by the client in the Client 
Key Subtype-data? 

On a slightly separate note, perhaps it makes it makes sense to expand the
size of the field to two octets so as to allow for a  protected
ciphersuite negotiation, which would include both the cipher and the
hash. Note that this would require adding the selected ciphersuite to the
final hash so as to protect against modification by man in the middle.  

Examples

I think that some examples of how EAP SRP authentication will proceed in
successful and unsuccessful cases would be helpful. Here are some
examples that might be worth including:

In the case where the EAP SRP mutual authentication is successful, the
conversation will appear as follows:

Authenticating Peer     Authenticator
-------------------     -------------
                        <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                        <- EAP-Request/
                        EAP-Type=EAP SRP,
                        Subtype 1
                        (cipersuite?, salt, prime
                         modulus, generator)
EAP-Response/
EAP-Type=EAP SRP,
Subtype 1
(ciphersuite?, A)->
                        <- EAP-Request/
                        EAP-Type=EAP SRP,
                        Subtype 2
                        (B)

EAP-Response/
EAP-Type=EAP SRP,
Subtype 2
(M1) ->
                        <- EAP-Request/
                        EAP-Type=EAP SRP,
                        Subtype 3
                        (M2)
EAP-Response/
EAP-Type=EAP SRP,
Subtype 3 ->
                        <- EAP-Success

In the case where server authentication is unsuccessful, the
conversation will appear as follows:

Authenticating Peer     Authenticator
-------------------     -------------
                        <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                        <- EAP-Request/
                        EAP-Type=EAP SRP,
                        Subtype 1
                        (cipersuite?, salt, prime
                         modulus, generator)
EAP-Response/
EAP-Type=EAP SRP,
Subtype 1
(ciphersuite?, A)->
                        <- EAP-Request/
                        EAP-Type=EAP SRP,
                        Subtype 2
                        (B)

EAP-Response/
EAP-Type=EAP SRP,
Subtype 2
(M1) ->
                        <- EAP-Request/
                        EAP-Type=EAP SRP,
                        Subtype 3
                        (M2)
EAP-Response/
EAP-Type=EAP SRP,
Subtype 3 ->
                        <- EAP-Failure

In the case where the client fails to authenticate to the server, the
conversation will appear as follows:

Authenticating Peer     Authenticator
-------------------     -------------
                        <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                        <- EAP-Request/
                        EAP-Type=EAP SRP,
                        Subtype 1
                        (cipersuite?, salt, prime
                         modulus, generator)
EAP-Response/
EAP-Type=EAP SRP,
Subtype 1
(ciphersuite?, A)->
                        <- EAP-Request/
                        EAP-Type=EAP SRP,
                        Subtype 2
                        (B)

EAP-Response/
EAP-Type=EAP SRP,
Subtype 2
(M1) ->
                        <- EAP-Failure

In the case where server authentication is unsuccessful, the
conversation will appear as follows:

Authenticating Peer     Authenticator
-------------------     -------------
                        <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                        <- EAP-Request/
                        EAP-Type=EAP SRP,
                        Subtype 1
                        (cipersuite?, salt, prime
                         modulus, generator)
EAP-Response/
EAP-Type=EAP SRP,
Subtype 1
(ciphersuite?, A)->
                        <- EAP-Request/
                        EAP-Type=EAP SRP,
                        Subtype 2
                        (B)

EAP-Response/
EAP-Type=EAP SRP,
Subtype 2
(M1) ->
                        <- EAP-Request/
                        EAP-Type=EAP SRP,
                        Subtype 3
                        (M2)
EAP-Response/
EAP-Type=EAP SRP,
Subtype 3 
[Disconnect] ->
                        <- EAP-Failure

[Question: how is the Disconnect action expressed 
when EAP runs over IEEE 802 media?]

---

From: James Carlson <[email-masked]>
Date: Tue, 12 Jun 2001 12:58:19 -0400 (EDT)

> Overall, this version of the draft is much improved. 

Thanks ...

> be deleted, enabling use of EAP SRP for authentication of other links,

OK.  (Note that the underlying EAP document makes multiple explicit
references to PPP as well.)

> and reference RFC 2284 sections so as to ensure sync.

While I recognize that the mechanism in EAP is extremely limited, I'm
not so sure it's helpful to add a new EAP message type to carry this
distinction.

>  For example, RFC 2284, section 2.2.1 states:
[...]
> instead of silently ignoring unexpected Response messages. 

I don't get that from the 2.2.1 text, and the two clauses in your
statement are most certainly not in conflict.  The only thing section
2.2.1 says is that the authenticator MUST continue *retransmitting*
until it receives a valid Response message or the retry counter
expires.  Retransmit is defined only in the context of a timer -- not
a Response of any type.

It specifically does not say that reception of an unexpected Response
should trigger any action.  Going with the spirit of the protocol, it
should be dropped.

As an implementor, I would log the first unexpected Response but allow
the timer to run.  On a second unexpected Response, I would just send
Failure and be done with it.

> Also, RFC 2284, section 2.2.1 states:
[...]
> rather than indicating errors of other types. 

I added that hash type thing at the request of one of the reviewers of
-00.  On further thought, it's a bad thing.  If someone really needs a
different hash type, then that should just be defined as a new EAP
Request Type, and reuse the basic framework in this draft.

EAP doesn't support negotiation within the individual message Type,
and I don't think I should teach it to do so.  It'll just get too
messy.

> This seems to conflicts with RFC 2284, section 2.2.1 which states: 

Right; my error.  I'll fix that.

> Section 2.2, page 5: 
[...]
> indication.

I'll withdraw that.  It's a mistake.

> Section 2.5, page 9:
[...]
> advertised by the authenticator, with one chosen by the client in the Client 

If the two are not in agreement on the type of hash to be used, then
there's no hope of authenticating through this mechanism.
Authentication is a mutual thing -- you need to be pre-configured to
accept some particular credentials, and this arrangement is outside of
the domain of the protocol.

I don't agree that negotiation is warranted here.

> final hash so as to protect against modification by man in the middle.  

Yes, if it were negotiated, I'd agree that it needs to be in the final
hash.

This very likely means that the ID and Type numbers should also be in
the hash.  I'll fix that.

> examples that might be worth including:
[...]

I agree; I'll add those.  Thanks!

> conversation will appear as follows:
[...]
>                         <- EAP-Failure

Actually, an implementation *could* continue with a fake Request
Subtype 3 in order to avoid giving the peer too much information.
(I'm not paranoid about this, but some implementors might be.)

[...]
> when EAP runs over IEEE 802 media?]

The PCMCIA card is ejected from the system and falls on the floor, I'd
guess.  ;-}

The EAP document says that you should accept LCP Terminate-Request as
equivalent to authentication failure.  Frankly, I neither know nor
care much what the IEEE is doing with EAP.  If they don't have the
necessary supporting semantics to use the protocol as written, then
they're likely to run into all sorts of problems.  It'd probably be
good if they ran these things by the working group ...

-- 
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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Jun 2001 22:08:59 -0700 (PDT)

I had one other comment that I left off the original message. That is
that I think that the prime modulus/generator groups should be expressed
in terms of a "group number" rather than sending the actual values. For
example, it would be possible to assign group numbers to the prime
modulus/generator groups included in the SRP source code or the Appendix
of the SASL-SRP draft. Even though prime moduli > 512 bits (or even 
1024 bits) is recommended, I'd probably leave them all in. Sending
a group number instead of the actual values makes it easier for the client
to determine that the group is valid. This could be a fairly complex task
if you allow arbitrary prime modulus/generator values to be sent. 

> Request Type, and reuse the basic framework in this draft.

I think that makes sense. Either you go with a fixed hash type, or you
need to enable negotiation. Not clear that negotiation is worth it for
this particular function (hash to be used in EAP SRP). 

> This very likely means that the ID and Type numbers should also be in

That would have the nice feature of protecting the EAP conversation. I 
think that is a good thing. 

> (I'm not paranoid about this, but some implementors might be.)

OK. Would be good to give that as an example, to guide implementors. 

> equivalent to authentication failure.  

Actually, it says that implementations need to be prepared to handle loss
of a Success or Failure message, since these messages aren't
ACK'd. Accepting LCP Terminate-Request as an alternative indication of
Failure or a Network Protocol packet as an alternative indication of
Success is PPP's way of fulfilling that requirement.