Subject: [Emu] Comments on emu-eap-tunnel-method-02

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Mar 2012 03:15:19 -0700

1.  After the first exchange of messages, if the version does not match the
agreed on version - what happens?

2.  Section 3.2 says that one should be able to do a renegotiate for getting
the peers identity certificate.  Do the following points need to be made?
a) If you are doing a re-negotiation - then you SHOULD not be using an
anonymous cipher suite
b) Once you have started phase 2, re-negotiation MUST NOT be done.

3. in section 3.3.1 - did you miss changing and EAP-TLS to a TEAP? "For
example, EAP-TLS..."  If not, then I would suggest changing to a std track
protocol.

4.  In section 3.4 - I want to make sure that what I read is what you
intend.
 == If I do multiple (one or more) inner EAP methods, the authenticated peer
identity is the set of all of these identities.
 == If I do zero inner EAP methods and I do a client auth TLS, the
authenticated peer identity comes from the certificate.
 == If I do zero inner EAP methods and do not do a client auth TLS, then I
have no authenticated peer identity.

 -- specifically - should the client auth TLS identity be excluded if I run
an inner EAP method
 -- Specifically - should the all non EAP methods be excluded -- include the
TEAP defined user name/password
 -- Specifically - should any EAP server name established in an EAP method
be excluded from its name set?

5.  In section 3.8 - potentially ambiguous statement:  "The request MAY be
issued after the peer has determined..."  Is the request the MAY or the
timing of the request the MAY?
 
6.  In section 4.2.3 - What is the registration policy for the Identity-Type
field of the Identity-Type TLV?  Do there need to be reserved ranges for use
by specific Servers - i.e. local use? Or is that insane?

7. In section 4.2.4 - What do I do for an defined value.  Do these values
only match those of the available through the base document or are other 

8.  In section 4.2.9 - Are the TLVs to be processed and the EAP to negotiate
to be included in the peer response?

9.  Does the order of items in the TLV list matter?  Or are specific TLVs
expected to be processed first.  For example what would be the expected
order on the  Identity-Type TLV and the EAP-Payload TLV?

10.  Section 4.2.12.2 says the key is of a specific length, yet there is
length field.  Why is a specific length mentioned esp as the length was just
changed in the last version.  I assume this key length is dependent on the
PAC type and should not be fixed.

11. Section 4.2.15 - If we change the "standard" way of doing name
preparation, should we be creating a new item, or should we have a byte
field that specifies the username/password processing function.

12. Section 5.2 - Does the truncation and expansion to 32-bytes still hold
true if the TLS-PRF were to use a new cypher suite that used P_SHA512?

Jim

---

From: Hao Zhou <[email-masked]>
Date: Wed, 21 Mar 2012 14:26:26 -0400

Jim:

Thanks for the detailed review. My comments are below inline:

> agreed on version - what happens?
[HZ] Good catch. Both sides should stick with the version negotiated. I
guess we will add some language to describe the behavior handling
exceptions. My initial thoughts are both sides should treat it as fatal
error and proceed with fatal error processing, e.g., server should just send
back EAP-Failure and peer sends back EAP-Nak.

> b) Once you have started phase 2, re-negotiation MUST NOT be done.
[HZ] Good points. I will add them.

> example, EAP-TLS..."  If not, then I would suggest changing to a std track
[HZ] No. It is meant to say EAP-TLS. I thought EAP-TLS RFC5216 is a std
track RFC.

> have no authenticated peer identity.
[HZ] Correct except last one. I would say the authenticated peer identity
comes from any inner method, not necessary EAP method. So if a password TLV
exchange happened, then the authenticated peer identity is coming from that
password authentication TLV exchange. I think we will change the word "inner
EAP method" to "inner authentication method".

>  -- specifically - should the client auth TLS identity be excluded if I run
[HZ] No. 
> TEAP defined user name/password
[HZ] No.
> be excluded from its name set?
[HZ] It could be included as part of the Server-ID if the server is not
authenticated as part of the tunnel establishment. I will add some text to
address this.
> timing of the request the MAY?
[HZ] Good catch. It is "the request MAY". Timing is should be after
validating the crypto-binding TLV. I will address that.
> by specific Servers - i.e. local use? Or is that insane?
[HZ] I missed that in IANA section. It should be Spec Required as others. I
don't see need for local use types.

> only match those of the available through the base document or are other
[HZ} I am confused. Are you talking about Section 4.2.4 Result TLV or
others?

> to be included in the peer response?
[HZ] Yes. I will add a sentence or two describe this.

> order on the  Identity-Type TLV and the EAP-Payload TLV?
[HZ] It shouldn't matter. But I would think Identity-Type TLV should precede
EAP-Payload TLV. Let me think about maybe some other cases order is
important and document that.
 
