RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
I think this is ok, but my email client isn't distinguishing the new vs. old text. If it's just changes to produce this new bullet, I have a small edit: o Channel binding MUST be used for all application authentication. The EAP server MUST either require that the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data for application authentication. "MUST either require that" --> "MUST require that either" Thanks, --David From: Joseph Salowey (jsalowey) [mailto:[email protected]] Sent: Wednesday, June 19, 2013 7:23 PM To: Black, David Cc: [email protected]; General Area Review Team; [email protected]; [email protected] Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thanks for the text, some revision to address On Jun 18, 2013, at 12:34 PM, "Black, David" mailto:[email protected]>> wrote: [Joe] Good points, the text can be more specific: "In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For application authentication, the EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All network access EAP peer implementations SHOULD use channel bindings including the EAP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. " This is looking good, modulo Sam's comment on EAP lower-layer vs. something else that I'll leave to you and he to sort out. I have a suggested rewrite, mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and to reformat into a structured bullet list of requirements (this is not intended to change any requirements from what you wrote): "In environments where EAP is used for purposes other than network access authentication: o All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings. o Channel binding MUST be used for all application authentication. The EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data for application authentication. o Channel binding MUST be used for all application authentication. The EAP server MUST either require that the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data for application authentication. o Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute to explicitly identify the reason for authentication. o Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. Thanks, --David -Original Message- From: Joseph Salowey (jsalowey) [mailto:[email protected]<http://cisco.com>] Sent: Tuesday, June 18, 2013 1:47 PM To: Black, David Cc: [email protected]<mailto:[email protected]>; General Area Review Team; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 I think we could state this a bit better as something like: "In environments where EAP is used for applications authentication and network access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD support channel binding to explicitly identify the reason for authentication. Any new usage of EAP MUST support channel bindings to prevent confusion with network access usage. " That text is an improvement, and it's headed in the same direction as Sam's comment - "application bindings MUST be present in application authentication" is a "MUST use" requirement, not just a "MUST implement" requirement. OTOH, I'm not clear on what "application bindings" means, as that term's not in the current draft. Specifically, I'm a bit unclear on "application bindings MUST be absent in network authentication" - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an "applicatio
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
I'm fine with this text. Either with eap-lower-layer as a MUST or the more complex version.
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
Thanks for the text, some revision to address On Jun 18, 2013, at 12:34 PM, "Black, David" mailto:[email protected]>> wrote: [Joe] Good points, the text can be more specific: "In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For application authentication, the EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All network access EAP peer implementations SHOULD use channel bindings including the EAP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. " This is looking good, modulo Sam's comment on EAP lower-layer vs. something else that I'll leave to you and he to sort out. I have a suggested rewrite, mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and to reformat into a structured bullet list of requirements (this is not intended to change any requirements from what you wrote): "In environments where EAP is used for purposes other than network access authentication: o All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings. o Channel binding MUST be used for all application authentication. The EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data for application authentication. o Channel binding MUST be used for all application authentication. The EAP server MUST either require that the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data for application authentication. o Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute to explicitly identify the reason for authentication. o Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. Thanks, --David -Original Message- From: Joseph Salowey (jsalowey) [mailto:[email protected]<http://cisco.com>] Sent: Tuesday, June 18, 2013 1:47 PM To: Black, David Cc: [email protected]<mailto:[email protected]>; General Area Review Team; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 I think we could state this a bit better as something like: "In environments where EAP is used for applications authentication and network access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD support channel binding to explicitly identify the reason for authentication. Any new usage of EAP MUST support channel bindings to prevent confusion with network access usage. " That text is an improvement, and it's headed in the same direction as Sam's comment - "application bindings MUST be present in application authentication" is a "MUST use" requirement, not just a "MUST implement" requirement. OTOH, I'm not clear on what "application bindings" means, as that term's not in the current draft. Specifically, I'm a bit unclear on "application bindings MUST be absent in network authentication" - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an "application binding", whatever that is? [Joe] Good points, the text can be more specific: "In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For application authentication, the EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All network access EAP peer implementations SHOULD use channel bindings including the EAP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. " Does this help? Thanks, Joe
RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
> [Joe] Good points, the text can be more specific: > > "In environments where EAP is used for purposes other than network access > authentication all EAP servers MUST enforce channel bindings. For application > authentication, the EAP server MUST require that the correct EAP lower-layer > attribute be present in the channel binding data. For network access > authentication, the EAP server MUST require that if channel bindings are > present they MUST contain the correct EAP lower-layer attribute. All network > access EAP peer implementations SHOULD use channel bindings including the EAP > lower-layer attribute to explicitly identify the reason for authentication. > Any new usage of EAP MUST use channel bindings including the EAP lower-layer > attribute to prevent confusion with network access usage. " This is looking good, modulo Sam's comment on EAP lower-layer vs. something else that I'll leave to you and he to sort out. I have a suggested rewrite, mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and to reformat into a structured bullet list of requirements (this is not intended to change any requirements from what you wrote): "In environments where EAP is used for purposes other than network access authentication: o All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings. o Channel binding MUST be used for all application authentication. The EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data for application authentication. o Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute to explicitly identify the reason for authentication. o Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage." Thanks, --David > -Original Message- > From: Joseph Salowey (jsalowey) [mailto:[email protected]] > Sent: Tuesday, June 18, 2013 1:47 PM > To: Black, David > Cc: [email protected]; General Area Review Team; [email protected]; > [email protected] > Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 > > >> > >> I think we could state this a bit better as something like: > >> > >> "In environments where EAP is used for applications authentication and > >> network > >> access authentication all EAP servers MUST understand channel bindings and > >> require that application bindings MUST be present in application > >> authentication and that application bindings MUST be absent in network > >> authentication. All network access EAP peer implementations SHOULD > >> support > >> channel binding to explicitly identify the reason for authentication. Any > >> new > >> usage of EAP MUST support channel bindings to prevent confusion with > >> network > >> access usage. " > > > > That text is an improvement, and it's headed in the same direction as Sam's > > comment - "application bindings MUST be present in application > > authentication" > > is a "MUST use" requirement, not just a "MUST implement" requirement. > > > > OTOH, I'm not clear on what "application bindings" means, as that term's not > > in the current draft. Specifically, I'm a bit unclear on "application > > bindings > > MUST be absent in network authentication" - does that mean that channel > > binding must be absent, or that channel binding is optional, but if channel > > binding is present, it MUST NOT be an "application binding", whatever that > is? > > > > [Joe] Good points, the text can be more specific: > > "In environments where EAP is used for purposes other than network access > authentication all EAP servers MUST enforce channel bindings. For application > authentication, the EAP server MUST require that the correct EAP lower-layer > attribute be present in the channel binding data. For network access > authentication, the EAP server MUST require that if channel bindings are > present they MUST contain the correct EAP lower-layer attribute. All network > access EAP peer implementations SHOULD use channel bindings including the EAP > lower-layer attribute to explicitly identify the reason for authentication. > Any new usage of EAP MUST use channel bindings including the EAP lower-layer > attribute to prevent confusion with network access usage. " > > Does this help? > > Thanks, > > Joe >
RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
> [Joe] I'm trying to get a handle on the attack mechanism here. In this > attack a valid network service is trying to spoof an application service? > Since it knows the MSK it can do this if the channel-binding of the lower- > layer into the EAP conversation is not enforced. If the AAA server always > enforces channel bindings for applications then it will catch the spoofing > attempt. The reverse case may also be an issue where an application service > is trying to spoof a network service. While both cases appear to be relevant, my concern started from the reverse case - here's the draft's text describing the attack: One potentially serious attack exists when channel binding is not required and EAP authentication is introduced into an existing non- network service. A device can be created that impersonates a Network Access Service to peers, but actually proxies the authentication to the new application service that accepts EAP authentications. This may decrease the security of this service even for users who previously used non-EAP means of authentication to the service. > In this case, if the AAA server > validates that the application channel binding is not present then it can > prevent the spoofing. However the server MUST understand channel bindings > even if the peers do not. I think the document did try to capture this in > the following sentence: > > "If the EAP server is aware that authentication is >for something other than a network service, it too MUST default to >requiring channel binding." > > I think we could state this a bit better as something like: > > "In environments where EAP is used for applications authentication and network > access authentication all EAP servers MUST understand channel bindings and > require that application bindings MUST be present in application > authentication and that application bindings MUST be absent in network > authentication. All network access EAP peer implementations SHOULD support > channel binding to explicitly identify the reason for authentication. Any new > usage of EAP MUST support channel bindings to prevent confusion with network > access usage. " That text is an improvement, and it's headed in the same direction as Sam's comment - "application bindings MUST be present in application authentication" is a "MUST use" requirement, not just a "MUST implement" requirement. OTOH, I'm not clear on what "application bindings" means, as that term's not in the current draft. Specifically, I'm a bit unclear on "application bindings MUST be absent in network authentication" - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an "application binding", whatever that is? Thanks, --David > -Original Message- > From: Joseph Salowey (jsalowey) [mailto:[email protected]] > Sent: Tuesday, June 18, 2013 1:10 PM > To: Sam Hartman > Cc: Black, David; [email protected]; General Area Review Team; > [email protected]; [email protected] > Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 > > > On Jun 18, 2013, at 7:18 AM, Sam Hartman > wrote: > > >>>>>> "Black," == Black, David writes: > > > >Black,> The next to last paragraph on p.3 begins with this sentence: > > > >Black,>For these reasons, channel binding MUST be implemented by > >Black,> peers, EAP servers and AAA servers in environments where EAP > >Black,> authentication is used to access application layer services. > > > >Black,> It appear that this "MUST" requirement applies to all uses > >Black,> of EAP, including network access authentication, not just > >Black,> application layer access authentication. If so, that's not > >Black,> immediately obvious from the text, and an additional > >Black,> sentence should be added to make this clearer. If not, the > >Black,> above sentence needs to exclude network access > >Black,> authentication from that requirement. > > > > > > I know you're correct that AAA servers and EAP servers need to implement > > channel binding for network access in such environments. > > I'm not sure whether peers only doing network access SHOULD implement > > channel binding or MUST implement channel binding. > > > > Practically speaking, it will be a while before peers implement channel > > binding for network access. > > The sorts of attacks that result without channel binding are attacks &
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
On Jun 18, 2013, at 11:39 AM, Sam Hartman wrote: > Joe, eap-lower-layer is not required for application authentication if > there's some other attribute that's specific to the lower layer. For > example Moonshot sends gss-acceptor-service-name but does not currently > send eap-lower-layer, and doing that seems consistent with the > requirements of the channel binding spec. > > Adding a requirement for eap-lower-layer all the time would be new, but > might be reasonable. > [Joe] Ah yes, I remember this. It would be simpler to just use eap lower-layer attribute. I think we could massage the text to say something like "eap lower-layer layer attribute or equivalent attribute indicating the EAP lower layer in use" . Let me see what I can do with the text David provided. > --Sam
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
Joe, eap-lower-layer is not required for application authentication if there's some other attribute that's specific to the lower layer. For example Moonshot sends gss-acceptor-service-name but does not currently send eap-lower-layer, and doing that seems consistent with the requirements of the channel binding spec. Adding a requirement for eap-lower-layer all the time would be new, but might be reasonable. --Sam
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
>> >> I think we could state this a bit better as something like: >> >> "In environments where EAP is used for applications authentication and >> network >> access authentication all EAP servers MUST understand channel bindings and >> require that application bindings MUST be present in application >> authentication and that application bindings MUST be absent in network >> authentication. All network access EAP peer implementations SHOULD support >> channel binding to explicitly identify the reason for authentication. Any >> new >> usage of EAP MUST support channel bindings to prevent confusion with network >> access usage. " > > That text is an improvement, and it's headed in the same direction as Sam's > comment - "application bindings MUST be present in application authentication" > is a "MUST use" requirement, not just a "MUST implement" requirement. > > OTOH, I'm not clear on what "application bindings" means, as that term's not > in the current draft. Specifically, I'm a bit unclear on "application > bindings > MUST be absent in network authentication" - does that mean that channel > binding must be absent, or that channel binding is optional, but if channel > binding is present, it MUST NOT be an "application binding", whatever that is? > [Joe] Good points, the text can be more specific: "In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For application authentication, the EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All network access EAP peer implementations SHOULD use channel bindings including the EAP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. " Does this help? Thanks, Joe
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
On Jun 18, 2013, at 7:18 AM, Sam Hartman wrote: >> "Black," == Black, David writes: > >Black,> The next to last paragraph on p.3 begins with this sentence: > >Black,>For these reasons, channel binding MUST be implemented by >Black,> peers, EAP servers and AAA servers in environments where EAP >Black,> authentication is used to access application layer services. > >Black,> It appear that this "MUST" requirement applies to all uses >Black,> of EAP, including network access authentication, not just >Black,> application layer access authentication. If so, that's not >Black,> immediately obvious from the text, and an additional >Black,> sentence should be added to make this clearer. If not, the >Black,> above sentence needs to exclude network access >Black,> authentication from that requirement. > > > I know you're correct that AAA servers and EAP servers need to implement > channel binding for network access in such environments. > I'm not sure whether peers only doing network access SHOULD implement > channel binding or MUST implement channel binding. > > Practically speaking, it will be a while before peers implement channel > binding for network access. > The sorts of attacks that result without channel binding are attacks > where a peer thinks it is doing network access authentication but what > it's really doing is helping an attacker access an application. > If all the application access peers support channel binding, then you > could potentially require the eap-lower-layer attribute or similar for > application authentication and work securely in environments where peers > for network access have not been updated yet. [Joe] I'm trying to get a handle on the attack mechanism here. In this attack a valid network service is trying to spoof an application service? Since it knows the MSK it can do this if the channel-binding of the lower-layer into the EAP conversation is not enforced. If the AAA server always enforces channel bindings for applications then it will catch the spoofing attempt. The reverse case may also be an issue where an application service is trying to spoof a network service. In this case, if the AAA server validates that the application channel binding is not present then it can prevent the spoofing. However the server MUST understand channel bindings even if the peers do not. I think the document did try to capture this in the following sentence: "If the EAP server is aware that authentication is for something other than a network service, it too MUST default to requiring channel binding." I think we could state this a bit better as something like: "In environments where EAP is used for applications authentication and network access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD support channel binding to explicitly identify the reason for authentication. Any new usage of EAP MUST support channel bindings to prevent confusion with network access usage. " > It's also kind of tempting to stick our head in the sand and just add > the clarification that "yes, we mean network access too." > > --Sam
RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
Sam, I was concerned that something along these lines was lurking in here :-(. I think this is the crucial "running code" consideration to start from: > Practically speaking, it will be a while before peers implement channel > binding for network access. Assuming that network access does not use channel binding, how does one avoid the proxy attack on network access authentication via application access authentication when the latter is introduced? For environments where EAP is used for network access authentication, the suggestion of a "MUST use" requirement for channel binding with application access authentication sounds like the right approach: > If all the application access peers support channel binding, then you > could potentially require the eap-lower-layer attribute or similar for > application authentication and work securely in environments where peers > for network access have not been updated yet. Is that plausible and reasonable in practice? This would be in addition to the "MUST implement" requirements for AAA servers, EAP serves and peers doing application access: > I know you're correct that AAA servers and EAP servers need to implement > channel binding for network access in such environments. Thanks, --David > -Original Message- > From: Sam Hartman [mailto:[email protected]] > Sent: Tuesday, June 18, 2013 10:19 AM > To: Black, David > Cc: [email protected]; [email protected]; General Area Review Team; > [email protected]; [email protected] > Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 > > >>>>> "Black," == Black, David writes: > > Black,> The next to last paragraph on p.3 begins with this sentence: > > Black,>For these reasons, channel binding MUST be implemented by > Black,> peers, EAP servers and AAA servers in environments where EAP > Black,> authentication is used to access application layer services. > > Black,> It appear that this "MUST" requirement applies to all uses > Black,> of EAP, including network access authentication, not just > Black,> application layer access authentication. If so, that's not > Black,> immediately obvious from the text, and an additional > Black,> sentence should be added to make this clearer. If not, the > Black,> above sentence needs to exclude network access > Black,> authentication from that requirement. > > > I know you're correct that AAA servers and EAP servers need to implement > channel binding for network access in such environments. > I'm not sure whether peers only doing network access SHOULD implement > channel binding or MUST implement channel binding. > > Practically speaking, it will be a while before peers implement channel > binding for network access. > The sorts of attacks that result without channel binding are attacks > where a peer thinks it is doing network access authentication but what > it's really doing is helping an attacker access an application. > If all the application access peers support channel binding, then you > could potentially require the eap-lower-layer attribute or similar for > application authentication and work securely in environments where peers > for network access have not been updated yet. > It's also kind of tempting to stick our head in the sand and just add > the clarification that "yes, we mean network access too." > > --Sam
Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
> "Black," == Black, David writes: Black,> The next to last paragraph on p.3 begins with this sentence: Black,>For these reasons, channel binding MUST be implemented by Black,> peers, EAP servers and AAA servers in environments where EAP Black,> authentication is used to access application layer services. Black,> It appear that this "MUST" requirement applies to all uses Black,> of EAP, including network access authentication, not just Black,> application layer access authentication. If so, that's not Black,> immediately obvious from the text, and an additional Black,> sentence should be added to make this clearer. If not, the Black,> above sentence needs to exclude network access Black,> authentication from that requirement. I know you're correct that AAA servers and EAP servers need to implement channel binding for network access in such environments. I'm not sure whether peers only doing network access SHOULD implement channel binding or MUST implement channel binding. Practically speaking, it will be a while before peers implement channel binding for network access. The sorts of attacks that result without channel binding are attacks where a peer thinks it is doing network access authentication but what it's really doing is helping an attacker access an application. If all the application access peers support channel binding, then you could potentially require the eap-lower-layer attribute or similar for application authentication and work securely in environments where peers for network access have not been updated yet. It's also kind of tempting to stick our head in the sand and just add the clarification that "yes, we mean network access too." --Sam
