Re: [Emu] Issue #19: Method Chaining
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emu] Issue #19: Method Chaining



Any objection to changing MUST to SHOULD for method chaining?

Thanks,

Joe 

> -----Original Message-----
> From: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org] On 
> Behalf Of Joseph Salowey (jsalowey)
> Sent: Thursday, August 06, 2009 12:44 PM
> To: emu at ietf.org
> Subject: [Emu] Issue #19: Method Chaining
> 
> #19: Method Chaining
> 
>  > Section 3.3
>  >
>  > "  Several circumstances are best addressed by using chained EAP
>  >    methods.  For example, it may be desirable to authenticate the
> user
>  >    and also authenticate the device that he or she is using."
>  > This requirement can be met by support for cryptographic  
> > binding, without chaining of EAP methods.  For example, the 
>  > combination of TLS and an inner method can support  > 
> user/device auth.  Given that, why is support for chained  > 
> methods a must, and not device/user auth support?
>  >
>  and
>  > Section 4.6.2
>  >
>  > "   The tunnel method MUST support the chaining of multiple
>  > EAP methods.
>  >    The tunnel method MUST allow for the communication of 
> intermediate
>  >    result and verification of compound binding between 
> executed inner
>  >    methods when chained methods are employed.
>  > "
>  >
>  > Given that the basic use case (machine + user auth) 
> doesn't  > require chaining of EAP methods, why is this a MUST?
>  >
> 
> --
> 
> Comment(by jsalowey at cisco.com):
> 
>  In the Stockholm meeting there was indication that there 
> were other  mechanisms that could require chaining, such as 
> posture checking.
> People
>  seemed to favor changing from MUST to SHOULD.
> 
> --
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/emu/trac/ticket/19#comment:1>
> emu <http://tools.ietf.org/wg/emu/>
> 
> _______________________________________________
> Emu mailing list
> Emu at ietf.org
> https://www.ietf.org/mailman/listinfo/emu
> 

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.