Subject: Re: [Emu] Multiple Request Action Items

From: Hao Zhou <[email-masked]>
Date: Sun, 01 Apr 2012 22:28:59 -0400

Jim:

Good question. The current draft allows for multiple request TLV items, but
only says a single Result TLV, indicating the what EAP Success/Failure
result the peer would expect if the requested action is not granted.

I can definitely see the need for the case you cited. If we want to extend
existing design to include individual Result TLVs for the individual request
items, we can do that. But I think this might be more complicated and
unnecessary.  Maybe we can use the mandatory bit in the requested TLVs to
indicate whether ignoring it would cause the failure in the result TLV.

Thoughts?

On 3/30/12 3:34 AM, "Jim Schaad" <[email-masked]> wrote:

> In the presentation you stated that the plan was to make the TLVs that are
> requested become a sub TLV of the request TLV items.  If that is true, then
> should it be possible to allow for multiple request TLVs to be present in a
> message.  Thus one could say:
>   Please do A - and if not then fail authentication
>   Please do B - and if not then succeed authentication
> 
> Jim
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 2 Apr 2012 08:07:51 +0200

Hao,

The idea that I thought you had presented would not make it a very
complicated item.

1.  Change the specification so that multiple Request TLVs are permitted to
occur in the TLV sequence.
2.  Change to specification so that the Request TLV item now looks like
    M|R|TLV Type | Length |
    Status | TLV sequence

The TLV Sequence is the set of TLV items to be processed for that sequence
code.

Then need some oddball text to the effect that:

Two Request TLVs MUST NOT occur in the message if they have the same Status
value.
The order of processing multiple Request TLVs is implementation dependent.
If the server process the optional (non-fatal) items first, it is possible
that the fatal items will disappear at a later time.  If the server process
the fatal items first, the communication time will be shorter.

The client MAY return a new set of Request TLV items after one or more of
the requested items has been processed and the server has signaled it wants
to end the EAP conversation.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hao Zhou
> Sent: Monday, April 02, 2012 4:29 AM
> To: Jim Schaad; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Emu] Multiple Request Action Items
> 
> Jim:
> 
result
> the peer would expect if the requested action is not granted.
> 
> > In the presentation you stated that the plan was to make the TLVs that
> > are requested become a sub TLV of the request TLV items.  If that is
> > true, then should it be possible to allow for multiple request TLVs to
> > be present in a message.  Thus one could say:

---

From: Hao Zhou <[email-masked]>
Date: Wed, 11 Apr 2012 13:15:49 -0400

Yes. That would work. If no objections, I can add to the draft.

---

From: [email-masked]
Date: Tue, 17 Apr 2012 17:51:54 +0800

In Section 2 draft-hartman-emu-mutual-crypto-bind-00，
"The print server offers a tunnel method towards the peer. The print
   server extracts the inner method from the tunnel and sends it on
   towards the AAA server.  Channel binding happens at the tunnel method
   though.  So, the print server is happy to confirm that it is the
   financial application.  After the inner method completes, the EAP
   server sends the MSK to the print server over the AAA protocol.  If
   only the MSK is needed for cryptographic binding then the print
   server can successfully perform cryptographic binding and may be able
   to impersonate the financial application to the peer."

The print server offers a tunnel method towards the peer, and channel 
binding is adopted. 

According to section 4.2 in draft-ietf-emu-chbind-14,
"The channel bindings MUST be transported with integrity protection  based 
on a key known only to the peer and EAP server."
section 6 in draft-ietf-emu-chbind-14：
"The channel binding protocol defined in this document must be transported 
after keying material has been derived between the EAP
peer and server, and before the peer would suffer adverse affects from 
joining an adversarial network."

To my understanding, right prior to finishing tunnel establishement, EAP 
peer and EAP Server(print server in the server insertion attack case) 
should have
exchanged channel binding with integrity protection by key only known to 
EAP peer and EAP server (MSK in this case),
but print server does not know MSK yet, so channel binding could not pass 
verification by EAP peer, then 
peer should not continue with the inner method, and print server chould 
not use non-tunneled innder method without cooperation of peer,
and print server chould not get MSK from EAP Server, and server insertion 
attack fails even though peer does not check print server or EAP server's 
cert.

Have I missed something? 

Regards~~~

-Sujing Zhou