Re: [Emu] Tunnel method requirements: Mandatory attributes
Joseph Salowey (jsalowey) wrote: We had some discussion of the mandatory attributes section in Anaheim. There was disagreement on the exact behavior of mandatory attributes. Instead of describing a specific behavior in the requirements document I think it would be better to include the requirement instead. Proposed modification: Replace section 4.3.3. Mandatory and Optional Attributes with 4.3.3 Indicating criticality of Attributes It is expected that new attributes will be defined to be carried within the tunnel method. In some cases it is necessary for the sender to know if the receiver did not understand the attribute. To support this, there MUST be a way for the sender to mark attributes such that the receiver will indicate if an attribute is not understood. Just to be clear, you're suggesting that this one paragraph replace all of the paragraphs in 4.3.3? spt ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Tunnel method requirements: Mandatory attributes
yes -Original Message- From: Sean Turner [mailto:turn...@ieca.com] Sent: Thursday, May 06, 2010 7:13 PM To: Joseph Salowey (jsalowey) Cc: emu@ietf.org Subject: Re: [Emu] Tunnel method requirements: Mandatory attributes Joseph Salowey (jsalowey) wrote: We had some discussion of the mandatory attributes section in Anaheim. There was disagreement on the exact behavior of mandatory attributes. Instead of describing a specific behavior in the requirements document I think it would be better to include the requirement instead. Proposed modification: Replace section 4.3.3. Mandatory and Optional Attributes with 4.3.3 Indicating criticality of Attributes It is expected that new attributes will be defined to be carried within the tunnel method. In some cases it is necessary for the sender to know if the receiver did not understand the attribute. To support this, there MUST be a way for the sender to mark attributes such that the receiver will indicate if an attribute is not understood. Just to be clear, you're suggesting that this one paragraph replace all of the paragraphs in 4.3.3? spt ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Tunnel method requirements: Mandatory attributes
We had some discussion of the mandatory attributes section in Anaheim. There was disagreement on the exact behavior of mandatory attributes. Instead of describing a specific behavior in the requirements document I think it would be better to include the requirement instead. Proposed modification: Replace section 4.3.3. Mandatory and Optional Attributes with 4.3.3 Indicating criticality of Attributes It is expected that new attributes will be defined to be carried within the tunnel method. In some cases it is necessary for the sender to know if the receiver did not understand the attribute. To support this, there MUST be a way for the sender to mark attributes such that the receiver will indicate if an attribute is not understood. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Tunnel Method Requirements - mandatory attributes
I am happy with Alan's proposed text except for the paragraph: A peer that either sends or receives a NAK attribute MUST treat the session as failing authentication. I suggest deleting this sentence and adopt the rest of the text. Best regards, Katrin -Original Message- From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Joseph Salowey (jsalowey) Sent: Monday, March 01, 2010 11:53 PM To: emu@ietf.org Subject: [Emu] Tunnel Method Requirements - mandatory attributes Alan commented that section 4.3.3 dealing with mandatory attributes should better define what is meant by mandatory attributes. I agree with this. Alan provided some text which describes behavior that may be too specific for a requirements document. For example, I'm not sure it is appropriate for a NAK to result in a failed authentication in all cases. Alan's text is copied below. Are folks happy with this text or is there other specific text that should go in this document. 4.3.3. Mandatory and Optional Attributes The payload MUST support marking of mandatory and optional attributes, as well as a NAK attribute used to communicate disagreements about received attributes. Mandatory attributes are attributes that a receiver MUST process as per the specification. Optional attributes are attributes that a receiver MAY ignore. A receiver MUST process mandatory attributes before optional ones. After an attribute has been processed, it SHOULD be marked as no longer being mandatory. If a receiver does not process a mandatory attribute, it MUST ignore everything else in a request, and it MUST send a NAK attribute in response. Similarly, if a receiver expects a mandatory attribute and does not receive one in a request, it MUST send a NAK attribute in the response that contains the set of attributes it expected to receive. A peer that either sends or receives a NAK attribute MUST treat the session as failing authentication. The NAK attribute MUST support a description of which mandatory attribute is either required, or is not supported. The NAK attribute MUST be otherwise treated as an optional attribute, and it MUST NOT contain a NAK of the NAK attribute, in order to prevent infinite recursion. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Tunnel Method Requirements - mandatory attributes
I agree with deleting this sentence, as in some case, sending a NAK does not necessary mean the authentication is failing. I also recommend to remove paragraph 3, A receiver MUST process mandatory attributes. It seems to be describing the protocol behavior, not a requirement. On 3/2/10 9:38 AM, Hoeper Katrin-QWKN37 khoe...@motorola.com wrote: I am happy with Alan's proposed text except for the paragraph: A peer that either sends or receives a NAK attribute MUST treat the session as failing authentication. I suggest deleting this sentence and adopt the rest of the text. Best regards, Katrin -Original Message- From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Joseph Salowey (jsalowey) Sent: Monday, March 01, 2010 11:53 PM To: emu@ietf.org Subject: [Emu] Tunnel Method Requirements - mandatory attributes Alan commented that section 4.3.3 dealing with mandatory attributes should better define what is meant by mandatory attributes. I agree with this. Alan provided some text which describes behavior that may be too specific for a requirements document. For example, I'm not sure it is appropriate for a NAK to result in a failed authentication in all cases. Alan's text is copied below. Are folks happy with this text or is there other specific text that should go in this document. 4.3.3. Mandatory and Optional Attributes The payload MUST support marking of mandatory and optional attributes, as well as a NAK attribute used to communicate disagreements about received attributes. Mandatory attributes are attributes that a receiver MUST process as per the specification. Optional attributes are attributes that a receiver MAY ignore. A receiver MUST process mandatory attributes before optional ones. After an attribute has been processed, it SHOULD be marked as no longer being mandatory. If a receiver does not process a mandatory attribute, it MUST ignore everything else in a request, and it MUST send a NAK attribute in response. Similarly, if a receiver expects a mandatory attribute and does not receive one in a request, it MUST send a NAK attribute in the response that contains the set of attributes it expected to receive. A peer that either sends or receives a NAK attribute MUST treat the session as failing authentication. The NAK attribute MUST support a description of which mandatory attribute is either required, or is not supported. The NAK attribute MUST be otherwise treated as an optional attribute, and it MUST NOT contain a NAK of the NAK attribute, in order to prevent infinite recursion. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu Hao Zhou Technical Leader Security Technology Business Unit hz...@cisco.com Phone: +1 330 523 2132 Cisco Systems, Inc. United States Cisco.com - http://www.cisco.com This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Tunnel Method Requirements - mandatory attributes
Hoeper Katrin-QWKN37 wrote: I am happy with Alan's proposed text except for the paragraph: A peer that either sends or receives a NAK attribute MUST treat the session as failing authentication. I suggest deleting this sentence and adopt the rest of the text. What are the situations where authentication can continue after a NAK? A NAK of a mandatory attribute should be treated as a failure. Otherwise, what does mandatory mean, if it can be ignored? Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Tunnel Method Requirements - mandatory attributes
A NAK for a mandatory attribute does not necessarily mean a whole session fails. For example, if you have a sequence of inner authentications, then even though some of them fail, the (overall) authentication may still be considered successful. (At least according to the current draft). Katrin -Original Message- From: Alan DeKok [mailto:al...@deployingradius.com] Sent: Tuesday, March 02, 2010 9:23 AM To: Hoeper Katrin-QWKN37 Cc: Joseph Salowey (jsalowey); emu@ietf.org Subject: Re: [Emu] Tunnel Method Requirements - mandatory attributes Hoeper Katrin-QWKN37 wrote: I am happy with Alan's proposed text except for the paragraph: A peer that either sends or receives a NAK attribute MUST treat the session as failing authentication. I suggest deleting this sentence and adopt the rest of the text. What are the situations where authentication can continue after a NAK? A NAK of a mandatory attribute should be treated as a failure. Otherwise, what does mandatory mean, if it can be ignored? Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Tunnel Method Requirements - mandatory attributes
Hoeper Katrin-QWKN37 wrote: A NAK for a mandatory attribute does not necessarily mean a whole session fails. For example, if you have a sequence of inner authentications, then even though some of them fail, the (overall) authentication may still be considered successful. (At least according to the current draft). Hmm... I'd like to understand exactly what a NAK means, then. The use-cases and failure scenarios aren't clear to me. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Tunnel Method Requirements - mandatory attributes
Mandatory per definition is mandatory to process and cannot be ignored. Sending a NAK is one kind of processing by telling the sender that the receiver doesn't know how to process. It just cannot ignore the attribute, like an optional attribute. It is up to authentication server's policy. It may allow the EAP authentication to finish successfully but only allow limited access. On 3/2/10 10:23 AM, Alan DeKok al...@deployingradius.com wrote: Hoeper Katrin-QWKN37 wrote: I am happy with Alan's proposed text except for the paragraph: A peer that either sends or receives a NAK attribute MUST treat the session as failing authentication. I suggest deleting this sentence and adopt the rest of the text. What are the situations where authentication can continue after a NAK? A NAK of a mandatory attribute should be treated as a failure. Otherwise, what does mandatory mean, if it can be ignored? Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu Hao Zhou Technical Leader Security Technology Business Unit hz...@cisco.com Phone: +1 330 523 2132 Cisco Systems, Inc. United States Cisco.com - http://www.cisco.com This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Tunnel Method Requirements - mandatory attributes
Alan commented that section 4.3.3 dealing with mandatory attributes should better define what is meant by mandatory attributes. I agree with this. Alan provided some text which describes behavior that may be too specific for a requirements document. For example, I'm not sure it is appropriate for a NAK to result in a failed authentication in all cases. Alan's text is copied below. Are folks happy with this text or is there other specific text that should go in this document. 4.3.3. Mandatory and Optional Attributes The payload MUST support marking of mandatory and optional attributes, as well as a NAK attribute used to communicate disagreements about received attributes. Mandatory attributes are attributes that a receiver MUST process as per the specification. Optional attributes are attributes that a receiver MAY ignore. A receiver MUST process mandatory attributes before optional ones. After an attribute has been processed, it SHOULD be marked as no longer being mandatory. If a receiver does not process a mandatory attribute, it MUST ignore everything else in a request, and it MUST send a NAK attribute in response. Similarly, if a receiver expects a mandatory attribute and does not receive one in a request, it MUST send a NAK attribute in the response that contains the set of attributes it expected to receive. A peer that either sends or receives a NAK attribute MUST treat the session as failing authentication. The NAK attribute MUST support a description of which mandatory attribute is either required, or is not supported. The NAK attribute MUST be otherwise treated as an optional attribute, and it MUST NOT contain a NAK of the NAK attribute, in order to prevent infinite recursion. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
