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.