Subject: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00

From: "Jim Schaad" <[email-masked]>
Date: Fri, 28 Sep 2012 18:18:14 -0700

1.  In section 3.2.3, it says that a new PAC can be requested after a full
TLS handshake.  Can one be requested following an abbreviated handshake?  Or
do you just re-use the existing PAC?

2.  Section 3.3 s/descried/described/

3.  Section 3.4 - Is it possible to have multiple server ids after the
authentication - one from the tunnel and others from the inner EAP methods.
I realize that most EAP methods don't send a sender id, but some (IBAKE for
example) currently do.  Also, the client might have an idea of what the
sender id is from configuration.  If so, do these all need to get exported
as server-id values?

4. In section 3.6.1 - It is not clear that an EAP-Failure packet is sent
when 1) the server sends a fatal alert to the peer, 2) the peer requests a
restart via a ClientHello and 3) the peer declines to permit the restart to
occur.

5.  In section 3.6.1 - Is the restart only an issue for fatal alerts, or is
it a problem for all alerts?

6.  In section 3.6.2 - Why SHOULD not MUST send clear text EAP-Failure?

7.  In section 3.6 - do we need to discuss the question of errors in the
outer EAP layer that is carrying the TLVs which contain the TLS content?
This is a distinct location from the current list of where to handle errors.
There is going to be a distinction (possibly) between errors that occur
during phase 1 and errors during phase 2.  Should the error return reflect
if the error occurred inside or outside of the TLS tunnel?

8.  In section 3.8 - I have the following questions
a) In the text "The request MAY be issued", I don't understand the MAY at
this point.  Is it supposed to say that the request can be issued either
before or after the authentication has finished, or is it saying that the
peer has the option of issuing or not issuing the request, but must wait
until the authentication level has been reached?
b) If a peer issues a PAC request, but the server has not yet satisfied it's
policy, does the server remember the PAC request and send back the response
after the internal policy has been satisfied or should it send back an error
saying that policy has not yet been satisfied along with additional TLVs to
attempt and satisfy that policy?
c) What should a peer do if it receives a PAC TLV with an unknown attribute?

9.  In section 3.9 - there is leaking on the POP, but not on identity at
this point.  I believe that there needs to be a requirement that an EAP
method needs to be run which will provide an identity proof on the client
prior to a certificate being issued.  You may or may not then want to add
text that says that the subject name(s) in the certificate request need to
be checked against the set of authenticated identities prior to the
certificate being issued.

10. In section 3.10 - It is unclear to me if the Server Unauthenticated mode
is because the server or the peer is unauthenticated at this point in time.
The cipher suite would indicate that the server is not authenticated,
however what about the case of the server providing an authenticated id to
the peer, but the peer is unable to validate the identity of the server for
some reason.  This is also a Server Unauthenticated mode.

11.  In section 4.1 - I would like to see a discussion that says that the
following situation can never occur.  The initial EAP message from the peer
to the server (or the response) plus the Outer TLV data plus the EAP message
headers exceeds the underlying packet size of the transport.  In the event
that it does, I am not sure how one finds the Outer TLV data start and where
the fragmentation would occur to get the Outer TLV data between the peer and
the server.

12.  Section 4.2 - I understand what is happening with an EMPTY TEAP message
being sent in response to a list of TLVs that are marked optional, however I
question if the statement that is MUST be sent is correct.  There are two
reasons for the question:  

a.  A server could send a RESULT TLV in response to a message from the
client that contains no TLVs that are either mandatory or recognized.
b.  I am (very slightly) worried about the fact that the response is not
authenticated by the tunnel in many manner.  I would think that a NAK to any
of the TLVs would be a better response if no other TLV messages are to be
sent.  The entity sending the TLV should know if it marked it as mandatory
or not.  The NAK is not the same as an Error TLV.

13.  Section 4.2.2 - Should "Type" in the outdented list be "TLV Type"? 
 s/filed/field/