> PAC type and should not be fixed.
[HZ] You are correct. It shouldn't be fixed, to be crypto-agile. Will fix
that. 48 octets are just an example, maybe minimum length.
> field that specifies the username/password processing function.
[HZ] Can you provide an example why UTF-8 is not sufficient? Are you
proposing adding a namespace or type for the name preparation, as opposed to
standard UTF-8? 
> true if the TLS-PRF were to use a new cypher suite that used P_SHA512?
[HZ] Good question. In current draft, the key length of the keying materials
to be mixed are somewhat fixed. I didn't see the need to extend it yet.
 
> Jim
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Mar 2012 13:56:12 -0700

> -----Original Message-----
> From: Hao Zhou [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2012 11:26 AM
> To: Jim Schaad; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Emu] Comments on emu-eap-tunnel-method-02
> 
> Jim:
> 
> > 7. In section 4.2.4 - What do I do for an defined value.  Do these
> > values only match those of the available through the base document or
> > are other
> >
others?

I was looking at the result TLV, I was thinking in terms of a Not Available
at this time - but that should probably be in the NAK not in the Result.  As
there are only two possible results to be returned at the top level EAP -
this is probably an extraneous comment.

> > preparation, should we be creating a new item, or should we have a
> > byte field that specifies the username/password processing function.
> >
> proposing adding a namespace or type for the name preparation, as opposed
> to standard UTF-8?

No the thing that will change is SASLPrep.  We will want to be able to move
to a string mangling function that matches the current Unicode standard and
use the (or one of the) result(s) of the precs working group.

> > 12. Section 5.2 - Does the truncation and expansion to 32-bytes still
> > hold true if the TLS-PRF were to use a new cypher suite that used
> P_SHA512?
> >

As long as the PRF is based on HMAC there is no problem with having a
"short" key.

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Mar 2012 17:52:58 -0700

You might also need to put in an IANA consideration for the use of the TLS
Exporter
(http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#exporter-
labels)

Jim

> > 1.  After the first exchange of messages, if the version does not
> > match the agreed on version - what happens?
> >
guess
> we will add some language to describe the behavior handling exceptions. My
> initial thoughts are both sides should treat it as fatal error and proceed
with
> fatal error processing, e.g., server should just send back EAP-Failure and
peer
> sends back EAP-Nak.
> 
> > 2.  Section 3.2 says that one should be able to do a renegotiate for
> > getting the peers identity certificate.  Do the following points need to
be
> made?
> > 3. in section 3.3.1 - did you miss changing and EAP-TLS to a TEAP?
> > "For example, EAP-TLS..."  If not, then I would suggest changing to a
> > std track protocol.
> >
track
> RFC.
> >  == If I do multiple (one or more) inner EAP methods, the
> > authenticated peer identity is the set of all of these identities.
> >  == If I do zero inner EAP methods and do not do a client auth TLS,
> > then I have no authenticated peer identity.
> >
> comes from any inner method, not necessary EAP method. So if a password
> TLV exchange happened, then the authenticated peer identity is coming
> from that password authentication TLV exchange. I think we will change the
> word "inner EAP method" to "inner authentication method".
> 
> >  -- specifically - should the client auth TLS identity be excluded if
> > I run an inner EAP method
> [HZ] No.
> >  -- Specifically - should the all non EAP methods be excluded --
> > include the TEAP defined user name/password
> [HZ] No.
> >  -- Specifically - should any EAP server name established in an EAP
> > method be excluded from its name set?
> >
> > 5.  In section 3.8 - potentially ambiguous statement:  "The request
> > MAY be issued after the peer has determined..."  Is the request the
> > MAY or the timing of the request the MAY?
> >
validating
> the crypto-binding TLV. I will address that.
> > 6.  In section 4.2.3 - What is the registration policy for the
> > Identity-Type field of the Identity-Type TLV?  Do there need to be
> > reserved ranges for use by specific Servers - i.e. local use? Or is that
> insane?
> >
others?
> 
> > 8.  In section 4.2.9 - Are the TLVs to be processed and the EAP to
> > negotiate to be included in the peer response?
> >
> > 9.  Does the order of items in the TLV list matter?  Or are specific
> > TLVs expected to be processed first.  For example what would be the
> > expected order on the  Identity-Type TLV and the EAP-Payload TLV?
> >
> > 10.  Section 4.2.12.2 says the key is of a specific length, yet there
> > is length field.  Why is a specific length mentioned esp as the length
> > was just changed in the last version.  I assume this key length is
> > dependent on the PAC type and should not be fixed.
that. 48
> octets are just an example, maybe minimum length.
> >