14.  Section 4.2.2 - Can multiple Authority-ID TLVs be transmitted to a
peer?

15.  Section 4.2.3 - I assume that there should only be one Identity-Type
TLV in a TEAP packet.  Should a request for authentication be present in the
packet as well?  If multiple are allowed then information about how to treat
this should be included.  What should the peer respond with if it does have
an identity of the type?  This is not explicitly stated.

16.  Section 4.2.4 - I don't understand the default in the event that an
unknown value is sent in the status field.  If there is an ERROR TLV in the
message, should I not use that error code rather than change it?

17. Section 4.2.6 - Do we need a discussion about how to produce/deal with
vender specific errors?  Do you expect that vender specific TLVs will have
an error mechanism built into them to return an error code?

18. Section 4.2.8 - Do we need to talk about the question of having some
Vender TLVs be marked as mandatory and others not.  Are we using the same
TLV structure with the same rules for mandatoriness.  If the mandatory bit
is set, does that mean that I need to recognize the vendor-id or all
combinations of vender-id/Vender-TLV type?

19.  Section 4.2.9 - After reading this, sketching out some scenarios and so
forth, I find that I do not like the text and result being pushed here at
all.  My problems start, in some respects, with the name of the TLV as it
does not map to how I would like to see this TLV treated.  I would propose
the following set of changes:
a) The name of the TLV be changed from Request-Action TLV to
Provisional-Result TLV
b) It needs to be made clear that the TLV can be sent from either the server
to the peer or the peer to the server.  It is my belief that presently it is
only sent from the peer to the client and only in response to a successful
Result TLV.
c)  The receiving entity MUST process the TLV.
d)  The processing for the TLV is as follows:
   i) The entity MAY choose to process (or start?) any of the TLVs that are
included in the message.
  ii) If the entity chooses NOT to process any TLV in the list, the
Provisional-Result TLV is treated as a Result TLV with the code "status"
  iii) If multiple Provisional-Result TLVs are in the body, the session can
continue if ANY of TLV in any Provisional-Result TLV is processed.
  iv) If multiple Provisional-Result TLVs are in the body and no sub-TLV is
processed, then the most fatal status should be used.  If a status is found
which is not understood by the entity, then it should be treated as a fatal
TLV.

The current text allows for the following:
The server sends a Success to the peer
The peer says please do this or go to fatal
The server sends a clear success outside of the tunnel.

I wonder if the capability needs to be added to say, please start this TLV.
So that a server can say, If you don't start a Channel binding TLV, I will
make this a failure return code, if you want to start the channel binding
TLV then I am open to giving you a success return code. 
>> OK - so this is kind of there, but only one value can be placed there.
One cannot say do either an EAP negotiation or process this TLV.

20. Section 4.2.12.4 - What does it mean to have an I-ID validation
enforcement for PAC session renewal?  Does it mean that the final message is
not sent unless an appropriate ID is presented?  Does it have to be an EAP
authentication or is password based authentication sufficient?  Should a PAC
be invalidated on the server side (oops how do you do that) if it a PAC is
presented and then the appropriate ID is not given?

21.  In section 4.2.12.6 - Is this supposed to be at the top level or
embedded in the PAC-TLV?

22.  In section 4.2.16 - PKCS#7 has been superseded by CMS - the references
should be to CMS and not to PCKS#7

23.  In IANA - Need to add the Request-Action TLV to the list of status
codes

24.  In IANA - Should the Vender ID of the Vender-Specific TLV be kept in a
registry?

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alan DeKok
> Sent: Tuesday, September 25, 2012 8:04 AM
> To: [email-masked]
> Subject: [Emu] Looking for reviewers
> 
>   We'd like to get the final two documents into last call before the next
> meeting.  Therefore, we're looking for reviewers:
> 
> https://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/
> 
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/
> 
>   Please post reviews to the list.  If all goes well, we can get updated
> documents issued before the next meeting.
> 
>   Thanks to everyone for their help.
> 
>   Alan DeKok.
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu