From Josh.Howlett@ja.net Mon Oct 1 06:54:42 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DF211E8178 for ; Mon, 1 Oct 2012 06:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy1YrAdRFm2d for ; Mon, 1 Oct 2012 06:54:41 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id B044D11E81DE for ; Mon, 1 Oct 2012 06:54:40 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 5DC294A6B60_69A09FB; Mon, 1 Oct 2012 13:54:39 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id D3CA14A6B42_69A09EF; Mon, 1 Oct 2012 13:54:38 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Mon, 1 Oct 2012 14:54:38 +0100 From: Josh Howlett To: Jim Schaad , Sam Hartman Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt Thread-Index: AQHNAEeuQDxs1CsWJEGtnzqtiGQZ65Zq22SAgTrL24A= Date: Mon, 1 Oct 2012 13:54:37 +0000 Message-ID: In-Reply-To: <000801cd026e$19e4b710$4dae2530$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 13:54:42 -0000 Jim, First, I apologise for the appalling tardiness of this response to your review. Thank you for your comments. >Major > >1. Do we have any other examples where we might have a SAML >requester/responder other than the case of the RP/IdP? If so, it might be >wise to mention at least one other case in the introductory paragraph in >section 1. Otherwise it might be easier to just say that we are sending >messages between the RP and the IdP and not generalize it. Can anybody >see >a reason that one might want to reverse the endpoints? So that the RP >becomes the server and the IdP the client??? I agree that your proposed change would more clearly reflect the primary motivating use case (Abfab), but I would strongly prefer to maintain the generalisation because it maintains consistency with the other bindings defined by OASIS SSTC. These bindings talk of requesters and responders, and RPs and IdPs are instances of higher-level abstractions that happen to use these bindings (as requesters and responders) to communicate. I would be happy to add some text talking around this point, if you think that would help? >2. In section 3, I would suggest adding the text "There MUST be at most >one >SAML-Message Attribute in either a RADIUS request or response message." Ok. >3. In section 4.1 and 5.1, the Identification will require an IANA >action. >I think we are looking at urn:ietf:params:xml:ns:abfab:here> >I think that something probably looks like SAML:binding:RADIUS-binding in >section 4.1. The contact information should be iesg@ietf.org. Ok. > I don't see >any requirement that the binding should be specific to the RADIUS >transport >- do you? Well... I think it has to, by definition. The underlying transport is inherent to a discussion of any binding. Perhaps I have misunderstood your point? >4. In section 4.2 item #2 - If the SAML responder is going to response >to a >SAML request, is there a requirement that the responder MUST response no >later than the Access-Accept or Access-Reject message? I think that's implicitly true, because either of those messages necessarily concludes a RADIUS exchange. However, I like the idea of making this explicit in the text. > Also what other >currently defined packets is the element permitted in - for example can I >include it in an Access-Challenge packet? I have a strong preference to constrain the SAML response to the Access-Accept and Access-Reject packets. RADIUS has a really fuzzy notion of a session, and I think drawing some clear boundaries here could avoid inadvertently reaching inconsistent states at the AAA and SAML layers. >5. In section 5.2 - Section on Responses: - I am confused when I read >this >text. It first says that you must return exactly one authentication >statement. It then says that the IdP can return other statements in the >assertion. Are these other assertions allowed to be authentication >Statements No; only allowed one of these. > or are they some other type of statement? Yes. A SAML assertion can contain three types of statements: authentication, authorisation and attribute. >6. The last sentence in section 5.2 makes no sense to me. I believe >the >sentence should finish "to a Relying Part without step 2 occurring." >Doing >it without having the EAP protocol run in section 3 would be bad news. Right :-) thanks >Ditto the last paragraph in section 5.3 - I think it should just say that >"The Request in section 5.3.2 is omitted from the process." Yes. >7. In section 5.3.4 - I would like to see a statement that in this >profile, >if the is marked as fail then the EAP should also >return fail. That is there should not be difference in the returned value >for the SAML request and the EAP dialog. Agreed. >8. In section 5.4.1 paragraph 3 - I am not sure how this section >interacts >with the ability of an IdP to return a Pseudonymous identifier. Are you >stating that the identifier must already exist, or just that the policy >for >creating the identifier must already exist in the case AllowCreate is set >to >"false".=20=20 The former. However, isn't this policy orthogonal to the question of whether the identifier is pseudonymous or not? >9. In section 5.4.1 last paragraph - I think we should make some type of >statement about what happens if either the request is not signed, or the >signature on the request cannot be validated by the IdP. I think that >both >of these cases are going to be more likely that the case of it is signed >and >the IdP happens to be able to validate the signature. I agree. I would prefer that the spec says words to the effect of "die if the signature, if any, does not conform to policy" and remain silent on the question of policy. (I have a strong personal preference to deal with this question by prohibiting message-level signatures altogether, and leaving integrity to the transport level where deployers have a better record of getting this right, but that wasn't a popular opinion in Taiwan). >10. I believe that a discussion of what is expected to happen as these >messages cross federation boundaries is probably in order. What would you expect to see in this discussion? >Nits > >1. We need to get a consistent method of doing Abfab or ABFAB. I have >always used all upper case, this document is doing mixed case. We should >be >consistent and I think the all upper case is the normal way. Please >change. Ok. >2. I object to the capitalization in the following sentence "The NAI >SHOULD >be used to route the > message towards the SAML responder, which MAY be more than one > RADIUS hop distant." How are these requirements on the binding >that >is being produced? Are these not intrinsic properties that are true just >by >saying that we are using RAIDUS? Ok. >3. There is an extraneous period in the last sentence of section 5.3.3 Ok. >4. Bad grammar /confirmation as the processing as defined in/ I don't >know >what this should be. Sorry -- defined where? >5. Please add http links to your SAML references so I don't have to >search >for them - I am very lazy. Ok. >6. Can we move some of the references out of normative? For example I >think that 3575 could be informative since it affects only the document >writer and not the implementer. The same is probably true for some of >the >other references. Ok. >s/reponse/response/ >s/Consequently here exists/Consequently there exists/ >s/unsolicited responser/unsolicited response/ >s/disgression/discretion/ I will have an update out by the end of the week. Thanks, Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From ietf@augustcellars.com Mon Oct 1 11:56:54 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C60921F89A7 for ; Mon, 1 Oct 2012 11:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfbCalNC2G8Q for ; Mon, 1 Oct 2012 11:56:53 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 77D1521F893B for ; Mon, 1 Oct 2012 11:56:45 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E151C2CA15; Mon, 1 Oct 2012 11:56:44 -0700 (PDT) From: "Jim Schaad" To: "'Josh Howlett'" , "'Sam Hartman'" References: <000801cd026e$19e4b710$4dae2530$@augustcellars.com> In-Reply-To: Date: Mon, 1 Oct 2012 11:55:19 -0700 Message-ID: <001201cda006$4dfd3460$e9f79d20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFWpZiOiQZ9vr02AiuCiZdDGNTbh5iSuicw Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 18:56:54 -0000 I have to both remember what I was thinking and find a copy of the document for review again. > -----Original Message----- > From: Josh Howlett [mailto:Josh.Howlett@ja.net] > Sent: Monday, October 01, 2012 6:55 AM > To: Jim Schaad; Sam Hartman > Cc: abfab@ietf.org > Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt > > Jim, > > First, I apologise for the appalling tardiness of this response to your review. > Thank you for your comments. > > >Major > > > >1. Do we have any other examples where we might have a SAML > >requester/responder other than the case of the RP/IdP? If so, it might > >be wise to mention at least one other case in the introductory > >paragraph in section 1. Otherwise it might be easier to just say that > >we are sending messages between the RP and the IdP and not generalize > >it. Can anybody see a reason that one might want to reverse the > >endpoints? So that the RP becomes the server and the IdP the client??? > > I agree that your proposed change would more clearly reflect the primary > motivating use case (Abfab), but I would strongly prefer to maintain the > generalisation because it maintains consistency with the other bindings > defined by OASIS SSTC. These bindings talk of requesters and responders, > and RPs and IdPs are instances of higher-level abstractions that happen to > use these bindings (as requesters and responders) to communicate. > > I would be happy to add some text talking around this point, if you think that > would help? Moving the first sentence of pargraph 4 into paragraph 1 would address my concern, that people don't read one paragraph - say this is abfab only - and skip. > >3. In section 4.1 and 5.1, the Identification will require an IANA > >action. > >I think we are looking at urn:ietf:params:xml:ns:abfab: >here> > >I think that something probably looks like SAML:binding:RADIUS-binding > >in section 4.1. The contact information should be iesg@ietf.org. > > Ok. > > > I don't see > >any requirement that the binding should be specific to the RADIUS > >transport > >- do you? > > Well... I think it has to, by definition. The underlying transport is inherent to a > discussion of any binding. Perhaps I have misunderstood your point? > I think that this issue had to do with confusion on my part on the differences between what happens for RADIUS and Diameter. I agree with you that this is a RADIUS specific transport now, and "RADIUS" can be transported by Diameter. > >4. In section 4.2 item #2 - If the SAML responder is going to response > >to a SAML request, is there a requirement that the responder MUST > >response no later than the Access-Accept or Access-Reject message? > > I think that's implicitly true, because either of those messages necessarily > concludes a RADIUS exchange. However, I like the idea of making this explicit > in the text. > This currently feels good to me, however it means that there is a question on how an Acceptor could later ask for additional attributes from the IdP. While this is not currently supported by GSS-EAP (yuk), I don't know that I also want to update this document to be able to do it here. I don't know that that is going to be in the Access-Accept/Reject. However it may be that is a different set of bindings and should be addressed separately. Given the current GSS-EAP, this is an explicit requirement that needs to be stated. (OK - so I am arguing both sides of the issue). > > Also what other > >currently defined packets is the element permitted in - for example can > >I include it in an Access-Challenge packet? > > I have a strong preference to constrain the SAML response to the Access- > Accept and Access-Reject packets. RADIUS has a really fuzzy notion of a > session, and I think drawing some clear boundaries here could avoid > inadvertently reaching inconsistent states at the AAA and SAML layers. > > >5. In section 5.2 - Section on Responses: - I am confused when I read > >this text. It first says that you must return exactly one > >authentication statement. It then says that the IdP can return other > >statements in the assertion. Are these other assertions allowed to be > >authentication Statements > > No; only allowed one of these. > > > or are they some other type of statement? > > Yes. A SAML assertion can contain three types of statements: > authentication, authorisation and attribute. > Ok - I think was I needed more SAML background at the time. > >8. In section 5.4.1 paragraph 3 - I am not sure how this section > >interacts with the ability of an IdP to return a Pseudonymous > >identifier. Are you stating that the identifier must already exist, or > >just that the policy for creating the identifier must already exist in > >the case AllowCreate is set to "false". > > The former. However, isn't this policy orthogonal to the question of whether > the identifier is pseudonymous or not? Yes, it is orthogonal to the question is the identifier pseudonymous. Changing the text slightly might solve my issue. The problem I have with "establishing a new identifier for a principal if none exists". The question is, is a new pseudonymous tag for an existing principal "establishing a new identifier". > > >9. In section 5.4.1 last paragraph - I think we should make some type > >of statement about what happens if either the request is not signed, or > >the signature on the request cannot be validated by the IdP. I think > >that both of these cases are going to be more likely that the case of > >it is signed and the IdP happens to be able to validate the signature. > > I agree. I would prefer that the spec says words to the effect of "die if the > signature, if any, does not conform to policy" and remain silent on the > question of policy. > > (I have a strong personal preference to deal with this question by prohibiting > message-level signatures altogether, and leaving integrity to the transport > level where deployers have a better record of getting this right, but that > wasn't a popular opinion in Taiwan). > I am in the same camp that you are and did not understand the ground swell in Taiwan. > >10. I believe that a discussion of what is expected to happen as these > >messages cross federation boundaries is probably in order. > > What would you expect to see in this discussion? My problems deal with the questions dealing with if names of attributes should be changed/could be changed as federation boundaries are crossed. The values could also be remapped at the same time if different federations had different ideas of things. Values could be silently removed if the second federation does not believe that the first federation has the ability to make such a statement, and this will make it appear as if the IdP was unwilling to provide the information. See the discussion from Paris in the audio. > >4. Bad grammar /confirmation as the processing as defined in/ I don't > >know what this should be. > > Sorry -- defined where? Section 5.4.2 bullet point 4 (search for the string) > I will have an update out by the end of the week. > > Thanks, Josh. > > > > > Janet is a trading name of The JNT Association, a company limited by > guarantee which is registered in England under No. 2881024 and whose > Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, > Oxfordshire. OX11 0SG From gabilm@um.es Tue Oct 2 01:36:19 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B5021F8B4C for ; Tue, 2 Oct 2012 01:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUfTscWo2674 for ; Tue, 2 Oct 2012 01:36:18 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 7D01121F8AF0 for ; Tue, 2 Oct 2012 01:36:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 85F4D4C437; Tue, 2 Oct 2012 10:36:16 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VJg7LNZRQMQs; Tue, 2 Oct 2012 10:36:16 +0200 (CEST) Received: from inf-205-228.inf.um.es (inf-205-228.inf.um.es [155.54.205.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon12.um.es (Postfix) with ESMTPSA id 95A734C440; Tue, 2 Oct 2012 10:36:10 +0200 (CEST) Message-ID: <506AA77A.8080501@um.es> Date: Tue, 02 Oct 2012 10:36:10 +0200 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jim Schaad References: <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <001201cda006$4dfd3460$e9f79d20$@augustcellars.com> In-Reply-To: <001201cda006$4dfd3460$e9f79d20$@augustcellars.com> X-Enigmail-Version: 1.4.4 OpenPGP: id=8D119153 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 08:36:19 -0000 El 01/10/12 20:55, Jim Schaad escribió: >>> or are they some other type of statement? >> Yes. A SAML assertion can contain three types of statements: >> authentication, authorisation and attribute. >> > Ok - I think was I needed more SAML background at the time. afaik, authorization statements are deprecated in SAML2.0 best regards, Gabi. > > -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de Ingenier’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From Josh.Howlett@ja.net Tue Oct 2 06:16:04 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A54721F87B7 for ; Tue, 2 Oct 2012 06:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCyTRm0XnWPw for ; Tue, 2 Oct 2012 06:16:03 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id A428021F879C for ; Tue, 2 Oct 2012 06:16:02 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 3A2EE20C7258_6AE911B; Tue, 2 Oct 2012 13:16:01 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 4D3BE20C7149_6AE910F; Tue, 2 Oct 2012 13:16:00 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Tue, 2 Oct 2012 14:16:00 +0100 From: Josh Howlett To: Jim Schaad , 'Sam Hartman' Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt Thread-Index: AQHNAEeuQDxs1CsWJEGtnzqtiGQZ65Zq22SAgTrL24CAAFQIgIABM34A Date: Tue, 2 Oct 2012 13:15:59 +0000 Message-ID: In-Reply-To: <001201cda006$4dfd3460$e9f79d20$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 13:16:04 -0000 >, however it means that there is a question >on how an Acceptor could later ask for additional attributes from the IdP. >While this is not currently supported by GSS-EAP (yuk), I don't know that >I >also want to update this document to be able to do it here. I don't know >that that is going to be in the Access-Accept/Reject. However it may be >that is a different set of bindings and should be addressed separately. >Given the current GSS-EAP, this is an explicit requirement that needs to >be >stated. (OK - so I am arguing both sides of the issue). Recall that this text is describing the general case, where the SAML requester is not necessarily an ABFAB acceptor; it could be wireless AP or VPN concentrator and their existing RADIUS API is probably good enough. However that's definitely not true in the case of an ABFAB acceptor; we are dependent on the GSS API and so we also need a discussion in Kitten. For the purposes of this document, I had been assuming that we could safely decouple discussion of the abstract assertion request API (in Kitten) from discussion of the protocol (in ABFAB), and that we should define the latter first in order to motivate the necessary work in Kitten. We may need to reconsider things if that is not a reasonable assumption... >> >8. In section 5.4.1 paragraph 3 - I am not sure how this section >> >interacts with the ability of an IdP to return a Pseudonymous >> >identifier. Are you stating that the identifier must already exist, or >> >just that the policy for creating the identifier must already exist in >> >the case AllowCreate is set to "false". >>=20 >> The former. However, isn't this policy orthogonal to the question of >whether >> the identifier is pseudonymous or not? > >Yes, it is orthogonal to the question is the identifier pseudonymous. >Changing the text slightly might solve my issue. The problem I have with >"establishing a new identifier for a principal if none exists". The >question is, is a new pseudonymous tag for an existing principal >"establishing a new identifier". Yes, for the particular identifier that denotes the subject of an assertion (which, confusingly, may or may not be the "tag" used by the application to denote the subject; often an attribute (e.g., 'mail') from the assertion is used instead). Do you have a specific concern? >>=20 >> >9. In section 5.4.1 last paragraph - I think we should make some type >> >of statement about what happens if either the request is not signed, or >> >the signature on the request cannot be validated by the IdP. I think >> >that both of these cases are going to be more likely that the case of >> >it is signed and the IdP happens to be able to validate the signature. >>=20 >> I agree. I would prefer that the spec says words to the effect of "die >>if >the >> signature, if any, does not conform to policy" and remain silent on the >> question of policy. >>=20 >> (I have a strong personal preference to deal with this question by >prohibiting >> message-level signatures altogether, and leaving integrity to the >transport >> level where deployers have a better record of getting this right, but >>that >> wasn't a popular opinion in Taiwan). >>=20 > >I am in the same camp that you are and did not understand the ground swell >in Taiwan. Yes, I am now kicking myself for not digging my heels in. As I won't be in Atlanta I will separately write mail arguing that the WG reconsiders this. >> >10. I believe that a discussion of what is expected to happen as these >> >messages cross federation boundaries is probably in order. >>=20 >> What would you expect to see in this discussion? > >My problems deal with the questions dealing with if names of attributes >should be changed/could be changed as federation boundaries are crossed. >The values could also be remapped at the same time if different >federations >had different ideas of things. Values could be silently removed if the >second federation does not believe that the first federation has the >ability >to make such a statement, and this will make it appear as if the IdP was >unwilling to provide the information. See the discussion from Paris in >the >audio. This is about the application of policy, and so I would prefer if we punted this discussion to the architecture document. Would this be ok? Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Tue Oct 2 06:39:16 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0A021F85C2 for ; Tue, 2 Oct 2012 06:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtP-qGSbTRHv for ; Tue, 2 Oct 2012 06:39:16 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id EA1A221F8532 for ; Tue, 2 Oct 2012 06:39:15 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 21FAF20C7149_6AEE83B; Tue, 2 Oct 2012 13:39:15 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 2FA8C20C710E_6AEE82F; Tue, 2 Oct 2012 13:39:14 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Tue, 2 Oct 2012 14:39:13 +0100 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt Thread-Index: AQHNAEeuQDxs1CsWJEGtnzqtiGQZ65Zq22SAgTrL24CAAFQIgIABM34AgAAWSrL///A2AA== Date: Tue, 2 Oct 2012 13:39:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 13:39:16 -0000 On 02/10/2012 14:34, "Sam Hartman" wrote: >I think that we need to have a mandatory-to-implement policy for >signature handling to guarantee interoperability. I think that >mandatory-to-implement policy should be ignore the signature in all its >bulk. > >I'm fine with implementations having other policies. I'm happy with that. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Tue Oct 2 06:41:28 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494EE21F85F9 for ; Tue, 2 Oct 2012 06:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqhA+TGXIJjI for ; Tue, 2 Oct 2012 06:41:25 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3642721F85C2 for ; Tue, 2 Oct 2012 06:41:25 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id E17E14A6B5C_6AEF03B; Tue, 2 Oct 2012 13:41:23 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id B46F34A6B58_6AEF03F; Tue, 2 Oct 2012 13:41:23 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Tue, 2 Oct 2012 14:41:23 +0100 From: Josh Howlett To: Jim Schaad , Sam Hartman Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt Thread-Index: AQHNAEeuQDxs1CsWJEGtnzqtiGQZ65Zq22SAgTrL24CAAY6RgA== Date: Tue, 2 Oct 2012 13:41:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <6811782BC7EC684D9FCBF7C61E41DB2B@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 13:41:28 -0000 > >>2. In section 3, I would suggest adding the text "There MUST be at most >>one >>SAML-Message Attribute in either a RADIUS request or response message." > >Ok. Just pedalling back here. Owing to the length constraint of RADIUS attributes, we will generally need to fragment the SAML message across multiple SAML-Message attributes within the RADIUS message. Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Tue Oct 2 06:42:22 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A62D21F85C3 for ; Tue, 2 Oct 2012 06:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.373 X-Spam-Level: **** X-Spam-Status: No, score=4.373 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZF-sVUHTZW1 for ; Tue, 2 Oct 2012 06:42:22 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 210FF21F85C2 for ; Tue, 2 Oct 2012 06:42:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0D2772010F; Tue, 2 Oct 2012 09:34:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6DA37414A; Tue, 2 Oct 2012 09:34:40 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Tue, 02 Oct 2012 09:34:40 -0400 In-Reply-To: (Josh Howlett's message of "Tue, 2 Oct 2012 13:15:59 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 13:42:22 -0000 I think that we need to have a mandatory-to-implement policy for signature handling to guarantee interoperability. I think that mandatory-to-implement policy should be ignore the signature in all its bulk. I'm fine with implementations having other policies. From stephen.farrell@cs.tcd.ie Tue Oct 2 07:04:47 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B998E21F8588 for ; Tue, 2 Oct 2012 07:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68maqQo9lkPh for ; Tue, 2 Oct 2012 07:04:47 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A307721F8458 for ; Tue, 2 Oct 2012 07:04:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 93EF31044C2; Tue, 2 Oct 2012 15:04:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1349186679; bh=l/k7cJQUNpIzOH FEWxQIlAi7J8CPTW/R5HD8jyKuGjs=; b=sz7Dx8Z0rjt8G12DAzwO8y8WP41691 aIUFhykmc9s3p1INtBlZT/iDomwwnBIVKsKlAQEiQgmz7Y+JgEHRqLDaAg0Em+4/ E3mogtj6ENZcHzOKOOjsv0IsDCNqKUZKwBx132NcwJ75juoVFlQEHVNnCf5ILIdp S44yRVjd8UXaUCbtGWdcsQunW9krlhPKxtBx1+QfytJGX2GdxjCTGHrbp4DIlBye NCd6k0ARZ016/srOA11ETn7GdTWjcFUP5w8MBbONWYJWK0wb73meDA3QkuZDTwro k1+Kxh5OoV1mXhOCcYMRFLi4tiNisOcyucZC7JlD4LEQKUVtzcUUOWIQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id D3o41J+rVEwO; Tue, 2 Oct 2012 15:04:39 +0100 (IST) Received: from [IPv6:2001:770:10:203:1981:101d:ab69:48ba] (unknown [IPv6:2001:770:10:203:1981:101d:ab69:48ba]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7D327171478; Tue, 2 Oct 2012 15:04:38 +0100 (IST) Message-ID: <506AF477.4020900@cs.tcd.ie> Date: Tue, 02 Oct 2012 15:04:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:04:47 -0000 (jumping in with little context...) On 10/02/2012 02:34 PM, Sam Hartman wrote: > I think that we need to have a mandatory-to-implement policy for > signature handling to guarantee interoperability. I think that > mandatory-to-implement policy should be ignore the signature in all its > bulk. Defining signature "handling" as ignoring the signature would seem very insecure, no? How'd you justify that? It'd seem to call for a lot of security considerations text at minimum. S. > > I'm fine with implementations having other policies. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > > From stephen.farrell@cs.tcd.ie Tue Oct 2 07:36:06 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E69121F84DD for ; Tue, 2 Oct 2012 07:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdiqKKM1LU3t for ; Tue, 2 Oct 2012 07:36:05 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B618721F84DC for ; Tue, 2 Oct 2012 07:36:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 2688A17147C; Tue, 2 Oct 2012 15:36:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1349188564; bh=j//5WrEIdXJq0F FggS1DM6OCo3mL7CriSjWwuuZKuwQ=; b=IB7m14bbnyFsaciS3XPTZ6lY+k9gHI FvmEL8SBqC/aHe8hQ3GJSTWtUgkwrqpV8PCyFx7UupXiqfpQDQ1R5R0B+y6ganJU Gx2RdHZTrhOF/avqBdOIxdXf5Pqxq/uCHD5/pegD6mTyL1rz7KREg5VMNMnLI1YV W5JjXB9ElK4S2747jeEZnE1k8afh6Nx5Me39kGeG/7/ba/HppuIPzFKWBGPpo7L3 1IgayxcY2fCosRG+3ae3iOFILm0AQIg7xFQZfep7DSt+QpsbF66DjDLZeKBWDd12 4v6x6JPYZMI6eQYP/Qdzz7HvJHVaafjYfuaU28deltkk36qwl1kcEm6g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id JYKNcW2HHMsG; Tue, 2 Oct 2012 15:36:04 +0100 (IST) Received: from [IPv6:2001:770:10:203:1981:101d:ab69:48ba] (unknown [IPv6:2001:770:10:203:1981:101d:ab69:48ba]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B4813171478; Tue, 2 Oct 2012 15:36:00 +0100 (IST) Message-ID: <506AFBD1.2060101@cs.tcd.ie> Date: Tue, 02 Oct 2012 15:36:01 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Sam Hartman References: <506AF477.4020900@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:36:06 -0000 On 10/02/2012 03:27 PM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Farrell writes: > > Stephen> (jumping in with little context...) > > Stephen> On 10/02/2012 02:34 PM, Sam Hartman wrote: > >> I think that we need to have a mandatory-to-implement policy for > >> signature handling to guarantee interoperability. I think that > >> mandatory-to-implement policy should be ignore the signature in > >> all its bulk. > > Stephen> Defining signature "handling" as ignoring the signature > Stephen> would seem very insecure, no? How'd you justify that? > > But something that can actually be implemented. The idea that you could > actually construct a usable PKI is sufficiently preposterous that it > need not be considered:-) > > OK, now that we've squared off, let me try and make a serious > contribution. :-) > The SAML signature mechanism is anselary to the security approach that > we're using for this. > I think a lot of us would like to not even support signatures in this > SAML binding because we believe that the hop-by-hop integrity is > sufficient and because those signatures will create interoperability > problems. Is there text somewhere that argues that hop-by-hop integrity is enough for abfab? Is that for all use-cases or just some? I reckon you'll need that text if "ignore signature" is the MUST implement. > It seems silly to me though to reject a request because it is signed > when you would hapilly accept the same request were the signature > stripped. I agree. After lots of debate, DKIM also passes on signatures even after they're sure to no longer be verifiable, so you have a good precedent for not stripping. OTOH, it also seems silly to say ignore signature is the MUST implement, if you're able to pass the signature around and it could in principle be verified. S. > > > From hartmans@painless-security.com Tue Oct 2 07:52:26 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AFD21F8525 for ; Tue, 2 Oct 2012 07:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.371 X-Spam-Level: **** X-Spam-Status: No, score=4.371 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOLzz0etTL0A for ; Tue, 2 Oct 2012 07:52:23 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3709821F8514 for ; Tue, 2 Oct 2012 07:52:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E51C72010F; Tue, 2 Oct 2012 10:27:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A7508414A; Tue, 2 Oct 2012 10:27:20 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <506AF477.4020900@cs.tcd.ie> Date: Tue, 02 Oct 2012 10:27:20 -0400 In-Reply-To: <506AF477.4020900@cs.tcd.ie> (Stephen Farrell's message of "Tue, 02 Oct 2012 15:04:39 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:52:26 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> (jumping in with little context...) Stephen> On 10/02/2012 02:34 PM, Sam Hartman wrote: >> I think that we need to have a mandatory-to-implement policy for >> signature handling to guarantee interoperability. I think that >> mandatory-to-implement policy should be ignore the signature in >> all its bulk. Stephen> Defining signature "handling" as ignoring the signature Stephen> would seem very insecure, no? How'd you justify that? But something that can actually be implemented. The idea that you could actually construct a usable PKI is sufficiently preposterous that it need not be considered:-) OK, now that we've squared off, let me try and make a serious contribution. The SAML signature mechanism is anselary to the security approach that we're using for this. I think a lot of us would like to not even support signatures in this SAML binding because we believe that the hop-by-hop integrity is sufficient and because those signatures will create interoperability problems. It seems silly to me though to reject a request because it is signed when you would hapilly accept the same request were the signature stripped. From ietf@augustcellars.com Tue Oct 2 08:36:59 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1273421F852E for ; Tue, 2 Oct 2012 08:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddc8qyFN48ne for ; Tue, 2 Oct 2012 08:36:58 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id A1D4621F84FC for ; Tue, 2 Oct 2012 08:36:58 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id D421238E6A; Tue, 2 Oct 2012 08:36:57 -0700 (PDT) From: "Jim Schaad" To: "'Josh Howlett'" , "'Sam Hartman'" References: In-Reply-To: Date: Tue, 2 Oct 2012 08:35:32 -0700 Message-ID: <004801cda0b3$8fb8de60$af2a9b20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLPCmuNg41iwKhKvxBIATutO18x35WjUhoQ Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:36:59 -0000 > -----Original Message----- > From: Josh Howlett [mailto:Josh.Howlett@ja.net] > Sent: Tuesday, October 02, 2012 6:41 AM > To: Jim Schaad; Sam Hartman > Cc: abfab@ietf.org > Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt > > > > >>2. In section 3, I would suggest adding the text "There MUST be at > >>most one SAML-Message Attribute in either a RADIUS request or > response > >>message." > > > >Ok. > > Just pedalling back here. Owing to the length constraint of RADIUS attributes, > we will generally need to fragment the SAML message across multiple SAML- > Message attributes within the RADIUS message. Yes you are right it can be fragmented, is there a way to say that you can only have one "unfragmented attribute" in a "logical message"? Jim > > Josh. > > > > Janet is a trading name of The JNT Association, a company limited by > guarantee which is registered in England under No. 2881024 and whose > Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, > Oxfordshire. OX11 0SG From ietf@augustcellars.com Tue Oct 2 08:39:39 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2F321F8530 for ; Tue, 2 Oct 2012 08:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHSuQAG4vSMc for ; Tue, 2 Oct 2012 08:39:38 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8B5721F852E for ; Tue, 2 Oct 2012 08:39:38 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 8381A2CA1B; Tue, 2 Oct 2012 08:39:38 -0700 (PDT) From: "Jim Schaad" To: "'Stephen Farrell'" , "'Sam Hartman'" References: <506AF477.4020900@cs.tcd.ie> <506AFBD1.2060101@cs.tcd.ie> In-Reply-To: <506AFBD1.2060101@cs.tcd.ie> Date: Tue, 2 Oct 2012 08:38:13 -0700 Message-ID: <004901cda0b3$ef80d3c0$ce827b40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbJb0R6Z2SjjU6LslRekoy+Hp0kAHHASXRASFvOKQCIgrJngC3bnNql10MtTA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:39:39 -0000 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, October 02, 2012 7:36 AM > To: Sam Hartman > Cc: Josh Howlett; Jim Schaad; abfab@ietf.org > Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt > > > > On 10/02/2012 03:27 PM, Sam Hartman wrote: > >>>>>> "Stephen" == Stephen Farrell writes: > > > > Stephen> (jumping in with little context...) > > > > Stephen> On 10/02/2012 02:34 PM, Sam Hartman wrote: > > >> I think that we need to have a mandatory-to-implement policy for > > >> signature handling to guarantee interoperability. I think that > > >> mandatory-to-implement policy should be ignore the signature in > > >> all its bulk. > > > > Stephen> Defining signature "handling" as ignoring the signature > > Stephen> would seem very insecure, no? How'd you justify that? > > > > But something that can actually be implemented. The idea that you > > could actually construct a usable PKI is sufficiently preposterous > > that it need not be considered:-) > > > > OK, now that we've squared off, let me try and make a serious > > contribution. > > :-) > > > The SAML signature mechanism is anselary to the security approach that > > we're using for this. > > I think a lot of us would like to not even support signatures in this > > SAML binding because we believe that the hop-by-hop integrity is > > sufficient and because those signatures will create interoperability > > problems. > > Is there text somewhere that argues that hop-by-hop integrity is enough for > abfab? Is that for all use-cases or just some? > > I reckon you'll need that text if "ignore signature" is the MUST implement. > > > It seems silly to me though to reject a request because it is signed > > when you would hapilly accept the same request were the signature > > stripped. > > I agree. After lots of debate, DKIM also passes on signatures even after > they're sure to no longer be verifiable, so you have a good precedent for not > stripping. > > OTOH, it also seems silly to say ignore signature is the MUST implement, if > you're able to pass the signature around and it could in principle be verified. But one of the current precepts of ABFAB is that you are not going to be in a single trust anchor world, the TA of the signer may not be known or trusted by the acceptor. This means that you probably cannot validate the signature even if it is present. Jim > > S. > > > > > > > > From stephen.farrell@cs.tcd.ie Tue Oct 2 08:43:02 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A340521F855A for ; Tue, 2 Oct 2012 08:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDZxfY7ZeUol for ; Tue, 2 Oct 2012 08:43:02 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id EE4EE21F854C for ; Tue, 2 Oct 2012 08:43:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 17C901044C2; Tue, 2 Oct 2012 16:43:00 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1349192579; bh=aEpvdoEKjYwUJt xZL2A4TuhSbiJJL5C+XpYOvsMY3NI=; b=0Np4dVnqvI5k1QRdy/PdmY5H3UnDiC HAit1ZMOyu4fjrzBjhbrBXNsEbfELmoZhK7BXw75IIS6Scb54BhrnWv9ltFMgzL9 PHXLOS7xVp8cK3R3VfZJLkm0ziEI48jq4BAZnse/ki1Gd5xBRUAO1BY1QYfWDpLb +eVXDubUeH7dEN5wjpJ1nUSmnulAdeskI3cMGX6KyJv8M51zVN89uo9ha/EYUxE8 S9PNP7kQw/IpcMUGjrJFohl91wQDINTfQV7SA1Gl/MDBdlxmhaMH9NmmRoDeAxvl m77RtiuemEajEwcc83movrkqyQnSy3tIZE5gOtwCxsddG5xyFbOoc5CQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 0upZ3AeKZC8U; Tue, 2 Oct 2012 16:42:59 +0100 (IST) Received: from [IPv6:2001:770:10:203:1981:101d:ab69:48ba] (unknown [IPv6:2001:770:10:203:1981:101d:ab69:48ba]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6B96017147C; Tue, 2 Oct 2012 16:42:59 +0100 (IST) Message-ID: <506B0B84.2010504@cs.tcd.ie> Date: Tue, 02 Oct 2012 16:43:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jim Schaad References: <506AF477.4020900@cs.tcd.ie> <506AFBD1.2060101@cs.tcd.ie> <004901cda0b3$ef80d3c0$ce827b40$@augustcellars.com> In-Reply-To: <004901cda0b3$ef80d3c0$ce827b40$@augustcellars.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:43:02 -0000 On 10/02/2012 04:38 PM, Jim Schaad wrote: > But one of the current precepts of ABFAB is that you are not going to be in > a single trust anchor world, the TA of the signer may not be known or > trusted by the acceptor. This means that you probably cannot validate the > signature even if it is present. Sure. That says you have a hard problem. But not that hop-by-hop integrity is sufficient, nor that "ignore the signature" is the right MUST implement. S. From hartmans@painless-security.com Tue Oct 2 08:47:26 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F3B21F8539 for ; Tue, 2 Oct 2012 08:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.368 X-Spam-Level: **** X-Spam-Status: No, score=4.368 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPjB-3KTBL2O for ; Tue, 2 Oct 2012 08:47:26 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id DE35E21F8533 for ; Tue, 2 Oct 2012 08:47:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E94E42010F; Tue, 2 Oct 2012 11:47:12 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 56DF6414A; Tue, 2 Oct 2012 11:47:18 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <506AF477.4020900@cs.tcd.ie> <506AFBD1.2060101@cs.tcd.ie> <004901cda0b3$ef80d3c0$ce827b40$@augustcellars.com> <506B0B84.2010504@cs.tcd.ie> Date: Tue, 02 Oct 2012 11:47:18 -0400 In-Reply-To: <506B0B84.2010504@cs.tcd.ie> (Stephen Farrell's message of "Tue, 02 Oct 2012 16:43:00 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:47:26 -0000 OK, I'm with Josh. This is going to be one of those cases where digging in heals now and saying MUST NOT sign will save us political grief later. A lot of people like Stephen are going to look at ignore signatures and complain, where as they would be more willing to accept that we're simply not using per-message signatures at all. It's unfortunate because I do think there ar situations where signatures are valuable. However, I'm imagining that we're going to be having this argument again and again and again and it just won't be worth the cost. From stephen.farrell@cs.tcd.ie Tue Oct 2 09:03:35 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B1721F8458 for ; Tue, 2 Oct 2012 09:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c96FkhStnFya for ; Tue, 2 Oct 2012 09:03:35 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF3A21F8456 for ; Tue, 2 Oct 2012 09:03:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 870A41044C3; Tue, 2 Oct 2012 17:03:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1349193814; bh=JwSp1H5kKw71r/ jzmxJpevAXACFzVfTO2IKq1yq12sQ=; b=G1+AxKXpTy3TBlx5fYhN7av7yUU2Jl vGnB+JLsYFpU2G5EqZ86p0UXGL/ZswxwWDV9db8zKP8doGy3vTZc57ugZxcQbMRk 45+x3crXH6cShjCr88fVGo6JwZ1I2yCUBPSuuNJDxQc35aDBmyWnOkLlN+cAqhO8 Ib0k1Juvcp6eGsoidlQHy9ZDtr/1Vg1YNucfnsGPxBDUaWj3+yBNwciWlKiXk1pn WiJB5KnuqOU6Lk8VZ2x08ds4YDWU+lVhAylC2vp3zpbsHiB/S3HTFglLH7meO0iU Wa7h5gddq22BW1lrimrwsWMgXp5RFMGSi5/df6G7kvNV/cY5UO57+L9w== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id sZGbhwTKHXPi; Tue, 2 Oct 2012 17:03:34 +0100 (IST) Received: from [IPv6:2001:770:10:203:1981:101d:ab69:48ba] (unknown [IPv6:2001:770:10:203:1981:101d:ab69:48ba]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D1D2D17147C; Tue, 2 Oct 2012 17:03:33 +0100 (IST) Message-ID: <506B1057.90201@cs.tcd.ie> Date: Tue, 02 Oct 2012 17:03:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Sam Hartman References: <506AF477.4020900@cs.tcd.ie> <506AFBD1.2060101@cs.tcd.ie> <004901cda0b3$ef80d3c0$ce827b40$@augustcellars.com> <506B0B84.2010504@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:03:36 -0000 I had a quick look at the -03 draft and I'm confused. Are "ignore signatures is the MUST implement" and "MUST NOT sign" the only real options? For example, I don't get why "IdP MAY sign + RP is NOT REQUIRED to verify signature + RP MUST implement signature verification" is not an option. (Assuming you add text that justifies why hop-by-hop integrity is ok.) Note: I'm not saying that the above is what you ought do, I'm saying I don't get why its not possible. S. On 10/02/2012 04:47 PM, Sam Hartman wrote: > OK, I'm with Josh. This is going to be one of those cases where digging > in heals now and saying MUST NOT sign will save us political grief > later. A lot of people like Stephen are going to look at ignore > signatures and complain, where as they would be more willing to accept > that we're simply not using per-message signatures at all. It's > unfortunate because I do think there ar situations where signatures are > valuable. However, I'm imagining that we're going to be having this > argument again and again and again and it just won't be worth the cost. > > From Josh.Howlett@ja.net Tue Oct 2 12:44:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2FE21F8574 for ; Tue, 2 Oct 2012 12:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O54fat-Nu4Fj for ; Tue, 2 Oct 2012 12:44:52 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8B721F856C for ; Tue, 2 Oct 2012 12:44:52 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 234F71A9AF71_6B4432B; Tue, 2 Oct 2012 19:44:50 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id E9AED1A9A259_6B4431F; Tue, 2 Oct 2012 19:44:49 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Tue, 2 Oct 2012 20:44:49 +0100 From: Josh Howlett To: Jim Schaad , 'Sam Hartman' Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt Thread-Index: AQHNAEeuQDxs1CsWJEGtnzqtiGQZ65Zq22SAgTrL24CAAY6RgIAAH/oAgABFoAA= Date: Tue, 2 Oct 2012 19:44:48 +0000 Message-ID: In-Reply-To: <004801cda0b3$8fb8de60$af2a9b20$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 19:44:53 -0000 >> >>2. In section 3, I would suggest adding the text "There MUST be at >> >>most one SAML-Message Attribute in either a RADIUS request or >> response >> >>message." >> > >> >Ok. >>=20 >> Just pedalling back here. Owing to the length constraint of RADIUS >attributes, >> we will generally need to fragment the SAML message across multiple >>SAML- >> Message attributes within the RADIUS message. > >Yes you are right it can be fragmented, is there a way to say that you can >only have one "unfragmented attribute" in a "logical message"? It says that already in section 4.2, in the context of the Binding: "The SAML responder MUST NOT include more than one SAML response". Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Tue Oct 2 12:48:49 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBB821F8452 for ; Tue, 2 Oct 2012 12:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEs-KgGIupRc for ; Tue, 2 Oct 2012 12:48:49 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id CAF2321F844D for ; Tue, 2 Oct 2012 12:48:48 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2880F1A9AF71_6B4520B; Tue, 2 Oct 2012 19:48:48 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 33BC41A9A259_6B451FF; Tue, 2 Oct 2012 19:48:47 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Tue, 2 Oct 2012 20:48:46 +0100 From: Josh Howlett To: Jim Schaad , 'Sam Hartman' Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt Thread-Index: AQHNAEeuQDxs1CsWJEGtnzqtiGQZ65Zq22SAgTrL24CAAY6RgIAAH/oAgABFoACAAAEaAA== Date: Tue, 2 Oct 2012 19:48:45 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 19:48:49 -0000 On 02/10/2012 20:44, "Josh Howlett" wrote: > >>> >>2. In section 3, I would suggest adding the text "There MUST be at >>> >>most one SAML-Message Attribute in either a RADIUS request or >>> response >>> >>message." >>> > >>> >Ok. >>>=20 >>> Just pedalling back here. Owing to the length constraint of RADIUS >>attributes, >>> we will generally need to fragment the SAML message across multiple >>>SAML- >>> Message attributes within the RADIUS message. >> >>Yes you are right it can be fragmented, is there a way to say that you >>can >>only have one "unfragmented attribute" in a "logical message"? > >It says that already in section 4.2, in the context of the Binding: "The >SAML responder MUST NOT include more > than one SAML response". Just to clarify, I believe that text says this implicitly. Obviously we can certainly can call it out more explicitly if you think that would help. Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Wed Oct 3 03:58:03 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B7421F8652 for ; Wed, 3 Oct 2012 03:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqmaMzZyVNfq for ; Wed, 3 Oct 2012 03:58:03 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1A55021F865B for ; Wed, 3 Oct 2012 03:58:02 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7A70220C7163_6C1A39B; Wed, 3 Oct 2012 10:58:01 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 43FCF20C7100_6C1A39F; Wed, 3 Oct 2012 10:58:01 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Wed, 3 Oct 2012 11:58:00 +0100 From: Josh Howlett To: Stephen Farrell , Sam Hartman Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt Thread-Index: AQHNAEeuQDxs1CsWJEGtnzqtiGQZ65Zq22SAgTrL24CAAFQIgIABM34AgAA7iHz///NUgIABPO2A Date: Wed, 3 Oct 2012 10:57:59 +0000 Message-ID: In-Reply-To: <506B1057.90201@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <88513C084E49ED4F802C8BDFD691E9A4@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 10:58:03 -0000 I agree that is an option; and it wouldn't be the end of the world if that's where we end up. But I believe it would impede interoperable deployments because it defers this discussion to implementers and users who won't, on the whole, care about or understand the issues. I would prefer to have a simple interoperable solution that works for 99% of the users than a less constrained but accordingly more complex solution that satisfies the remaining 1%. (This is, as I understand it, the reason why the SAML community ended up with the 'Metadata Interoperability Profile'; which constrains the possible expressible trust semantics of SAML 2.0 federation metadata to facilitate interop). Josh. On 02/10/2012 17:03, "Stephen Farrell" wrote: > >I had a quick look at the -03 draft and I'm confused. > >Are "ignore signatures is the MUST implement" and >"MUST NOT sign" the only real options? > >For example, I don't get why "IdP MAY sign + >RP is NOT REQUIRED to verify signature + >RP MUST implement signature verification" >is not an option. (Assuming you add text that >justifies why hop-by-hop integrity is ok.) > >Note: I'm not saying that the above is what >you ought do, I'm saying I don't get why its >not possible. > >S. > >On 10/02/2012 04:47 PM, Sam Hartman wrote: >> OK, I'm with Josh. This is going to be one of those cases where digging >> in heals now and saying MUST NOT sign will save us political grief >> later. A lot of people like Stephen are going to look at ignore >> signatures and complain, where as they would be more willing to accept >> that we're simply not using per-message signatures at all. It's >> unfortunate because I do think there ar situations where signatures are >> valuable. However, I'm imagining that we're going to be having this >> argument again and again and again and it just won't be worth the cost. >>=20 >>=20 Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From stephen.farrell@cs.tcd.ie Wed Oct 3 04:11:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6DF21F86B7 for ; Wed, 3 Oct 2012 04:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKLgRqvDV5mi for ; Wed, 3 Oct 2012 04:11:45 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 59AD721F86B5 for ; Wed, 3 Oct 2012 04:11:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6B981104243; Wed, 3 Oct 2012 12:11:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1349262702; bh=bhxBXgEEct42U8 2uKDearka0pHxmH0ffhQ4ysze6NVU=; b=ns+aPgjpeZlBEt7xPnLmA4+52f/uh2 t8n+JQGPI/rH/xpRBy4UiC7XfD4qbFIqRrNxEjPGKZLC3c0HX9jy/9EOPboboPAM gsizPCFnS3khp/60s6SjixZhwNxZTCbyz6OTrhQw/qed327ddnc81AiYa2movWpz /YqRFYt1JTKn3gyxE2VML96+fAWFqhlntvinORyapikgddVxHqGkfP7OZcrR8BT7 7PaHrZYrqcNq6UkINoyy9zBerzuikukiy4KTjj7zf5hF3NCcpn+v/LcH8m/4ImNv t6Ve1v3CJGP3Ka5EfxJ2TE5dPnBBuGT312XXddvSOisP+IZ0yfgEN9YA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id hpB96wGyEAsP; Wed, 3 Oct 2012 12:11:42 +0100 (IST) Received: from [IPv6:2001:770:10:203:ad9d:b359:c29a:1743] (unknown [IPv6:2001:770:10:203:ad9d:b359:c29a:1743]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A495D104242; Wed, 3 Oct 2012 12:11:39 +0100 (IST) Message-ID: <506C1D6C.4000407@cs.tcd.ie> Date: Wed, 03 Oct 2012 12:11:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 11:11:55 -0000 On 10/03/2012 11:57 AM, Josh Howlett wrote: > I agree that is an option; and it wouldn't be the end of the world if > that's where we end up. Ok, good. (I mean its good that I'm not entirely misunderstanding what's possible, I do not mean that the option I described below is necessarily good.) > But I believe it would impede interoperable > deployments because it defers this discussion to implementers and users > who won't, on the whole, care about or understand the issues. I don't get that. Do you mean that the presence of the signature and signature-verification code would lead implementers to throw an exception if they don't have the right keys to verify the signature? Surely that'd depend on what you tell them, e.g. whether you say they SHOULD or MAY verify the signature and about the consequences (or lack thereof) of not verifying the signature. And all of these options seem to depend on having a good argument that hop-by-hop integrity is ok. Is that already written down somewhere? If not, it'll need to be. (I keep harping on about that because I worry that hop-by-hop may turn out to only be ok in some use-cases/deployments.) > I would > prefer to have a simple interoperable solution that works for 99% of the > users than a less constrained but accordingly more complex solution that > satisfies the remaining 1%. #include // :-) S > > (This is, as I understand it, the reason why the SAML community ended up > with the 'Metadata Interoperability Profile'; which constrains the > possible expressible trust semantics of SAML 2.0 federation metadata to > facilitate interop). > > Josh. > > On 02/10/2012 17:03, "Stephen Farrell" wrote: > >> >> I had a quick look at the -03 draft and I'm confused. >> >> Are "ignore signatures is the MUST implement" and >> "MUST NOT sign" the only real options? >> >> For example, I don't get why "IdP MAY sign + >> RP is NOT REQUIRED to verify signature + >> RP MUST implement signature verification" >> is not an option. (Assuming you add text that >> justifies why hop-by-hop integrity is ok.) >> >> Note: I'm not saying that the above is what >> you ought do, I'm saying I don't get why its >> not possible. >> >> S. >> >> On 10/02/2012 04:47 PM, Sam Hartman wrote: >>> OK, I'm with Josh. This is going to be one of those cases where digging >>> in heals now and saying MUST NOT sign will save us political grief >>> later. A lot of people like Stephen are going to look at ignore >>> signatures and complain, where as they would be more willing to accept >>> that we're simply not using per-message signatures at all. It's >>> unfortunate because I do think there ar situations where signatures are >>> valuable. However, I'm imagining that we're going to be having this >>> argument again and again and again and it just won't be worth the cost. >>> >>> > > > Janet is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > > > From hartmans@painless-security.com Wed Oct 3 06:04:37 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B56621F84C2 for ; Wed, 3 Oct 2012 06:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.366 X-Spam-Level: **** X-Spam-Status: No, score=4.366 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKZZUnPalXh6 for ; Wed, 3 Oct 2012 06:04:37 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8A721F845F for ; Wed, 3 Oct 2012 06:04:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 789D620183; Wed, 3 Oct 2012 09:04:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 23955414A; Wed, 3 Oct 2012 09:04:27 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Wed, 03 Oct 2012 09:04:27 -0400 In-Reply-To: (Josh Howlett's message of "Wed, 3 Oct 2012 10:57:59 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 13:04:37 -0000 >>>>> "Josh" == Josh Howlett writes: Josh> I agree that is an option; and it wouldn't be the end of the Josh> world if that's where we end up. But I believe it would impede Josh> interoperable deployments because it defers this discussion to Josh> implementers and users who won't, on the whole, care about or Josh> understand the issues. I would prefer to have a simple Josh> interoperable solution that works for 99% of the users than a Josh> less constrained but accordingly more complex solution that Josh> satisfies the remaining 1%. IDP MAY sign + RP MAY ignore + RP MUSt verify doesn't meet the IETf's interoperability criteria because an IDP that does not support signatures cannot work with an RP that requires them. A solution that depends on verifying signatures as the MTI is the wrong approach because we don't plan to have trust anchors in common. We don't believe there is a viable strategy for having trust anchors in common in our deployments and are going to a lot of effort to avoid needing that. for my part, I've worked with a number of potential customers and prepared Moonshot related proposals for two. In both those situtaions, shared trust anchors were not an option. So, I would not support a MTI strategy that depended on shared trust anchors. --Sam From hartmans@painless-security.com Wed Oct 3 07:17:22 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9A921F84D5 for ; Wed, 3 Oct 2012 07:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.363 X-Spam-Level: **** X-Spam-Status: No, score=4.363 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix7gH5rbVieC for ; Wed, 3 Oct 2012 07:17:21 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id CEA2A21F84D1 for ; Wed, 3 Oct 2012 07:17:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F175C20183; Wed, 3 Oct 2012 09:58:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6A06F414A; Wed, 3 Oct 2012 09:58:46 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <506C1D6C.4000407@cs.tcd.ie> Date: Wed, 03 Oct 2012 09:58:46 -0400 In-Reply-To: <506C1D6C.4000407@cs.tcd.ie> (Stephen Farrell's message of "Wed, 03 Oct 2012 12:11:40 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 14:17:22 -0000 So, I'm a bit confused why we're discussing whether hop-by-hop integrity is good enough. That's been how RADIUS handles integrity for authorization attributes all along. Why does describing authorization in terms of XML make that different than authorization described in native RADIUS attributes? No confidentiality and too many proxies is posing a problem for some usecases that we're looking at deploying. I'm looking to RADSEC as a solution to that for my clients. SAML signatures would not help with the confidentiality issues. Also, since most of what I'd like to make confidential is in RADIUS attributes not SAML, xml encryption wouldn't help either. --Sam From Josh.Howlett@ja.net Wed Oct 3 07:30:43 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6729A21F859C for ; Wed, 3 Oct 2012 07:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpfqT1p8RvMf for ; Wed, 3 Oct 2012 07:30:43 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id CF09E21F84F2 for ; Wed, 3 Oct 2012 07:30:42 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id BB0391A9B08A_6C4C11B; Wed, 3 Oct 2012 14:30:41 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 90E711A9A2B9_6C4C11F; Wed, 3 Oct 2012 14:30:41 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Wed, 3 Oct 2012 15:30:41 +0100 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt Thread-Index: AQHNAEeuQDxs1CsWJEGtnzqtiGQZ65Zq22SAgTrL24CAAFQIgIABM34AgAA7iHz///NUgIABPO2AgAA0u/KAAAazgA== Date: Wed, 3 Oct 2012 14:30:41 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <74F054CC3F863A488C1BC5367E7D7739@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 14:30:43 -0000 > > Josh> I agree that is an option; and it wouldn't be the end of the > Josh> world if that's where we end up. But I believe it would impede > Josh> interoperable deployments because it defers this discussion to > Josh> implementers and users who won't, on the whole, care about or > Josh> understand the issues. I would prefer to have a simple > Josh> interoperable solution that works for 99% of the users than a > Josh> less constrained but accordingly more complex solution that > Josh> satisfies the remaining 1%. > >IDP MAY sign + RP MAY ignore + RP MUSt verify doesn't meet the IETf's >interoperability criteria because an IDP that does not support >signatures cannot work with an RP that requires them. I agree. I thought Stephen's suggestion was IdP MAY sign + RP MAY verify. This at least gets you interoperability, in the absence of a common TA, if the RP chooses not to verify the signature (if any). >So, I would not support a MTI strategy that depended on shared trust >anchors. Agreed. Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From stephen.farrell@cs.tcd.ie Wed Oct 3 07:30:48 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC5A21F8639 for ; Wed, 3 Oct 2012 07:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0z5TaTf+Msqo for ; Wed, 3 Oct 2012 07:30:47 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id AAAB621F85F4 for ; Wed, 3 Oct 2012 07:30:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A156D171473; Wed, 3 Oct 2012 15:30:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1349274645; bh=dv6lIt3R3ZXjdZ 2CFOqJeTaC7gt39uwT9OLp9+mkRsE=; b=3BbDd99TRpnjWtGqJ+4/Bp6eDxe0+X JQq6H4kbR2x/t8Z7MMiv9vEkArFOo0Tui+gFD+R+DC3qFnDd3/BfSvOhcA24GsOQ 509k5x0TVe6RYDXgNlAeiAOpLidVFQIvrUR0/9FlQR7PNx+gHGFNPYRjyKYcFhkI bCEJSlBD+5XIsh/ouYojWs73T8ELZUUsFeILQlQ5gkMswyybIp0l98TPnTftjXft KHWLYysWWTqjNqqSPg/u2zaoR5umRnjl/WdxtH8SNXf3/E+8ZQzh1BktcW87KkLa vuXYsRBGuPuipG94/Itqg7xr74ewHKAznJn/kAUeMK2ECsE5wKvyheDQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 17GsEgXcIaY1; Wed, 3 Oct 2012 15:30:45 +0100 (IST) Received: from [IPv6:2001:770:10:203:ad9d:b359:c29a:1743] (unknown [IPv6:2001:770:10:203:ad9d:b359:c29a:1743]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A4445171477; Wed, 3 Oct 2012 15:30:43 +0100 (IST) Message-ID: <506C4C14.10205@cs.tcd.ie> Date: Wed, 03 Oct 2012 15:30:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Sam Hartman References: <506C1D6C.4000407@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 14:30:48 -0000 On 10/03/2012 02:58 PM, Sam Hartman wrote: > So, I'm a bit confused why we're discussing whether hop-by-hop integrity > is good enough. I guess its at minimum a reaction to ignoring a signature. It may well be ok, but I think it needs justifying, if the WG go this way. > That's been how RADIUS handles integrity for authorization attributes > all along. Sure. Diameter too. > Why does describing authorization in terms of XML make that different > than authorization described in native RADIUS attributes? The encoding (XML vs. AVPs) doesn't make any difference. The difference is that in principle an RP could verify the SAML assertion signature and get e2e integrity, (if it had the right keys) whereas that's not currently possible for RADIUS or Diameter. That seems like a change to the usual SAML trust model, isn't it? So I'm really asking that it be justified explicitly if the WG are taking this route. Stating the equivalence with RADIUS almost does that. I guess what remains to be said is that the SAML assertion attributes (if that's the right term) that'll be used by abfab are always ok to use with just hop-by-hop integrity. I'm guessing that'll be the case, but I don't know. > No confidentiality and too many proxies is posing a problem for some > usecases that we're looking at deploying. I'm looking to RADSEC as a > solution to that for my clients. SAML signatures would not help with the > confidentiality issues. Also, since most of what I'd like to make > confidential is in RADIUS attributes not SAML, xml encryption wouldn't > help either. Sure. S. > > > --Sam > > From stephen.farrell@cs.tcd.ie Wed Oct 3 07:36:24 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7343E21F8652 for ; Wed, 3 Oct 2012 07:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1D7BTP-rC5zd for ; Wed, 3 Oct 2012 07:36:23 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A757F21F84F6 for ; Wed, 3 Oct 2012 07:36:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7E994171477; Wed, 3 Oct 2012 15:36:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1349274979; bh=q3nebR39obK822 rBETyaokN2S1kM+QceEL1aFgYUQIU=; b=CLQRF3m9TzF/lBpCPbRSEAWgy974I8 +FJExuPAVDa2ys2BeFkZx++Vo+SkaM3MLyDEVbmD2LYV89p2D9mkNy1elbIWwKKh EbuvkQ4k3HHnlDkfXv2OmQephgtUhCcrxkTwSF9Va2g3+7Ilroh+BFCvk3FdDxLe rQY8xb3yH8lmASSt7trghB58Dw2mue3KbMZBiE+CCjXXTZ5TgtanRjz0DcCzuRcW RKHK+Zy67ebj/J6OETgfu43VVejOJp4mAKIqwh+nbQfUwx1jmVBQJ8f4hj/uaSo3 ItRxyr4np8N4Oa2K8HA1tDT/cEMdfxppbm5Vg7V5mbK6TRW2PWRA43ZQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id EuKFrrjfHeBm; Wed, 3 Oct 2012 15:36:19 +0100 (IST) Received: from [IPv6:2001:770:10:203:ad9d:b359:c29a:1743] (unknown [IPv6:2001:770:10:203:ad9d:b359:c29a:1743]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C3860171473; Wed, 3 Oct 2012 15:36:18 +0100 (IST) Message-ID: <506C4D63.6040801@cs.tcd.ie> Date: Wed, 03 Oct 2012 15:36:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 14:36:24 -0000 On 10/03/2012 03:30 PM, Josh Howlett wrote: >> >> Josh> I agree that is an option; and it wouldn't be the end of the >> Josh> world if that's where we end up. But I believe it would impede >> Josh> interoperable deployments because it defers this discussion to >> Josh> implementers and users who won't, on the whole, care about or >> Josh> understand the issues. I would prefer to have a simple >> Josh> interoperable solution that works for 99% of the users than a >> Josh> less constrained but accordingly more complex solution that >> Josh> satisfies the remaining 1%. >> >> IDP MAY sign + RP MAY ignore + RP MUSt verify doesn't meet the IETf's >> interoperability criteria because an IDP that does not support >> signatures cannot work with an RP that requires them. > > I agree. I thought Stephen's suggestion was IdP MAY sign + RP MAY verify. > This at least gets you interoperability, in the absence of a common TA, if > the RP chooses not to verify the signature (if any). Sam clarified his take on the above for me offlist. He's concerned that the option I wrote down would allow an RP implementation that insisted on always checking signatures and didn't offer the option to not verify some or all signatures. I agree that if its ok to not check some signatures then its also ok to dis-allow implementations that insist on checking all signatures. I'm not so sure that's the same as saying that ignoring signatures is *the* MTI though. You could also make the ability to check signatures MTI. (Again, I'm not saying such an option is right, I'm still trying to understand this stuff.) S. > >> So, I would not support a MTI strategy that depended on shared trust >> anchors. > > Agreed. > > Josh. > > > > Janet is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > > > From hartmans@painless-security.com Wed Oct 3 07:47:22 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58A821F86B4 for ; Wed, 3 Oct 2012 07:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.361 X-Spam-Level: **** X-Spam-Status: No, score=4.361 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NC5-HbhPyUJt for ; Wed, 3 Oct 2012 07:47:22 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4E19F21F8546 for ; Wed, 3 Oct 2012 07:47:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 501E32033A; Wed, 3 Oct 2012 10:37:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CF6AF414A; Wed, 3 Oct 2012 10:38:00 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <506C1D6C.4000407@cs.tcd.ie> <506C4C14.10205@cs.tcd.ie> Date: Wed, 03 Oct 2012 10:38:00 -0400 In-Reply-To: <506C4C14.10205@cs.tcd.ie> (Stephen Farrell's message of "Wed, 03 Oct 2012 15:30:44 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 14:47:23 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> On 10/03/2012 02:58 PM, Sam Hartman wrote: >> So, I'm a bit confused why we're discussing whether hop-by-hop >> integrity is good enough. Stephen> I guess its at minimum a reaction to ignoring a signature. Stephen> It may well be ok, but I think it needs justifying, if the Stephen> WG go this way. I'd like to push back on this reaction in the strongest possible terms. The idea that it's bad to ignore a signature, but it would be acceptable to not have a signature at all decreases the value of signatures. It means that by adding a signature we decrease interoperability. However if the RP would accept an unsigned object, we gain no security advantage. I'd like to ask you to think about whether that reaction--the negative response to ignoring a signature--is ever appropriate in a case where the signature is optional. If so I'd like to understand why. --Sam From hartmans@painless-security.com Wed Oct 3 07:52:22 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D977621F864D for ; Wed, 3 Oct 2012 07:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.359 X-Spam-Level: **** X-Spam-Status: No, score=4.359 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neSt6O-TzR-c for ; Wed, 3 Oct 2012 07:52:21 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id D0AC421F8667 for ; Wed, 3 Oct 2012 07:52:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0181520289; Wed, 3 Oct 2012 10:34:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 653B9414A; Wed, 3 Oct 2012 10:34:28 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Wed, 03 Oct 2012 10:34:28 -0400 In-Reply-To: (Josh Howlett's message of "Wed, 3 Oct 2012 14:30:41 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 14:52:23 -0000 >>>>> "Josh" == Josh Howlett writes: >> Josh> I agree that is an option; and it wouldn't be the end of the Josh> world if that's where we end up. But I believe it would impede Josh> interoperable deployments because it defers this discussion to Josh> implementers and users who won't, on the whole, care about or Josh> understand the issues. I would prefer to have a simple Josh> interoperable solution that works for 99% of the users than a Josh> less constrained but accordingly more complex solution that Josh> satisfies the remaining 1%. >> >> IDP MAY sign + RP MAY ignore + RP MUSt verify doesn't meet the >> IETf's interoperability criteria because an IDP that does not >> support signatures cannot work with an RP that requires them. Josh> I agree. I thought Stephen's suggestion was IdP MAY sign + RP Josh> MAY verify. This at least gets you interoperability, in the Josh> absence of a common TA, if the RP chooses not to verify the Josh> signature (if any). >From a purely process point of view IDP MAY sign and RP MAY verify doesn't interop. MAY means just that; the RP is permitted to verify. I.E. I can ship an RP that always verifies. From stephen.farrell@cs.tcd.ie Wed Oct 3 08:01:08 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF5D21F8554 for ; Wed, 3 Oct 2012 08:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VskHLGrUip-N for ; Wed, 3 Oct 2012 08:01:07 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 47B7921F846C for ; Wed, 3 Oct 2012 08:01:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A59C8171477; Wed, 3 Oct 2012 16:01:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1349276466; bh=rGJGvQV9GSSlkV 7CNk5+ruc73yTrubzj4enX8q+8OVY=; b=2gM9sQDhKgp/hzfM6qmi1GbFgE6CuY HlAPFmoHxTQJ90WTM/CPk65nvoRcnOgl2GEWLUqwlbSNWE+12N+0NcaLfym5jWO1 PAFOKy6bDFObEOd00sqcSeA07zFLOGZAzQKxjvdTHlahrDhd9x4T8/zm7mXq8WB2 T7/05N1laXhNpE2uAgfirZkXHmfA8Vlv6UIOI23bWsLr66h1OvJ+fxc9dmp58/Rs fK92HJrKJHz6yT9+AQK+STZYbyR5Qf94tqpgVx64j/Yat4Hb7nP3VtlsBLJp1/Gd AN/e2pSLFvYfvrXegqSj2oKWbxFAWSSeSsKI2lPNzQfOgmjcBCR4E3/Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id LG1NH7linXTQ; Wed, 3 Oct 2012 16:01:06 +0100 (IST) Received: from [IPv6:2001:770:10:203:ad9d:b359:c29a:1743] (unknown [IPv6:2001:770:10:203:ad9d:b359:c29a:1743]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1677B171473; Wed, 3 Oct 2012 16:01:06 +0100 (IST) Message-ID: <506C5332.7090001@cs.tcd.ie> Date: Wed, 03 Oct 2012 16:01:06 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Sam Hartman References: <506C1D6C.4000407@cs.tcd.ie> <506C4C14.10205@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:01:08 -0000 On 10/03/2012 03:38 PM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Farrell writes: > > Stephen> On 10/03/2012 02:58 PM, Sam Hartman wrote: > >> So, I'm a bit confused why we're discussing whether hop-by-hop > >> integrity is good enough. > > Stephen> I guess its at minimum a reaction to ignoring a signature. > Stephen> It may well be ok, but I think it needs justifying, if the > Stephen> WG go this way. > > I'd like to push back on this reaction in the strongest possible terms. Push away. But note that my reaction has not been to say "don't do that" - I'm saying "justify that." Note also that we're moving away from abfab-specific things to generalities. > The idea that it's bad to ignore a signature, but it would be acceptable > to not have a signature at all decreases the value of signatures. Perhaps. Or maybe its that optionally-signed things decrease the value of signatures when those are present compared to always-signed things. > It > means that by adding a signature we decrease interoperability. That's definitely true. Adding any crypto decreases interop. > However > if the RP would accept an unsigned object, we gain no security > advantage. An RP could choose depending on the to-be-signed/unsigned value(s) and get a security advantage. For example, something along the lines of being ok with "local" stuff not being signed on the assumption that some border node will already have prevented a bad version of that arriving, but treating non-local signed or unsigned things differently. (For some definition of "local.") > I'd like to ask you to think about whether that reaction--the negative > response to ignoring a signature--is ever appropriate in a case where > the signature is optional. If so I'd like to understand why. I think it can be appropriate sometimes as per the above. Cheers, S. > > --Sam > > From kwiereng@cisco.com Wed Oct 3 08:07:05 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3C321F8593 for ; Wed, 3 Oct 2012 08:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL5gLA2a6Vkw for ; Wed, 3 Oct 2012 08:07:05 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1572B21F84CF for ; Wed, 3 Oct 2012 08:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1430; q=dns/txt; s=iport; t=1349276825; x=1350486425; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jJru2J/lmJ2quovuyGeOLtallrZJm/5RUoZXBRYO2lg=; b=Uhp8PZLMwSjVLXmgThIzehp3U188VPCRbwLE6PHrSe2XSCVW/vi0mVO3 rZjloy6nlf2i83aTSU5PHl5Bgkv7PQcky2Wo7Za7ZxZbVxOgSrnIG8njn USg0LRwogkULRHRJmcbcDvWEnJTAZDbg5SX9c4WJUQ4LW1jqNrvtGEec5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAK5TbFCtJV2c/2dsb2JhbABFvnOBCIIgAQEBAwESASc/BQsCAQgiFBAyJQIEDg0TB4ddBpdyoAWLI4VaYAOkK4Fpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="127907211" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 03 Oct 2012 15:07:04 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q93F743f023932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Oct 2012 15:07:04 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.113]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 10:07:04 -0500 From: "Klaas Wierenga (kwiereng)" To: Sam Hartman Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt Thread-Index: AQHNAEeuQDxs1CsWJEGtnzqtiGQZ65Zq22SAgTrL24CAALidgIABM4aA///WhEaAAFhQgIABPPKAgAAD0wD//+AYpoAAYasA Date: Wed, 3 Oct 2012 15:07:03 +0000 Message-ID: <7E1636E02F313F4BA69A428B314B77C7081E8F1E@xmb-aln-x12.cisco.com> References: <506C1D6C.4000407@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.240.198] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19234.001 x-tm-as-result: No--31.182000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:07:06 -0000 On Oct 3, 2012, at 3:58 PM, Sam Hartman wrote: Sam, > So, I'm a bit confused why we're discussing whether hop-by-hop integrity > is good enough. > That's been how RADIUS handles integrity for authorization attributes > all along. > Why does describing authorization in terms of XML make that different > than authorization described in native RADIUS attributes? >=20 > No confidentiality and too many proxies is posing a problem for some > usecases that we're looking at deploying. I'm looking to RADSEC as a > solution to that for my clients. SAML signatures would not help with the > confidentiality issues. Also, since most of what I'd like to make > confidential is in RADIUS attributes not SAML, xml encryption wouldn't > help either. I think Stephen raises a valid point. Just pointing to the RADIUS hop-by-ho= p protection is a bit weak, after all there is potentially a lot more autho= rization data going over the wire compared to the simple network access cas= e. I think it is fine to call out the hop-by-hop behaviour and, as you ment= ion above, state that if you want direct peer to peer connections you'll ha= ve to do RadSec. Don't you think that that would decrease the likelihood of= ill thought through deployments? I have seen a couple of weird uses of the= eduroam trust fabric (not looking at you Josh ;-), so a bit of discussion = around this topic would help. Klaas= From hartmans@painless-security.com Wed Oct 3 08:11:16 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D312E21F8680 for ; Wed, 3 Oct 2012 08:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.357 X-Spam-Level: **** X-Spam-Status: No, score=4.357 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XjE4P+hQtGa for ; Wed, 3 Oct 2012 08:11:16 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5D55621F867A for ; Wed, 3 Oct 2012 08:11:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2B0E720183; Wed, 3 Oct 2012 11:11:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 606DD414A; Wed, 3 Oct 2012 11:11:06 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <506C1D6C.4000407@cs.tcd.ie> <506C4C14.10205@cs.tcd.ie> <506C5332.7090001@cs.tcd.ie> Date: Wed, 03 Oct 2012 11:11:06 -0400 In-Reply-To: <506C5332.7090001@cs.tcd.ie> (Stephen Farrell's message of "Wed, 03 Oct 2012 16:01:06 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:11:16 -0000 OK. Let me rephrase. I claim for a given message the following reactions are reasonable: 1) require signature 2) ignore any present signature and that 3) verify if present and fail if verified is unreasonable. It may be that verify if present and tell a human what verification yielded is sometimes helpful but I'm dubious. Are you arguing for 3? Or are you arguing that we should add a new security requirement to RADIUS that there are some messages that MUST be signed? From hartmans@painless-security.com Wed Oct 3 08:42:21 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DEC21F84EA for ; Wed, 3 Oct 2012 08:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.356 X-Spam-Level: **** X-Spam-Status: No, score=4.356 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGgUJEQfoQV9 for ; Wed, 3 Oct 2012 08:42:21 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 751CB21F84AE for ; Wed, 3 Oct 2012 08:42:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1764A20183; Wed, 3 Oct 2012 11:33:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0A88D414A; Wed, 3 Oct 2012 11:33:07 -0400 (EDT) From: Sam Hartman To: "Klaas Wierenga \(kwiereng\)" References: <506C1D6C.4000407@cs.tcd.ie> <7E1636E02F313F4BA69A428B314B77C7081E8F1E@xmb-aln-x12.cisco.com> Date: Wed, 03 Oct 2012 11:33:07 -0400 In-Reply-To: <7E1636E02F313F4BA69A428B314B77C7081E8F1E@xmb-aln-x12.cisco.com> (Klaas Wierenga's message of "Wed, 3 Oct 2012 15:07:03 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:42:22 -0000 >>>>> "Klaas" == Klaas Wierenga (kwiereng) writes: Klaas> I think Stephen raises a valid point. Just pointing to the Klaas> RADIUS hop-by-hop protection is a bit weak, after all there Klaas> is potentially a lot more authorization data going over the Klaas> wire compared to the simple network access case. I think it Klaas> is fine to call out the hop-by-hop behaviour and, as you Klaas> mention above, state that if you want direct peer to peer Klaas> connections you'll have to do RadSec. Don't you think that Klaas> that would decrease the likelihood of ill thought through Klaas> deployments? I have seen a couple of weird uses of the Klaas> eduroam trust fabric (not looking at you Josh ;-), so a bit Klaas> of discussion around this topic would help. I'm all for security considerations text. Heck, I'm all for MTI RADSEC if we could find a process way to do it. --Sam From stephen.farrell@cs.tcd.ie Wed Oct 3 08:51:50 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3D421F84F8 for ; Wed, 3 Oct 2012 08:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-p66FtcPy8I for ; Wed, 3 Oct 2012 08:51:50 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 67A4121F84F6 for ; Wed, 3 Oct 2012 08:51:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 52A4617147A; Wed, 3 Oct 2012 16:51:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1349279507; bh=NV5uu6c6jpR42N 7wmN1g+xFz5bxmgtqmrozwM9jX5UA=; b=cr9BSeXCbKLj6oFdTOPmy3ohIgFxIE DUoDqopwQvDsoqxf6Rc5UL6z09dzMhnIojbtFgFARNBfB38/Kx0Iq/CFLDPCIc4s q+54CosNqDHc0Fr+tJAQJbJBtOAZDFr+s0ksdjhhr8coFF5gCE/6DCCV4Dkcbi9m z0bStG32vPn+832PFWpJu4sAGUIKSh1oyUXavZRlwtid/ouoccL38nqeeDy61bQ8 tZbKBseS0rBJe7kUyO3H7eH2FgLeLDExY04jhotLxArZgqR5lYi3zx3ggw7fatOR hyyxbBPQYRsyNIqhpYXAYJjFArKZd9V5ElmSl52D6Vk4fyAY1Bh0GSMg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id a5MdabN0EH9E; Wed, 3 Oct 2012 16:51:47 +0100 (IST) Received: from [IPv6:2001:770:10:203:ad9d:b359:c29a:1743] (unknown [IPv6:2001:770:10:203:ad9d:b359:c29a:1743]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CFC57171473; Wed, 3 Oct 2012 16:51:47 +0100 (IST) Message-ID: <506C5F14.9030303@cs.tcd.ie> Date: Wed, 03 Oct 2012 16:51:48 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Sam Hartman References: <506C1D6C.4000407@cs.tcd.ie> <506C4C14.10205@cs.tcd.ie> <506C5332.7090001@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:51:51 -0000 Hiya, On 10/03/2012 04:11 PM, Sam Hartman wrote: > OK. > Let me rephrase. > > I claim for a given message the following reactions are reasonable: I'm assuming we're talking generalities here and not just about abfab. > > 1) require signature > 2) ignore any present signature > > and that > > 3) verify if present and fail if verified > is unreasonable. Did you mean: 3) verify if present and fail transaction if not good-signature but handle transaction if no signature present as if a good signature was present If so, yes that'd almost certainly be unreasonable. > It may be that verify if present and tell a human what verification > yielded is sometimes helpful but I'm dubious. > > Are you arguing for 3? I'm arguing that in general (perhaps not for abfab, not sure), your three choices are too binary:-) Signature checking can fail for various reasons (hash compare fails, wrong key, don't have key, don't have path for key, revocation, naming, ...) and the reaction to failure of a signature check can also vary (fail the transaction, subject transaction to more checks as in DKIM, re-route transaction, log the transaction somewhere special, ...). The appropriate reaction to not being able to verify a signature on a signed message can reasonably be different to the reaction to an unsigned message. For example, if I were using key continuity, then the first time I see a signed thing I might allow the transaction even though I've no good reason to accept the public key. But the 2nd time different checks will apply, with possibly different results. For example, I might start rejecting transactions that claim to be from that source but don't have signatures that verify with the key I saw on the first signed transaction from that source. And again, the above are generalities. I'm not saying how the argument might or might not apply to abfab. (And I think we've wandered off topic somewhat.) > Or are you arguing that we should add a new security requirement to > RADIUS that there are some messages that MUST be signed? No, I've made no argument about RADIUS at all. S. > > From stephen.farrell@cs.tcd.ie Wed Oct 3 09:03:52 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E5C21F8470 for ; Wed, 3 Oct 2012 09:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faLyns2a4Fgf for ; Wed, 3 Oct 2012 09:03:51 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8B321F846E for ; Wed, 3 Oct 2012 09:03:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 76E31171477; Wed, 3 Oct 2012 17:03:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1349280230; bh=qUxsfUaJG8DZjs Y+q+oHcnPcO8R1+Y6uv6kObI2Eh6M=; b=hjD1bN9adYiW51tgnU5AtuGvdO8Xva TWVG6l9ASaS5z7wawFe0XgvPxbdG9pcuPOG+8NCwnYWAqLMPXXsp/QAcNn+sSNbx jufJgQRBGClQQGj8NG2KdIAzd5shZK8ZgmgiQ0mJ3ahVmYvcQYTdV08L6xd7szRa i6pFi1ubDN9n7g0gfwUV7vh7N7uwQd+DghvyEDPIBu/5CzeQTKL1zwYv4m3xlhp8 DCu+NKqgld0ZAmilkZblmZSROXlCqq/NoTqyhTd1ttcVSwQTIrW9P3dcGAWsrzUM 3gAlKqXjzfTLa7eyv5VzzCvRwPn7B2fBhhSNPGHATxvHo6uS1vx6Schg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 6iQk3vH2xQvL; Wed, 3 Oct 2012 17:03:50 +0100 (IST) Received: from [IPv6:2001:770:10:203:ad9d:b359:c29a:1743] (unknown [IPv6:2001:770:10:203:ad9d:b359:c29a:1743]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 048AE171473; Wed, 3 Oct 2012 17:03:50 +0100 (IST) Message-ID: <506C61E6.5070703@cs.tcd.ie> Date: Wed, 03 Oct 2012 17:03:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Sam Hartman References: <506C1D6C.4000407@cs.tcd.ie> <506C4C14.10205@cs.tcd.ie> <506C5332.7090001@cs.tcd.ie> <506C5F14.9030303@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:03:52 -0000 On 10/03/2012 04:56 PM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Farrell writes: > > > Stephen> 3) verify if present and fail transaction if not > Stephen> good-signature but handle transaction if no signature > Stephen> present as if a good signature was present > > Stephen> If so, yes that'd almost certainly be unreasonable. > > Yes that is what I meant. > > I've been interpreting your request in the ABFAB context as a request > for exactly that. It wasn't. > If that isn't what you've been asking us to consider I'd like to > understand better > > 1) What you're asking for specifically The justification for why its safe to ignore a signature, when one is present that could, in principle, be verified and thus provide e2e integrity/origin-authentication for the attributes extracted from the signed SAML assertion. Stating that its hard to get the right keys in the right places explains your design choice but doesn't communicate why that design is a safe one. > 2) Why the departure from the standard RADIUS assumptions about > integrity and authorization is justified. I'm asking that you justify the departure from the standard SAML assumptions about assertions that are signed by an IdP. S. > > > From hartmans@painless-security.com Wed Oct 3 09:07:22 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B0121F8682 for ; Wed, 3 Oct 2012 09:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.354 X-Spam-Level: **** X-Spam-Status: No, score=4.354 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOR-1ZHWattu for ; Wed, 3 Oct 2012 09:07:21 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id B94B521F867B for ; Wed, 3 Oct 2012 09:07:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C8E6720183; Wed, 3 Oct 2012 11:56:56 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0FF9D414A; Wed, 3 Oct 2012 11:57:00 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <506C1D6C.4000407@cs.tcd.ie> <506C4C14.10205@cs.tcd.ie> <506C5332.7090001@cs.tcd.ie> <506C5F14.9030303@cs.tcd.ie> Date: Wed, 03 Oct 2012 11:56:59 -0400 In-Reply-To: <506C5F14.9030303@cs.tcd.ie> (Stephen Farrell's message of "Wed, 03 Oct 2012 16:51:48 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:07:22 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> 3) verify if present and fail transaction if not Stephen> good-signature but handle transaction if no signature Stephen> present as if a good signature was present Stephen> If so, yes that'd almost certainly be unreasonable. Yes that is what I meant. I've been interpreting your request in the ABFAB context as a request for exactly that. If that isn't what you've been asking us to consider I'd like to understand better 1) What you're asking for specifically 2) Why the departure from the standard RADIUS assumptions about integrity and authorization is justified. From hartmans@painless-security.com Wed Oct 3 09:27:22 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C32821F85D5 for ; Wed, 3 Oct 2012 09:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.352 X-Spam-Level: **** X-Spam-Status: No, score=4.352 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwFvcwi2hvT7 for ; Wed, 3 Oct 2012 09:27:21 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id CF43F21F85C3 for ; Wed, 3 Oct 2012 09:27:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0D3FA20183; Wed, 3 Oct 2012 12:09:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 275CC414A; Wed, 3 Oct 2012 12:09:13 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <506C1D6C.4000407@cs.tcd.ie> <506C4C14.10205@cs.tcd.ie> <506C5332.7090001@cs.tcd.ie> <506C5F14.9030303@cs.tcd.ie> <506C61E6.5070703@cs.tcd.ie> Date: Wed, 03 Oct 2012 12:09:13 -0400 In-Reply-To: <506C61E6.5070703@cs.tcd.ie> (Stephen Farrell's message of "Wed, 03 Oct 2012 17:03:50 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:27:22 -0000 >>>>> "Stephen" == Stephen Farrell writes: I'm sorry. I'm still not seeing the difference between what you're asking for and what we've both stated we see as unreasonable. I'm going to withdraw from the discussion at this point, because I don't think me stating that I'm confused more will help. From hartmans@painless-security.com Thu Oct 4 13:59:06 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD05621F85A4; Thu, 4 Oct 2012 13:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.351 X-Spam-Level: **** X-Spam-Status: No, score=4.351 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO6OSmQUSTtL; Thu, 4 Oct 2012 13:59:06 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 65B2B21F85A1; Thu, 4 Oct 2012 13:59:05 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 777D62010F; Thu, 4 Oct 2012 16:58:52 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E8F9B414A; Thu, 4 Oct 2012 16:58:53 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <20120920141717.4821.29598.idtracker@ietfa.amsl.com> <87fw6c9w97.fsf@latte.josefsson.org> Date: Thu, 04 Oct 2012 16:58:53 -0400 In-Reply-To: <87fw6c9w97.fsf@latte.josefsson.org> (Simon Josefsson's message of "Fri, 21 Sep 2012 00:15:16 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, ietf@ietf.org Subject: Re: [abfab] Last Call: (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 20:59:06 -0000 Any advice from the SAML community on responding to the following comment from Simon: If the value is not simple or is empty, then the raw value(s) of the GSS name attribute MUST be the well-formed serialization of the element(s) encoded as UTF-8. The "display" values are implementation-defined. Question: what serialization is intended here? An example here would make this more clear. From internet-drafts@ietf.org Thu Oct 4 14:23:41 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6919C21F871E; Thu, 4 Oct 2012 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrXmfU1+EG+F; Thu, 4 Oct 2012 14:23:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB5321F8711; Thu, 4 Oct 2012 14:23:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121004212340.3458.6565.idtracker@ietfa.amsl.com> Date: Thu, 04 Oct 2012 14:23:40 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-naming-06.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:23:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : Name Attributes for the GSS-API EAP mechanism Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-naming-06.txt Pages : 17 Date : 2012-10-04 Abstract: The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap-naming There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-naming-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-gss-eap-naming-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@mit.edu Thu Oct 4 14:24:56 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C128421F8726; Thu, 4 Oct 2012 14:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.792 X-Spam-Level: X-Spam-Status: No, score=-96.792 tagged_above=-999 required=5 tests=[AWL=-1.080, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjBW7ZJvARJn; Thu, 4 Oct 2012 14:24:56 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id E75F021F8718; Thu, 4 Oct 2012 14:24:55 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 522182010F; Thu, 4 Oct 2012 17:24:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A2B18414A; Thu, 4 Oct 2012 17:24:42 -0400 (EDT) From: Sam Hartman To: iesg@ietf.org,abfab@ietf.org Date: Thu, 04 Oct 2012 17:24:42 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] draft-ietf-abfab-gss-eap-naming-06 submitted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:24:56 -0000 At Stephen's request I spun a new version of draft-ietf-abfab-gss-eap-naming. This draft attempts to address Simon's comments. It also includes an update to the IANA expert assignment guidance based on an IESG review comment. --Sam From barryleiba@gmail.com Thu Oct 4 14:35:21 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1C31F0CA5; Thu, 4 Oct 2012 14:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.062 X-Spam-Level: X-Spam-Status: No, score=-103.062 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAymcxsEqOse; Thu, 4 Oct 2012 14:35:21 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 370DF1F0425; Thu, 4 Oct 2012 14:35:21 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1354950vcb.31 for ; Thu, 04 Oct 2012 14:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CoNLs4MO6tQYZp0oso2vK5x/QRbo3+qpPX4NFZ1tkIc=; b=CuSDEOAYJq1mZrnLsB4dZ/H6Bhmi4W8Toss/6K7EgJcs+ab113wud1apmsyasXzm2A RcHB9piQ+QQKgyADkbKGd6p9JYxPLIKsXY3qQ0Xh8KaQEH4SP/Wrn3iKIUtenqlFInSj nIGHxXYgVNR87OFQjll3u6dYMs7vukq4ZJ0PyMUIvTAg0t6bGukoQ59uyRf4bhFyCuRW JbD/VqzJvjYVo6ekQEhbJliNqd2VEnqnAC32JMQhwpuDHupztPECF91+j/v5vc1V2BPS siz4tiljTQJw3KH6JmfWQi1oo302R2AzbbygKwThYGZW+EiJ/M6otBhZddFUkzYjkCxq 8tPQ== MIME-Version: 1.0 Received: by 10.220.208.210 with SMTP id gd18mr3946629vcb.43.1349386520605; Thu, 04 Oct 2012 14:35:20 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.59.5.72 with HTTP; Thu, 4 Oct 2012 14:35:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Oct 2012 17:35:20 -0400 X-Google-Sender-Auth: N4kbiuI0tnAZNbFddrWTU_Mzumw Message-ID: From: Barry Leiba To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Cc: abfab@ietf.org, iesg@ietf.org Subject: Re: [abfab] draft-ietf-abfab-gss-eap-naming-06 submitted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 21:35:22 -0000 > At Stephen's request I spun a new version of > draft-ietf-abfab-gss-eap-naming. ... > It also includes an update to the IANA expert assignment > guidance based on an IESG review comment. And the text you used is perfect; thanks for addressing that with me. Barry From cantor.2@osu.edu Thu Oct 4 17:15:39 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C04F1F0425; Thu, 4 Oct 2012 17:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naS0oeuhxclw; Thu, 4 Oct 2012 17:15:38 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0C11F041F; Thu, 4 Oct 2012 17:15:38 -0700 (PDT) Received: from mail114-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 00:15:35 +0000 Received: from mail114-ch1 (localhost [127.0.0.1]) by mail114-ch1-R.bigfish.com (Postfix) with ESMTP id C59C86017D; Fri, 5 Oct 2012 00:15:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.40; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT02.osuad.osu.edu; RD:cio-krc-ht02.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: PS-4(z551bizbb2dI98dI9371I1432I1418Izz1d77h1202h1d1ah1d2ahzz8275bh8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: pass (mail114-ch1: domain of osu.edu designates 164.107.81.40 as permitted sender) client-ip=164.107.81.40; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT02.osuad.osu.edu ; suad.osu.edu ; Received: from mail114-ch1 (localhost.localdomain [127.0.0.1]) by mail114-ch1 (MessageSwitch) id 1349396133713527_13936; Fri, 5 Oct 2012 00:15:33 +0000 (UTC) Received: from CH1EHSMHS011.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail114-ch1.bigfish.com (Postfix) with ESMTP id A1C3C4000E4; Fri, 5 Oct 2012 00:15:33 +0000 (UTC) Received: from CIO-KRC-HT02.osuad.osu.edu (164.107.81.40) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 5 Oct 2012 00:15:33 +0000 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.02.0309.002; Thu, 4 Oct 2012 20:15:32 -0400 From: "Cantor, Scott" To: Sam Hartman , Simon Josefsson Thread-Topic: [abfab] Last Call: (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard Thread-Index: AQHNoo6IhaenKMaBu0KVsTWqbAugXQ== Date: Fri, 5 Oct 2012 00:15:32 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.27.107.146] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: osu.edu Cc: "abfab@ietf.org" , "ietf@ietf.org" Subject: Re: [abfab] Last Call: (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 00:15:39 -0000 On 10/4/12 4:58 PM, "Sam Hartman" wrote: >Any advice from the SAML community on responding to the following >comment from Simon: > > If the value is not simple or is empty, then the raw value(s) of the > GSS name attribute MUST be the well-formed serialization of the > element(s) encoded as UTF-8. The "display" > values are implementation-defined. > >Question: what serialization is intended here? An example here would >make this more clear. I think that was my text, possibly. I just meant that it's the XML representation of the element, but well-formed, meaning that you have to make sure any namespaces are declared, etc. so that if a parser were to parse that serialization, it would be well-formed XML. Like, say, this: 84e411ea-7daa-4a57-bbf6-b5cc52981b73 That's not a simple XML content model. So one such serialization is: 84e411ea-7daa-4a57-bbf6-b5cc52981b73 This is NOT the same as canonicalization of course. It's just well-formed and is one of many possible serializations that would meet the requirement. I suspect an example for the spec might be simpler. I just didn't have an example of a complex value to hand, other than that case. -- Scott From leifj@sunet.se Sat Oct 6 00:16:30 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687C221F866B for ; Sat, 6 Oct 2012 00:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufnNXT3cnc8L for ; Sat, 6 Oct 2012 00:16:29 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id D56F121F8650 for ; Sat, 6 Oct 2012 00:16:28 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q967GLnD012588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Oct 2012 09:16:25 +0200 (CEST) Message-ID: <506FDAC5.1000404@sunet.se> Date: Sat, 06 Oct 2012 09:16:21 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab-chairs@tools.ietf.org" Subject: [abfab] call for agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 07:16:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, Its that time again. We've seen a few documents, if not out the door, then at least pretty close. At this rate this may very well be our last meeting so if you've been sitting on an issue this is the time to bring it up or for ever wish you had. Please send us your proposed agenda items besides the usual document review and open mic. Best R Leif & Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBv2sEACgkQ8Jx8FtbMZndS5QCeODj6KXsAnvw3BwuLoR6EiF6G Tc0Ani3AFNvFx9QrKVGyLrpX22mC1t9J =OKty -----END PGP SIGNATURE----- From simon@josefsson.org Sat Oct 6 09:50:40 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F06421F84F2; Sat, 6 Oct 2012 09:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.875 X-Spam-Level: X-Spam-Status: No, score=-99.875 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id si9E7xZwVn5g; Sat, 6 Oct 2012 09:50:39 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD9621F850D; Sat, 6 Oct 2012 09:50:37 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q96GoSMw032734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 6 Oct 2012 18:50:29 +0200 From: Simon Josefsson To: "Cantor\, Scott" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:121006:abfab@ietf.org::yKaWn1UdwdRMBQmw:4uVp X-Hashcash: 1:22:121006:cantor.2@osu.edu::3uLuMcHIs5R6i2I/:7iXS X-Hashcash: 1:22:121006:ietf@ietf.org::U+m/2Hhh3eh2mMbK:H+7h X-Hashcash: 1:22:121006:hartmans@painless-security.com::yoNXcnAALj76nF8a:PoJG Date: Sat, 06 Oct 2012 18:50:27 +0200 In-Reply-To: (Scott Cantor's message of "Fri, 5 Oct 2012 00:15:32 +0000") Message-ID: <874nm7v92k.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "abfab@ietf.org" , "ietf@ietf.org" Subject: Re: [abfab] Last Call: (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 16:50:40 -0000 "Cantor, Scott" writes: > On 10/4/12 4:58 PM, "Sam Hartman" wrote: > >>Any advice from the SAML community on responding to the following >>comment from Simon: >> >> If the value is not simple or is empty, then the raw value(s) of the >> GSS name attribute MUST be the well-formed serialization of the >> element(s) encoded as UTF-8. The "display" >> values are implementation-defined. >> >>Question: what serialization is intended here? An example here would >>make this more clear. > > I think that was my text, possibly. I just meant that it's the XML > representation of the element, but well-formed, meaning that you have to > make sure any namespaces are declared, etc. so that if a parser were to > parse that serialization, it would be well-formed XML. Thanks, now I understand better. I would feel more comfortable if there were a precise reference to what "well-formed serialization" means, especially since there is a MUST here. It ought to be possible to determine algorithmically whether something conforms or not. Sometimes I get the impression that "well-formed" just refers to syntactical correctness, whereas namespace considerations are more semantic. Perhaps the text would be improved by adding a sentence between the two sentences above like this: This means, for example, that the XML code includes all necessary namespace declarations, so that a parser is able to parse and understand the meaning of the raw value. If there is a suitable reference to some XML standard, that is probably better. /Simon From cantor.2@osu.edu Sun Oct 7 11:19:39 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D0521F8714; Sun, 7 Oct 2012 11:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otZ18U5g9Uf8; Sun, 7 Oct 2012 11:19:38 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD6721F8711; Sun, 7 Oct 2012 11:19:37 -0700 (PDT) Received: from mail98-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Sun, 7 Oct 2012 18:19:36 +0000 Received: from mail98-va3 (localhost [127.0.0.1]) by mail98-va3-R.bigfish.com (Postfix) with ESMTP id DEC953C0127; Sun, 7 Oct 2012 18:19:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.43; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT03.osuad.osu.edu; RD:cio-krc-ht03.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(z551bizbb2dI98dI9371I1432I4015Izz1d77h1202h1d1ah1d2ahzz17326ah8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: pass (mail98-va3: domain of osu.edu designates 164.107.81.43 as permitted sender) client-ip=164.107.81.43; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT03.osuad.osu.edu ; suad.osu.edu ; Received: from mail98-va3 (localhost.localdomain [127.0.0.1]) by mail98-va3 (MessageSwitch) id 1349633975520260_11442; Sun, 7 Oct 2012 18:19:35 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.249]) by mail98-va3.bigfish.com (Postfix) with ESMTP id 7AC442A0044; Sun, 7 Oct 2012 18:19:35 +0000 (UTC) Received: from CIO-KRC-HT03.osuad.osu.edu (164.107.81.43) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 7 Oct 2012 18:19:35 +0000 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT03.osuad.osu.edu ([fe80::2572:c08d:8186:46a4%12]) with mapi id 14.02.0309.002; Sun, 7 Oct 2012 14:19:34 -0400 From: "Cantor, Scott" To: Simon Josefsson Thread-Topic: Last Call: (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard Thread-Index: AQHNo+K8KYVCRSrcB0SaMmyLw5NQppeuKM0A Date: Sun, 7 Oct 2012 18:19:34 +0000 Message-ID: In-Reply-To: <874nm7v92k.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.47] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C1BF4FA0905EB4E9D0980C5F6555BAF@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: osu.edu Cc: "abfab@ietf.org" , "ietf@ietf.org" Subject: Re: [abfab] Last Call: (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 18:19:39 -0000 On 10/6/12 12:50 PM, "Simon Josefsson" wrote: > >Thanks, now I understand better. I would feel more comfortable if there >were a precise reference to what "well-formed serialization" means, >especially since there is a MUST here. It ought to be possible to >determine algorithmically whether something conforms or not. Sometimes >I get the impression that "well-formed" just refers to syntactical >correctness, whereas namespace considerations are more semantic. Actually namespaces extend the notion of syntax in XML, so they're not just semantic. When you parse while namespace-aware, there are normative rules for that grammar that include having namespaces declared properly. I think you probably want to reference the notion of "namespace well-formed", so my suggested text could be adjusted to include that instead of just "well-formed". http://www.w3.org/TR/2009/REC-xml-names-20091208/#Conformance >If there is a suitable reference to some XML standard, that is probably >better. See above. -- Scott From leifj@sunet.se Mon Oct 8 02:37:22 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF8D21F8717 for ; Mon, 8 Oct 2012 02:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei2plBZ2f2x7 for ; Mon, 8 Oct 2012 02:37:21 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2A321F86D8 for ; Mon, 8 Oct 2012 02:37:21 -0700 (PDT) Received: from [109.105.104.222] (dhcp87.se-tug.nordu.net [109.105.104.222] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q989bFga016435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Oct 2012 11:37:19 +0200 (CEST) Message-ID: <50729ECB.9080406@sunet.se> Date: Mon, 08 Oct 2012 11:37:15 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <506AF477.4020900@cs.tcd.ie> <506AFBD1.2060101@cs.tcd.ie> In-Reply-To: <506AFBD1.2060101@cs.tcd.ie> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 09:37:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> The SAML signature mechanism is anselary to the security approach >> that we're using for this. I think a lot of us would like to not >> even support signatures in this SAML binding because we believe >> that the hop-by-hop integrity is sufficient and because those >> signatures will create interoperability problems. > > Is there text somewhere that argues that hop-by-hop integrity is > enough for abfab? Is that for all use-cases or just some? with chair as off: I'm a bit worried about out-of-band attribute-authorities here. In-band hop-by-hop _may_ be good enough when all of the attributes come from the IdP. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBynscACgkQ8Jx8FtbMZnfHPACggEqHgLZW+edwUUWFuEhSntFf l+0An1pO5AIQa+cj3RtW7m/llwsnoKBX =wd5x -----END PGP SIGNATURE----- From hartmans@painless-security.com Mon Oct 8 05:55:28 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA07C21F8596 for ; Mon, 8 Oct 2012 05:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.347 X-Spam-Level: **** X-Spam-Status: No, score=4.347 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p587ZXP-b-B for ; Mon, 8 Oct 2012 05:55:28 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5AB21F8592 for ; Mon, 8 Oct 2012 05:55:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8A27720161; Mon, 8 Oct 2012 08:55:13 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C39C44AD5; Mon, 8 Oct 2012 08:55:22 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <506AF477.4020900@cs.tcd.ie> <506AFBD1.2060101@cs.tcd.ie> <50729ECB.9080406@sunet.se> Date: Mon, 08 Oct 2012 08:55:22 -0400 In-Reply-To: <50729ECB.9080406@sunet.se> (Leif Johansson's message of "Mon, 08 Oct 2012 11:37:15 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 12:55:28 -0000 This specification only covers in-band. I agree with you that you need to do something about integrity for out-of-band. --Sam From simon@josefsson.org Wed Oct 10 15:14:04 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CD321F86B5; Wed, 10 Oct 2012 15:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjthuRmgwYpi; Wed, 10 Oct 2012 15:14:04 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7858421F86BA; Wed, 10 Oct 2012 15:14:02 -0700 (PDT) Received: from latte (host-95-193-1-90.mobileonline.telia.com [95.193.1.90]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9AMDObv021255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 11 Oct 2012 00:13:34 +0200 From: Simon Josefsson To: "Cantor\, Scott" References: <874nm7v92k.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:121010:cantor.2@osu.edu::mNWUgTgx06C4taci:1n52 X-Hashcash: 1:22:121010:abfab@ietf.org::U4vxsnPFNIPtaOvE:6zNH X-Hashcash: 1:22:121010:ietf@ietf.org::NSULhYFmJXvyQLrl:K75X Date: Thu, 11 Oct 2012 00:13:16 +0200 In-Reply-To: (Scott Cantor's message of "Sun, 7 Oct 2012 18:19:34 +0000") Message-ID: <87wqyyf01v.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "abfab@ietf.org" , "ietf@ietf.org" Subject: Re: [abfab] Last Call: (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 22:14:04 -0000 "Cantor, Scott" writes: > On 10/6/12 12:50 PM, "Simon Josefsson" wrote: >> >>Thanks, now I understand better. I would feel more comfortable if there >>were a precise reference to what "well-formed serialization" means, >>especially since there is a MUST here. It ought to be possible to >>determine algorithmically whether something conforms or not. Sometimes >>I get the impression that "well-formed" just refers to syntactical >>correctness, whereas namespace considerations are more semantic. > > Actually namespaces extend the notion of syntax in XML, so they're not > just semantic. When you parse while namespace-aware, there are normative > rules for that grammar that include having namespaces declared properly. I > think you probably want to reference the notion of "namespace > well-formed", so my suggested text could be adjusted to include that > instead of just "well-formed". > > http://www.w3.org/TR/2009/REC-xml-names-20091208/#Conformance If the document use the term "namespace well-formed" and/or include the reference that would resolve the issue for me. Thanks for clarifying this. /Simon From internet-drafts@ietf.org Sun Oct 14 09:59:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3044721F8450; Sun, 14 Oct 2012 09:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R42G4mqXyP4; Sun, 14 Oct 2012 09:59:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39C221F8452; Sun, 14 Oct 2012 09:59:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121014165911.29720.33493.idtracker@ietfa.amsl.com> Date: Sun, 14 Oct 2012 09:59:11 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-eapapplicability-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 16:59:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : Update to the EAP Applicability Statement for ABFAB Author(s) : Stefan Winter Joseph Salowey Filename : draft-ietf-abfab-eapapplicability-01.txt Pages : 6 Date : 2012-10-14 Abstract: This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-eapapplicability-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-eapapplicability-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf@augustcellars.com Sun Oct 14 20:33:14 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7295921F852B for ; Sun, 14 Oct 2012 20:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFsCtqmoxG2J for ; Sun, 14 Oct 2012 20:33:14 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF8521F84DE for ; Sun, 14 Oct 2012 20:33:14 -0700 (PDT) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 9E9E32CA19; Sun, 14 Oct 2012 20:33:13 -0700 (PDT) From: "Jim Schaad" To: Date: Sun, 14 Oct 2012 20:31:28 -0700 Message-ID: <002301cdaa85$99f82080$cde86180$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2qhTlMukE6B++4RiSiD/ycj0enUw== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Comments: draft-ietf-abfab-eapapplicability-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 03:33:14 -0000 On the current draft I have the following comments. 1. I believe that the document is ready for a WGLC 2. Section 2 last paragraph uses the word MUST for possession of the EAP MSK. Section 3 paragraph 2 uses the work important. Section 3 should be updated to use MUST. Jim From klaas@cisco.com Mon Oct 15 04:11:51 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC4521F86AB; Mon, 15 Oct 2012 04:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqJ-tMZTQV14; Mon, 15 Oct 2012 04:11:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3890821F8712; Mon, 15 Oct 2012 04:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1583; q=dns/txt; s=iport; t=1350299505; x=1351509105; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=kBE/bQTYpjcgG6nWznZMgRzBErdvMxZK0BCTiXo0/K4=; b=FN/2rytq7SW8thLn/FNcZev86JNSciIhpOX/4DHZyu9ABvyqTRzJS+5K LdPyU9NKtHtfrgyHDICjtXkbi4obVBaRAqxMyacw5Rr2a13XPz1KrxgxI THwO8DDVMV/wndSV1vN4YSmZ8uF734IceqRm68efWeO9jX3v3n3bUguEU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAvue1CtJV2Z/2dsb2JhbABFv3eBCIIgAQEBAwESASc9BwscAQIBAi9JBAIIBgESCRmHXAYLnVufQItZhV1gA5VsgRWNMIFrgm8 X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="131623606" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2012 11:11:44 +0000 Received: from rtp-vpn6-1164.cisco.com (rtp-vpn6-1164.cisco.com [10.82.252.144]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9FBBg6a016451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Oct 2012 11:11:44 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Oct 2012 13:11:41 +0200 References: <20121015102423.29339.12997.idtracker@ietfa.amsl.com> To: radext@ietf.org, "" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Subject: [abfab] Fwd: New Version Notification for draft-wierenga-ietf-eduroam-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 11:11:51 -0000 FYI Begin forwarded message: > From: > Subject: New Version Notification for = draft-wierenga-ietf-eduroam-00.txt > Date: October 15, 2012 12:24:23 PM GMT+02:00 > To: > Cc: , >=20 >=20 > A new version of I-D, draft-wierenga-ietf-eduroam-00.txt > has been successfully submitted by Klaas Wierenga and posted to the > IETF repository. >=20 > Filename: draft-wierenga-ietf-eduroam > Revision: 00 > Title: The eduroam architecture for network roaming > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 31 > URL: = http://www.ietf.org/internet-drafts/draft-wierenga-ietf-eduroam-00.txt > Status: = http://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam > Htmlized: = http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-00 >=20 >=20 > Abstract: > This document describes the architecture of the eduroam service for > federated (wireless) network access in academia. The combination of > 802.1X, EAP and RADIUS that is used in eduroam provides a secure, > scalable and deployable service for roaming network access. The > successful deployment of eduroam over the last decade in the > educational sector may serve as an example for other sectors, hence > this document. In particular the initial architectural and = standards > choices and the changes that were prompted by operational experience > are highlighted. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From Josh.Howlett@ja.net Mon Oct 15 05:56:40 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCEE21F8758 for ; Mon, 15 Oct 2012 05:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMpsA8dL-DQm for ; Mon, 15 Oct 2012 05:56:39 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEB821F86F8 for ; Mon, 15 Oct 2012 05:56:39 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2A50320C71B8_7C0805B; Mon, 15 Oct 2012 12:56:37 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 4751C20C7123_7C0804F; Mon, 15 Oct 2012 12:56:36 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Mon, 15 Oct 2012 13:56:35 +0100 From: Josh Howlett To: Klaas Wierenga , "" Thread-Topic: Trust router (was Re: [abfab] Fwd: New Version Notification for draft-wierenga-ietf-eduroam-00.txt) Thread-Index: AQHNqtSBIG2/OYb8xkuALeXxRwN1Dg== Date: Mon, 15 Oct 2012 12:56:35 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [abfab] Trust router (was Re: Fwd: New Version Notification for draft-wierenga-ietf-eduroam-00.txt) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 12:56:40 -0000 Hi Klaas, I probably shouldn't be writing this email until I have finished the update to aaa-saml :-). However I thought it was worth pointing out that section 3.3. ('Routing table complexity') is a nice description of the kind of problem that Trust Router (draft-howlett-abfab-trust-router-ps) is trying to fix. But now let us imagine that one was also interested in operating "govroam" in parallel to eduroam, where they may be some overlap between these communities. Now, in addition to the naming/connectivity incongruence described in section 3.3, you can also add incongruence of trust communities. My contention is that, for the use cases that Abfab is addressing, the number and overlap of trust communities wanting to consume identity is in fact rather large. Therefore it will be significantly cheaper to operate a single infrastructure that can manage these incongruences, rather than instantiate N distinct infrastructures for N different trust communities. It should be as cheap and easy to create and manage a trust community of arbitrary actors as it is to connect a house full of consumer electronics to a domestic WiFi router. Josh. On 15/10/2012 12:11, "Klaas Wierenga" wrote: >FYI > >Begin forwarded message: > >> From: >> Subject: New Version Notification for draft-wierenga-ietf-eduroam-00.txt >> Date: October 15, 2012 12:24:23 PM GMT+02:00 >> To: >> Cc: , >>=20 >>=20 >> A new version of I-D, draft-wierenga-ietf-eduroam-00.txt >> has been successfully submitted by Klaas Wierenga and posted to the >> IETF repository. >>=20 >> Filename: draft-wierenga-ietf-eduroam >> Revision: 00 >> Title: The eduroam architecture for network roaming >> Creation date: 2012-10-15 >> WG ID: Individual Submission >> Number of pages: 31 >> URL:=20=20=20=20=20=20=20=20=20=20=20=20 >>http://www.ietf.org/internet-drafts/draft-wierenga-ietf-eduroam-00.txt >> Status:=20=20=20=20=20=20=20=20=20 >>http://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam >> Htmlized:=20=20=20=20=20=20=20 >>http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-00 >>=20 >>=20 >> Abstract: >> This document describes the architecture of the eduroam service for >> federated (wireless) network access in academia. The combination of >> 802.1X, EAP and RADIUS that is used in eduroam provides a secure, >> scalable and deployable service for roaming network access. The >> successful deployment of eduroam over the last decade in the >> educational sector may serve as an example for other sectors, hence >> this document. In particular the initial architectural and standards >> choices and the changes that were prompted by operational experience >> are highlighted. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 > >_______________________________________________ >abfab mailing list >abfab@ietf.org >https://www.ietf.org/mailman/listinfo/abfab Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From klaas@cisco.com Mon Oct 15 06:34:05 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A90021F868A for ; Mon, 15 Oct 2012 06:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SD7lHlxUnV0Q for ; Mon, 15 Oct 2012 06:34:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6361721F8688 for ; Mon, 15 Oct 2012 06:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3845; q=dns/txt; s=iport; t=1350308044; x=1351517644; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CicBldgXSF4ppZXXKPPQF+jiQpgXaTHjLVkZ8ttYjp4=; b=WPD+zersHdEwvpQuvFMgZ0f508tbcjPu7+tfjo1s7u8bfEAvG6x/lrMB okcajbDKwaMQsdwW+DBOOLY6XSAUVWUku7JHjDbrOSHXq/oLYTrd7qrvc k8DLS53iCFLZt1Pqvh831LjUHr0yVQ3AGeI2WnMC4qRwRW/30t4SLCRXm w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIMPfFCtJXG8/2dsb2JhbAA8Cb94gQiCIAEBAQMBAQEBDwFbCQIFCwsRAQIBAgEjCyciBggGEwkLDodcBgudZ59Ti1kRhUxgA5VsgRWNMIFrgm+BYQ X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="131664608" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2012 13:34:03 +0000 Received: from rtp-vpn6-1164.cisco.com (rtp-vpn6-1164.cisco.com [10.82.252.144]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9FDY1GI027902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Oct 2012 13:34:02 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Klaas Wierenga In-Reply-To: Date: Mon, 15 Oct 2012 15:33:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B5663C2-D1B5-4507-9CC0-C898BC03BA3F@cisco.com> References: To: Josh Howlett X-Mailer: Apple Mail (2.1498) Cc: "" Subject: Re: [abfab] Trust router (was Re: Fwd: New Version Notification for draft-wierenga-ietf-eduroam-00.txt) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 13:34:05 -0000 On Oct 15, 2012, at 2:56 PM, Josh Howlett wrote: Hi Josh, all, > I probably shouldn't be writing this email until I have finished the > update to aaa-saml :-). However I thought it was worth pointing out = that see, I knew our severity would pay of at some point=85. ;-) > section 3.3. ('Routing table complexity') is a nice description of the > kind of problem that Trust Router = (draft-howlett-abfab-trust-router-ps) is > trying to fix. >=20 > But now let us imagine that one was also interested in operating = "govroam" > in parallel to eduroam, where they may be some overlap between these > communities. Now, in addition to the naming/connectivity incongruence > described in section 3.3, you can also add incongruence of trust > communities. >=20 > My contention is that, for the use cases that Abfab is addressing, the > number and overlap of trust communities wanting to consume identity is = in > fact rather large. Therefore it will be significantly cheaper to = operate a > single infrastructure that can manage these incongruences, rather than > instantiate N distinct infrastructures for N different trust = communities. >=20 > It should be as cheap and easy to create and manage a trust community = of > arbitrary actors as it is to connect a house full of consumer = electronics > to a domestic WiFi router. Yes, I was meaning to bring this topic up. Given that we are making good = progress with the abfab core documents the question arises what to do = next. Fold abfab or recharter and pick up new work. I think we should = have that discussion. Klaas >=20 > Josh. >=20 > On 15/10/2012 12:11, "Klaas Wierenga" wrote: >=20 >> FYI >>=20 >> Begin forwarded message: >>=20 >>> From: >>> Subject: New Version Notification for = draft-wierenga-ietf-eduroam-00.txt >>> Date: October 15, 2012 12:24:23 PM GMT+02:00 >>> To: >>> Cc: , >>>=20 >>>=20 >>> A new version of I-D, draft-wierenga-ietf-eduroam-00.txt >>> has been successfully submitted by Klaas Wierenga and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-wierenga-ietf-eduroam >>> Revision: 00 >>> Title: The eduroam architecture for network roaming >>> Creation date: 2012-10-15 >>> WG ID: Individual Submission >>> Number of pages: 31 >>> URL: =20 >>> = http://www.ietf.org/internet-drafts/draft-wierenga-ietf-eduroam-00.txt >>> Status: =20 >>> http://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam >>> Htmlized: =20 >>> http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-00 >>>=20 >>>=20 >>> Abstract: >>> This document describes the architecture of the eduroam service for >>> federated (wireless) network access in academia. The combination = of >>> 802.1X, EAP and RADIUS that is used in eduroam provides a secure, >>> scalable and deployable service for roaming network access. The >>> successful deployment of eduroam over the last decade in the >>> educational sector may serve as an example for other sectors, hence >>> this document. In particular the initial architectural and = standards >>> choices and the changes that were prompted by operational = experience >>> are highlighted. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 >=20 > Janet is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024=20 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG >=20 From hartmans@painless-security.com Fri Oct 19 06:28:05 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D7621F85FE for ; Fri, 19 Oct 2012 06:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.361 X-Spam-Level: **** X-Spam-Status: No, score=4.361 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3MtwpcWBlIW for ; Fri, 19 Oct 2012 06:28:04 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id C49CE21F8480 for ; Fri, 19 Oct 2012 06:28:04 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E22F22010B; Fri, 19 Oct 2012 09:27:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BD6104AD5; Fri, 19 Oct 2012 09:28:02 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Fri, 19 Oct 2012 09:28:02 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: zhangdacheng@huawei.com, pcp-chairs@tools.ietf.org Subject: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:28:05 -0000 Hi. Over in PCP we've been attempting to apply EAP to the application authentication problem. My personal opinion is that GSS-EAP brings more complexity than PCP needs. Three solutions are being considered: two PANA-based solutions and one solution tuned for PCP. A few issues have come up where the requirements of EAP are unclear at least to some participants. It seems to me like the EAP applicability update would be a great place to cover these issues. The first is retransmission. As specified in RFC 3748, EAP handles retransmissions, and the EAP authenticator is responsible for the retransmission. However, the EAP RFC allows a lower layer to set the retransmission timeout to infinite. In terms of an applicability statement, I believe that applications MUST choose one of the following options: 1) Have authenticator-initiated retransmissions at the EAP layer. 2) Set the timeout to infinite and require retransmissions at a lower layer that is application specific. For example, since GSS-API provides reliability, we chose option 2 in draft-ietf-abfab-gss-eap. This is particularly true because GSS-API doesn't support the idea of unsolicited messages from server to client. The applicability statement should point out that if applications choose option 1 they need to be able to transmit messages from server to client at any time during the authentication phase. If the WG agrees with this proposal I'll propose specific text. From hartmans@painless-security.com Fri Oct 19 06:41:31 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C437E21F86BF for ; Fri, 19 Oct 2012 06:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.36 X-Spam-Level: **** X-Spam-Status: No, score=4.36 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu2SfzqJ5PD2 for ; Fri, 19 Oct 2012 06:41:31 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3449821F86A1 for ; Fri, 19 Oct 2012 06:41:31 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 966BD2010B; Fri, 19 Oct 2012 09:41:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5141C4AD5; Fri, 19 Oct 2012 09:41:29 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Fri, 19 Oct 2012 09:41:29 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: zhangdacheng@huawei.com, pcp-chairs@tools.ietf.org Subject: [abfab] EAP Applicability: server-initiated re-authentication X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:41:31 -0000 Second issue relates to EAP requirements surrounding server-initiated re-authentication. We've had one claim that EAP lower layers MUST support re-authentication initiated by the server. If that's true, we have kind of a big problem with GSS-EAP. As best I can tell though that's not true. RFC 3748 doesn't really talk about server-initiated re-authentication. The RADIUS EAP support doesn't seem to support it, and the COA informational RFC explicitly says it cannot be used for re-authentication. The Diameter EAP application says that if the lower layer supports EAP re-authentication then the Diameter NAS MUST support re-authentication as well. I have looked up citations for the above in a PCP discussion and am happy to dig that all up if they would help anyone here. As best I can tell, the motivation for re-authentication is an interesting different between network access and application authentication. In network access, there is a significant disruption if your connection drops and you have to re-authenticate before you can send your next packet. It's strongly desirable to re-authenticate before your lifetime expires. (This doesn't speak to server-initiated re-auth, I realize) Some applications work like that. However there are a lot of applications where the server can close the connection and when the client wants to do the next thing, it will re-authenticate at that time. For example with SMTP, it's not going to be a big deal if the next time I want to send mail it takes a bit longer because my server has closed a connection to force me to reauthenticate. My recommendation is that the applicability statement should discuss the issue of re-authentication. We should recommend that applications that will be disrupted by authentication expiration have a mechanism to re-authenticate while the existing authentication is still live. I think we need to say very little about server-initiated re-authentication. I think we should say that applications MAY support server-initiated re-authentication. If they do, then the server can send authentication packets at any time. From alper.yegin@yegin.org Fri Oct 19 06:56:51 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE41E21F86DF for ; Fri, 19 Oct 2012 06:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPSb0W-efU0u for ; Fri, 19 Oct 2012 06:56:50 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id CB8C321F86B6 for ; Fri, 19 Oct 2012 06:56:50 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lx8eP-1TMoXT08Ft-016JF6; Fri, 19 Oct 2012 09:56:49 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Fri, 19 Oct 2012 16:56:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> References: To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:MSk5oR2d7d4hi4UM0O7t1o11GitE+2h84rXlmiF/8HF gOCEP/Vf1w715a1mJy6fzHmIrdC31+zxFHDz4Dzx2xg3PQu6eD WEGTXj7C8nuYV9MH7UAtaQ9z7i0BPYmv1CpHt0kvcus5xMnbW7 Wpx0avfKnhxvrH15bBfCSLx5SxMV5MxnZX90sbjuWJrwMzqVK2 E/O1mYmymMdNCfCJ2VflkVBVOweSK2fIf34D2bZ8IW2v65HUk+ oDjBqs8XPJeHFE/FJ4fwAiR3kWldmCTUpDRXYHqXPhTANRREFw Bry5B3u3ZoLo34mqOLdPfvJvPtRfULNTvRbr9wBR1pV5dPHBgG 15C5hKN8i1RDdknnseWhys9WlThyJZ8hktrbIY0RkpTKELqrx1 1PzVaqNzo+rfw== Cc: abfab@ietf.org, zhangdacheng@huawei.com, pcp-chairs@tools.ietf.org Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:56:51 -0000 Hi Sam, Please also share this discussion with EAP WG and EMU WG mailing lists. = That's where the EAP expertise is and they should chime in, given that = you are proposing to modify EAP applicability statement. Alper On Oct 19, 2012, at 4:41 PM, Sam Hartman wrote: >=20 > Second issue relates to EAP requirements surrounding server-initiated > re-authentication. We've had one claim that EAP lower layers MUST > support re-authentication initiated by the server. >=20 > If that's true, we have kind of a big problem with GSS-EAP. >=20 > As best I can tell though that's not true. RFC 3748 doesn't really = talk > about server-initiated re-authentication. The RADIUS EAP support > doesn't seem to support it, and the COA informational RFC explicitly > says it cannot be used for re-authentication. The Diameter EAP > application says that if the lower layer supports EAP = re-authentication > then the Diameter NAS MUST support re-authentication as well. > I have looked up citations for the above in a PCP discussion and am > happy to dig that all up if they would help anyone here. >=20 > As best I can tell, the motivation for re-authentication is an > interesting different between network access and application > authentication. In network access, there is a significant disruption = if > your connection drops and you have to re-authenticate before you can > send your next packet. > It's strongly desirable to re-authenticate before your lifetime = expires. > (This doesn't speak to server-initiated re-auth, I realize) >=20 > Some applications work like that. > However there are a lot of applications where the server can close the > connection and when the client wants to do the next thing, it will > re-authenticate at that time. > For example with SMTP, it's not going to be a big deal if the next = time > I want to send mail it takes a bit longer because my server has closed = a > connection to force me to reauthenticate. >=20 > My recommendation is that the applicability statement should discuss > the issue of re-authentication. We should recommend that applications > that will be disrupted by authentication expiration have a mechanism > to re-authenticate while the existing authentication is still live. >=20 > I think we need to say very little about server-initiated > re-authentication. I think we should say that applications MAY support > server-initiated re-authentication. If they do, then the server can = send > authentication packets at any time. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Fri Oct 19 07:00:00 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA1B21F8639 for ; Fri, 19 Oct 2012 07:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.358 X-Spam-Level: **** X-Spam-Status: No, score=4.358 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDDljLrYZRO8 for ; Fri, 19 Oct 2012 07:00:00 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5928E21F8487 for ; Fri, 19 Oct 2012 07:00:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B43A22010B; Fri, 19 Oct 2012 09:59:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 536C24AD5; Fri, 19 Oct 2012 09:59:58 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Fri, 19 Oct 2012 09:59:58 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: zhangdacheng@huawei.com, pcp-chairs@tools.ietf.org Subject: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:00:01 -0000 Another issue that has come up in the PCP discussions is the question of authorization lifetimes. Various AAA documents including the EAP keying framework limit the session lifetime based on what you get back from AAA. In the case of network access, that's kind of obvious: your ability to send packets is limited by the lifetime. There's a lot of discussion of complexity surrounding pre-authentication, but the general concept is only mildly complex. It's more complex with applications. If I go commit some source code, that change will persist well past my ssh session. PCP is a NAT/firewall management protocol. It creates NAT mappings among other things. There has been some heated debate about whether the lifetime of these mappings should be dependend on the authentication session. One argument is that during the authentication session, you are authorized to make mapping changes. The server gets to decide how long those mappings are using whatever policy it likes. The server can limit things to the authentication session lifetime if it likes. Another argument is that the PCP security protocol should place requirements on this like the AAA keying framework does for network sessions. the question of what PCP should do belongs in that WG; I don't want to discuss it here. However, I think we should clarify whether EAP or AAA has anything to say about this. I think the answer is that AAA has a session lifetime, but what that means for applications and what persists beyond that session needs to be decided by those apps. I'd like to have fairly clear text that this is an application decision and that EAP and AAA are not trying to define the extent of a session or lifetime for applications. Other people involved in the PCP discussion may disagree with me and prefer that EAP/AAA define this for apps. --Sam From stefan.winter@restena.lu Fri Oct 19 07:00:11 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB3121F8594 for ; Fri, 19 Oct 2012 07:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgXsX2VsV2Og for ; Fri, 19 Oct 2012 07:00:10 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 5310F21F8570 for ; Fri, 19 Oct 2012 07:00:10 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C494D1058B; Fri, 19 Oct 2012 16:00:08 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:bc1e:8f50:4d90:9f2e] (unknown [IPv6:2001:a18:1:8:bc1e:8f50:4d90:9f2e]) by smtprelay.restena.lu (Postfix) with ESMTPS id B0F531058A; Fri, 19 Oct 2012 16:00:08 +0200 (CEST) Message-ID: <50815CE4.9000603@restena.lu> Date: Fri, 19 Oct 2012 16:00:04 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: abfab@ietf.org, zhangdacheng@huawei.com, pcp-chairs@tools.ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD39E2C4F1DF0C0B0FBAB55FB" X-Virus-Scanned: ClamAV Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:00:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD39E2C4F1DF0C0B0FBAB55FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Hi. Over in PCP we've been attempting to apply EAP to the application > authentication problem. My personal opinion is that GSS-EAP brings mor= e > complexity than PCP needs. Three solutions are being considered: two > PANA-based solutions and one solution tuned for PCP. >=20 > A few issues have come up where the requirements of EAP are unclear at= > least to some participants. Draft draft-ietf-abfab-eapapplicability updates only the EAP applicability statement (i.e. section 1.3 of RFC3748). I have the impression that the clarifications regarding retransmission which you describe below are certainly related to RFC3748, but are not something that should be mentioned in section 1.3, i.e. the applicability statement. > It seems to me like the EAP applicability update would be a great place= > to cover these issues. If my suspicion in the paragraph above is true, the *applicability update* seems like the wrong place IMHO. An update to (or if the issue is seen as small enough: an erratum pertinent to) RFC3748 as a whole would be a more logical approach. Also, we have earlier been discussing the scope of draft-ietf-abfab-eapapplicability - whether it should cover all present-day uses of EAP, or just abfab-related uses. Back then we concluded that its scope should be narrowed down to just abfab. Since your issue is occuring in pcp, not abfab, that agreed course of action would mean that the issue is out of scope for draft-ietf-abfab-eapapplicability, even if it should indeed relate to section 1.3 of RFC3748. > The first is retransmission. >=20 > As specified in RFC 3748, EAP handles retransmissions, and the EAP > authenticator is responsible for the retransmission. >=20 > However, the EAP RFC allows a lower layer to set the retransmission > timeout to infinite. >=20 > In terms of an applicability statement, I believe that applications > MUST choose one of the following options: >=20 > 1) Have authenticator-initiated retransmissions at the EAP layer. >=20 > 2) Set the timeout to infinite and require retransmissions at a lower > layer that is application specific. >=20 > For example, since GSS-API provides reliability, we chose option 2 in > draft-ietf-abfab-gss-eap. This is particularly true because GSS-API > doesn't support the idea of unsolicited messages from server to client.= > The applicability statement should point out that if applications choos= e > option 1 they need to be able to transmit messages from server to clien= t > at any time during the authentication phase. Is there a second one? Greetings, Stefan >=20 > If the WG agrees with this proposal I'll propose specific text. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigD39E2C4F1DF0C0B0FBAB55FB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCBXOgACgkQ+jm90f8eFWZ+IACfWm8zurztakxcsRpG9xtF1SVw mkkAn1oevdMMzpuIpVJbDayVM4rQLw7H =vkpM -----END PGP SIGNATURE----- --------------enigD39E2C4F1DF0C0B0FBAB55FB-- From hartmans@painless-security.com Fri Oct 19 07:06:47 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBFC21F8949 for ; Fri, 19 Oct 2012 07:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.357 X-Spam-Level: **** X-Spam-Status: No, score=4.357 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4e0q9l6-tVy for ; Fri, 19 Oct 2012 07:06:46 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3D74621F88EC for ; Fri, 19 Oct 2012 07:06:46 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 95F462010B; Fri, 19 Oct 2012 10:06:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 143D14AD5; Fri, 19 Oct 2012 10:06:44 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <50815CE4.9000603@restena.lu> Date: Fri, 19 Oct 2012 10:06:44 -0400 In-Reply-To: <50815CE4.9000603@restena.lu> (Stefan Winter's message of "Fri, 19 Oct 2012 16:00:04 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, zhangdacheng@huawei.com, pcp-chairs@tools.ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:06:47 -0000 >>>>> "Stefan" == Stefan Winter writes: >> Hi. Over in PCP we've been attempting to apply EAP to the >> application authentication problem. My personal opinion is that >> GSS-EAP brings more complexity than PCP needs. Three solutions >> are being considered: two PANA-based solutions and one solution >> tuned for PCP. >> >> A few issues have come up where the requirements of EAP are >> unclear at least to some participants. Stefan> Draft draft-ietf-abfab-eapapplicability updates only the EAP Stefan> applicability statement (i.e. section 1.3 of RFC3748). Stefan> I have the impression that the clarifications regarding Stefan> retransmission which you describe below are certainly Stefan> related to RFC3748, but are not something that should be Stefan> mentioned in section 1.3, i.e. the applicability statement. Actually, RFC 3748 is quite clear about this already. My belief is that your draft should cover the sorts of issues that applicability statements generally cover... What issues should an applied-to thing consider when applying the applied thing. What issues should you consider when evaluating whether the applied thing is appropriate to apply. I'm not proposing changing EAp. Also, my understanding is that the scope of your document is uses of EAP within ABFAB's scope. That is, uses of EAp within the scope of application authentication. What's going on with PCP is very much within that scope. So would you be willing to reread my messages in that revised context and give me your thoughts there? --Sam From stefan.winter@restena.lu Fri Oct 19 07:10:23 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D47D21F8722 for ; Fri, 19 Oct 2012 07:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO64txh739Sm for ; Fri, 19 Oct 2012 07:10:23 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D918A21F86E5 for ; Fri, 19 Oct 2012 07:10:22 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 0FF0210691 for ; Fri, 19 Oct 2012 16:10:21 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:bc1e:8f50:4d90:9f2e] (unknown [IPv6:2001:a18:1:8:bc1e:8f50:4d90:9f2e]) by smtprelay.restena.lu (Postfix) with ESMTPS id EE2DE10590 for ; Fri, 19 Oct 2012 16:10:20 +0200 (CEST) Message-ID: <50815F47.3010608@restena.lu> Date: Fri, 19 Oct 2012 16:10:15 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAAD1667BB7066C7A888A37E7" X-Virus-Scanned: ClamAV Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:10:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAAD1667BB7066C7A888A37E7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I'd like to have fairly clear text that this is an application decisio= n > and that EAP and AAA are not trying to define the extent of a session o= r > lifetime for applications. > Other people involved in the PCP discussion may disagree with me and > prefer that EAP/AAA define this for apps. It sounds to me like the sequence of events here should better be: you and the other people in PCP come to an agreement which of the two approaches should be taken and *then* one has to think whether a corresponding update to either section 1.3 or any other part of RFC3748 is necessary. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigAAD1667BB7066C7A888A37E7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCBX0wACgkQ+jm90f8eFWbemACdE6kCd2J5NMqC0OLrlkT+DRZt LkMAnjNk4W3j8ArMGIvU5rqyeYZ6NSHJ =QjQO -----END PGP SIGNATURE----- --------------enigAAD1667BB7066C7A888A37E7-- From hartmans@painless-security.com Fri Oct 19 07:26:16 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7BE21F8639 for ; Fri, 19 Oct 2012 07:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.356 X-Spam-Level: **** X-Spam-Status: No, score=4.356 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrBlgnbMYxAs for ; Fri, 19 Oct 2012 07:26:16 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3DA21F85A4 for ; Fri, 19 Oct 2012 07:26:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C79D32010B; Fri, 19 Oct 2012 10:08:20 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 745F94AD5; Fri, 19 Oct 2012 10:08:35 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> Date: Fri, 19 Oct 2012 10:08:35 -0400 In-Reply-To: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> (Alper Yegin's message of "Fri, 19 Oct 2012 16:56:27 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, zhangdacheng@huawei.com, pcp-chairs@tools.ietf.org Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:26:16 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> Hi Sam, Please also share this discussion with EAP WG and EMU Alper> WG mailing lists. That's where the EAP expertise is and they Alper> should chime in, given that you are proposing to modify EAP Alper> applicability statement. The eap applicability statement update is a charter item of ABFAB. We've agreed it will be last called in EMU. Since it's a work item of abfab, it should be discussed on that list. You're certainly free to let people know that the discussion if taking place, although we've done that several times before. From internet-drafts@ietf.org Fri Oct 19 07:30:54 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704F721F86ED; Fri, 19 Oct 2012 07:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpUsMQ1tozrs; Fri, 19 Oct 2012 07:30:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0384121F86E8; Fri, 19 Oct 2012 07:30:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019143054.12985.27195.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 07:30:54 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-04.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:30:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : A RADIUS Attribute, Binding and Profiles for SAML Author(s) : Josh Howlett Sam Hartman Filename : draft-ietf-abfab-aaa-saml-04.txt Pages : 19 Date : 2012-10-19 Abstract: This document specifies a RADIUS attribute, a binding and two profiles for the Security Assertion Mark-up Language (SAML). The attribute provides RADIUS encapsulation of SAML protocol messages, and the binding describes the use of this attribute, and the SAML protocol messages within, with RADIUS transport. The two profiles describe the application of this binding for ABFAB authentication and assertion query/request respectively. The SAML RADIUS attribute and binding are defined generically to permit application in other scenarios, such as network access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-aaa-saml-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@painless-security.com Fri Oct 19 07:46:21 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B0B21F8639 for ; Fri, 19 Oct 2012 07:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.355 X-Spam-Level: **** X-Spam-Status: No, score=4.355 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vcr3D0zfQJ6 for ; Fri, 19 Oct 2012 07:46:20 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 556FB21F847B for ; Fri, 19 Oct 2012 07:46:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7BE4B2010B; Fri, 19 Oct 2012 10:39:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0561F4AD5; Fri, 19 Oct 2012 10:40:04 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <50815F47.3010608@restena.lu> Date: Fri, 19 Oct 2012 10:40:03 -0400 In-Reply-To: <50815F47.3010608@restena.lu> (Stefan Winter's message of "Fri, 19 Oct 2012 16:10:15 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:46:21 -0000 >>>>> "Stefan" == Stefan Winter writes: Stefan> Hi, >> I'd like to have fairly clear text that this is an application >> decision and that EAP and AAA are not trying to define the extent >> of a session or lifetime for applications. Other people involved >> in the PCP discussion may disagree with me and prefer that >> EAP/AAA define this for apps. Stefan> It sounds to me like the sequence of events here should Stefan> better be: you and the other people in PCP come to an Stefan> agreement which of the two approaches should be taken and Stefan> *then* one has to think whether a corresponding update to Stefan> either section 1.3 or any other part of RFC3748 is Stefan> necessary. I'm confused by your message because I don't understand how PCP can make the decision without understanding the EAP requirements. If EAP is going to make requirements of PCP, then either PCP needs to meet those requirements or not use EAP. so, I think we need to understand the general requirements to understand what our options are in PCP. So, would you be willing to explain why you believe PCP should decide on its requirements first and how you see that interacting with a later general discussion? --Sam From klaas@cisco.com Fri Oct 19 07:46:39 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E7521F869E for ; Fri, 19 Oct 2012 07:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FirImOjySMs for ; Fri, 19 Oct 2012 07:46:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 060F621F847B for ; Fri, 19 Oct 2012 07:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3292; q=dns/txt; s=iport; t=1350657999; x=1351867599; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=xguVaYgzfVXpgDAsP0j17W6kweD+ZLfPc1DiWlgDeDk=; b=b6CiXf/LLggn3iBJY85ayichiL+p5ygsdHKJlmnYttqsVeZwP4fm+wjn OYGZ/K0radxVVuQbEsywWvJB4B66ymZ3teQqGWPlZutLggBcQBLvivLs6 Gid7BfaUoPXvgU1gWFm4I/6zxV6F5RCp4ms+Vy2S2m1S6DZXyVMueDSca c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKxmgVCtJXG+/2dsb2JhbABFwGGBCIIgAQEBAwEBAQEPASc0CxALRicwBhMih1wGC5xpoCsEi1gUAYV6YAOVb45NgWuCcYFYAQ X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="133433102" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 19 Oct 2012 14:46:38 +0000 Received: from rtp-vpn4-806.cisco.com (rtp-vpn4-806.cisco.com [10.82.211.38]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9JEkaeT019305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Oct 2012 14:46:37 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Klaas Wierenga In-Reply-To: Date: Fri, 19 Oct 2012 16:46:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F48F8FA-D3F3-4DCD-B997-FDB192F6BBA4@cisco.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1498) Cc: abfab@ietf.org, zhangdacheng@huawei.com, pcp-chairs@tools.ietf.org Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:46:39 -0000 On Oct 19, 2012, at 3:59 PM, Sam Hartman = wrote: Sam, The way I look at it is that you talk about two different types of = authorisations, one where the AAA-server says "for the following x = seconds my vouch for the fact that Sam has successfully authenticated = and is associated with the following attributes" and the other where the = resource owner decides what should happen once that assertion is not = valid anymore. I don't believe it is the business of the AAA-server to = say what the resource owner must do. If someone has configured my = firewalls perfectly and now leaves for another company, I do want to = make sure he can not mess with my configs anymore, but I definitely = don;t want to have to redo all my configuration. At the same time, I can = also imagine cases where you do want to roll back actions someone = undertook. So all in all, this is application logic that I don't think = we should try to specify. And indeed, for one particular application, = like network access, it may make perfect sense to specify the behaviour = explicitly. Klaas =20 >=20 >=20 > Another issue that has come up in the PCP discussions is the question > of authorization lifetimes. > Various AAA documents including the EAP keying framework limit the > session lifetime based on what you get back from AAA. > In the case of network access, that's kind of obvious: your ability to > send packets is limited by the lifetime. > There's a lot of discussion of complexity surrounding > pre-authentication, but the general concept is only mildly complex. >=20 > It's more complex with applications. > If I go commit some source code, that change will persist well past my > ssh session. >=20 > PCP is a NAT/firewall management protocol. It creates NAT mappings = among > other things. > There has been some heated debate about whether the lifetime of these > mappings should be dependend on the authentication session. >=20 > One argument is that during the authentication session, you are > authorized to make mapping changes. The server gets to decide how = long > those mappings are using whatever policy it likes. > The server can limit things to the authentication session lifetime if = it > likes. >=20 > Another argument is that the PCP security protocol should place > requirements on this like the AAA keying framework does for network > sessions. >=20 > the question of what PCP should do belongs in that WG; I don't want to > discuss it here. >=20 > However, I think we should clarify whether EAP or AAA has anything to > say about this. > I think the answer is that AAA has a session lifetime, but what that > means for applications and what persists beyond that session needs to = be > decided by those apps. >=20 > I'd like to have fairly clear text that this is an application = decision > and that EAP and AAA are not trying to define the extent of a session = or > lifetime for applications. > Other people involved in the PCP discussion may disagree with me and > prefer that EAP/AAA define this for apps. >=20 > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Fri Oct 19 07:49:34 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0797321F8585 for ; Fri, 19 Oct 2012 07:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.654 X-Spam-Level: **** X-Spam-Status: No, score=4.654 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_31=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKgvE-kwqwmE for ; Fri, 19 Oct 2012 07:49:33 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 394F921F857A for ; Fri, 19 Oct 2012 07:49:33 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D49C22010B; Fri, 19 Oct 2012 10:49:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6C0F84AD5; Fri, 19 Oct 2012 10:49:31 -0400 (EDT) From: Sam Hartman To: Klaas Wierenga References: <1F48F8FA-D3F3-4DCD-B997-FDB192F6BBA4@cisco.com> Date: Fri, 19 Oct 2012 10:49:31 -0400 In-Reply-To: <1F48F8FA-D3F3-4DCD-B997-FDB192F6BBA4@cisco.com> (Klaas Wierenga's message of "Fri, 19 Oct 2012 16:46:35 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, zhangdacheng@huawei.com, pcp-chairs@tools.ietf.org Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:49:34 -0000 >>>>> "Klaas" == Klaas Wierenga writes: Klaas> On Oct 19, 2012, at 3:59 PM, Sam Hartman wrote: Sam, Klaas> The way I look at it is that you talk about two different Klaas> types of authorisations, one where the AAA-server says "for Klaas> the following x seconds my vouch for the fact that Sam has Klaas> successfully authenticated and is associated with the Klaas> following attributes" and the other where the resource owner Klaas> decides what should happen once that assertion is not valid Klaas> anymore. I don't believe it is the business of the AAA-server Klaas> to say what the resource owner must do. If someone has Klaas> configured my firewalls perfectly and now leaves for another Klaas> company, I do want to make sure he can not mess with my Klaas> configs anymore, but I definitely don;t want to have to redo Klaas> all my configuration. At the same time, I can also imagine Klaas> cases where you do want to roll back actions someone Klaas> undertook. So all in all, this is application logic that I Klaas> don't think we should try to specify. And indeed, for one Klaas> particular application, like network access, it may make Klaas> perfect sense to specify the behaviour explicitly. +1 This is really well stated. From stefan.winter@restena.lu Fri Oct 19 08:22:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A005421F8722 for ; Fri, 19 Oct 2012 08:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxECgB4QtbRP for ; Fri, 19 Oct 2012 08:22:55 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D517C21F8721 for ; Fri, 19 Oct 2012 08:22:54 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 3973D1058D; Fri, 19 Oct 2012 17:22:54 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:bc1e:8f50:4d90:9f2e] (unknown [IPv6:2001:a18:1:8:bc1e:8f50:4d90:9f2e]) by smtprelay.restena.lu (Postfix) with ESMTPS id 234F71058B; Fri, 19 Oct 2012 17:22:54 +0200 (CEST) Message-ID: <5081704A.5090504@restena.lu> Date: Fri, 19 Oct 2012 17:22:50 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Sam Hartman References: <50815F47.3010608@restena.lu> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF96A6D602E71004780490D36" X-Virus-Scanned: ClamAV Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:22:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF96A6D602E71004780490D36 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I'm confused by your message because I don't understand how PCP can mak= e > the decision without understanding the EAP requirements. >=20 > If EAP is going to make requirements of PCP, then either PCP needs to > meet those requirements or not use EAP. > so, I think we need to understand the general requirements to understan= d > what our options are in PCP. EAP does not make requirements for PCP in this case; the question is left open in the RFC. That is highly understandable, IMHO, because EAP is the Extensible Authentication protocol; *authorisation* lifetime is not something that's naturally covered. > So, would you be willing to explain why you believe PCP should decide o= n > its requirements first and how you see that interacting with a later > general discussion? You described two courses of action: PCP can either make applications decide on the authorization lifetime on their own, or it can request that this lifetime information is derived from EAP. We agree that the question which course to take is PCP's decision alone. The text in the EAP RFC seems to allow for both; there is lifetime information that can either be made use of, or can be ignored. Given that the information is meant for authentication, it may not be the best idea to overload it and use it for authorisation information; but since signalling authorisation is out of scope for EAP, that doesn't necessarily need to be included in EAP applicability text. One could argue that the EAP Applicability Statement is actually quite clear: it doesn't mention the word authorization. So, probably, whichever of the two courses the PCP wg might favour, chances are good that none of the two require changes to the applicability statement. If the wg thinks that they need a specific use of EAP and they are unsure whether their specific need is covered or not, they can try to sort that out at that point. I would worry about clarifying wording when that has happened. If your intent was to add a "non-applicability" statement like: EAP doesn't care about your authorisation lifetime, then yes, such a statement could be made, but isn't it implicit that everything that is not mentioned as being applicable is not applicable? EAP also doesn't do accounting nor coffee; maybe that needs to be stated, too. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigF96A6D602E71004780490D36 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCBcE4ACgkQ+jm90f8eFWZjrQCfcHl2Uv2WqgsZJ412kOSorH5Y EOIAn1h4Rn66Og+L8xtwGsuXAwqnH/xB =8Rtj -----END PGP SIGNATURE----- --------------enigF96A6D602E71004780490D36-- From hartmans@painless-security.com Fri Oct 19 08:40:54 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1974121F8504 for ; Fri, 19 Oct 2012 08:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.358 X-Spam-Level: **** X-Spam-Status: No, score=4.358 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jfBykN8wzIX for ; Fri, 19 Oct 2012 08:40:53 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 417FB21F84F8 for ; Fri, 19 Oct 2012 08:40:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B09A92010B; Fri, 19 Oct 2012 11:40:36 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 459FD4AD5; Fri, 19 Oct 2012 11:40:51 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <50815F47.3010608@restena.lu> <5081704A.5090504@restena.lu> Date: Fri, 19 Oct 2012 11:40:51 -0400 In-Reply-To: <5081704A.5090504@restena.lu> (Stefan Winter's message of "Fri, 19 Oct 2012 17:22:50 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:40:54 -0000 >>>>> "Stefan" == Stefan Winter writes: Stefan> Hi, >> I'm confused by your message because I don't understand how PCP >> can make the decision without understanding the EAP requirements. >> >> If EAP is going to make requirements of PCP, then either PCP >> needs to meet those requirements or not use EAP. so, I think we >> need to understand the general requirements to understand what >> our options are in PCP. Stefan> EAP does not make requirements for PCP in this case; the Stefan> question is left open in the RFC. Stefan> That is highly understandable, IMHO, because EAP is the Stefan> Extensible Authentication protocol; *authorisation* lifetime Stefan> is not something that's naturally covered. Right. And I'm asking to point out that this is not covered in the applicability statement. I think Klaas does a great job of explaining the situation and I'd like to work on adapting his message for text. >> So, would you be willing to explain why you believe PCP should >> decide on its requirements first and how you see that interacting >> with a later general discussion? Stefan> You described two courses of action: PCP can either make Stefan> applications decide on the authorization lifetime on their Stefan> own, or it can request that this lifetime information is Stefan> derived from EAP. Thanks for helping explain. I now understand my confusion and believe it was because I was unclear in my message. In my mind PCP was the application. I was arguing that here in ABFAB we have two courses of action: 1) Say that applications need to figure out authorization lifetime on their own. I favor this. 2) Say that as part of making EAP applicable to application authentication, we make requirements for all applications using EAP on authorization lifetime. I prefer the first option. --Sam From Josh.Howlett@ja.net Fri Oct 19 08:57:15 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EA121F8460 for ; Fri, 19 Oct 2012 08:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq-mCtWkcbJw for ; Fri, 19 Oct 2012 08:57:15 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 67F0321F845E for ; Fri, 19 Oct 2012 08:57:15 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 248EF20C711B_817859B; Fri, 19 Oct 2012 15:57:13 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 81BA920C70F6_817858F; Fri, 19 Oct 2012 15:57:12 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Fri, 19 Oct 2012 16:57:12 +0100 From: Josh Howlett To: Sam Hartman , Stefan Winter Thread-Topic: [abfab] EAP Applicability: Lifetime of Authorizations Thread-Index: AQHNrgJQWMBj1u55SEa9hi2gq1nLjJfAmiOAgAAbGrD///kuAIAAFkQdgAAEEYA= Date: Fri, 19 Oct 2012 15:57:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <899E92533E502C47A9F58B36ADE93DF2@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:57:16 -0000 > > > >1) Say that applications need to figure out authorization lifetime on >their own. >I favor this. +1 Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From yoshihiro.ohba@toshiba.co.jp Fri Oct 19 10:25:00 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C1C21F8793 for ; Fri, 19 Oct 2012 10:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.907 X-Spam-Level: X-Spam-Status: No, score=-4.907 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1O3-la76c5i for ; Fri, 19 Oct 2012 10:24:59 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5D94721F8794 for ; Fri, 19 Oct 2012 10:24:59 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q9JHOwcb016813 for ; Sat, 20 Oct 2012 02:24:58 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q9JHOwi2010929 for abfab@ietf.org; Sat, 20 Oct 2012 02:24:58 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id CAA10927; Sat, 20 Oct 2012 02:24:58 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q9JHOvvK019292 for ; Sat, 20 Oct 2012 02:24:57 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9JHOvqe013104; Sat, 20 Oct 2012 02:24:57 +0900 (JST) Received: from [133.199.16.146] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MC500ATKHPK9A80@mail.po.toshiba.co.jp> for abfab@ietf.org; Sat, 20 Oct 2012 02:24:57 +0900 (JST) Date: Sat, 20 Oct 2012 02:25:06 +0900 From: Yoshihiro Ohba In-reply-to: To: abfab@ietf.org Message-id: <50818CF2.1090902@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50815F47.3010608@restena.lu> <5081704A.5090504@restena.lu> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:25:00 -0000 I think the two options you provided below are two extremes. It is too restrictive to have a requirement on one of the two extremes. I can think of an application that can choose to follow AAA-associatied authorization lifetime or use its own (AAA-independent) lifetime depending on use case. Having said that I don't think we need to change EAP applicability text on this matter. Thanks, Yoshihiro Ohba (2012/10/20 0:40), Sam Hartman wrote: >>>>>> "Stefan" == Stefan Winter writes: > Stefan> Hi, > >> I'm confused by your message because I don't understand how PCP > >> can make the decision without understanding the EAP requirements. > >> > >> If EAP is going to make requirements of PCP, then either PCP > >> needs to meet those requirements or not use EAP. so, I think we > >> need to understand the general requirements to understand what > >> our options are in PCP. > > Stefan> EAP does not make requirements for PCP in this case; the > Stefan> question is left open in the RFC. > > Stefan> That is highly understandable, IMHO, because EAP is the > Stefan> Extensible Authentication protocol; *authorisation* lifetime > Stefan> is not something that's naturally covered. > > Right. And I'm asking to point out that this is not covered in the > applicability statement. > I think Klaas does a great job of explaining the situation and I'd like > to work on adapting his message for text. > > >> So, would you be willing to explain why you believe PCP should > >> decide on its requirements first and how you see that interacting > >> with a later general discussion? > > Stefan> You described two courses of action: PCP can either make > Stefan> applications decide on the authorization lifetime on their > Stefan> own, or it can request that this lifetime information is > Stefan> derived from EAP. > > Thanks for helping explain. > I now understand my confusion and believe it was because I was unclear > in my message. > In my mind PCP was the application. > I was arguing that here in ABFAB we have two courses of action: > > 1) Say that applications need to figure out authorization lifetime on > their own. > I favor this. > > 2) Say that as part of making EAP applicable to application > authentication, we make requirements for all applications using EAP on > authorization lifetime. > I prefer the first option. > > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From hartmans@painless-security.com Fri Oct 19 10:35:41 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BA521F87A6 for ; Fri, 19 Oct 2012 10:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.356 X-Spam-Level: **** X-Spam-Status: No, score=4.356 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD4yC52ztQjw for ; Fri, 19 Oct 2012 10:35:40 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3E83A21F870C for ; Fri, 19 Oct 2012 10:35:34 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9B4E92010B; Fri, 19 Oct 2012 13:35:17 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1A1784AD5; Fri, 19 Oct 2012 13:35:32 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <50815F47.3010608@restena.lu> <5081704A.5090504@restena.lu> <50818CF2.1090902@toshiba.co.jp> Date: Fri, 19 Oct 2012 13:35:32 -0400 In-Reply-To: <50818CF2.1090902@toshiba.co.jp> (Yoshihiro Ohba's message of "Sat, 20 Oct 2012 02:25:06 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:35:41 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> I think the two options you provided below are two Yoshihiro> extremes. It is too restrictive to have a requirement on Yoshihiro> one of the two extremes. I can think of an application Yoshihiro> that can choose to follow AAA-associatied authorization Yoshihiro> lifetime or use its own (AAA-independent) lifetime Yoshihiro> depending on use case. That's well within what I mean by option 1--leave it up to the application. One reasonable thing for applications to do in some usecases would be to depend on AAA. Would you be willing to review text to make sure we don't exclude this sort of thing? --Sam From yoshihiro.ohba@toshiba.co.jp Fri Oct 19 10:44:01 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3367721F8895 for ; Fri, 19 Oct 2012 10:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.873 X-Spam-Level: X-Spam-Status: No, score=-4.873 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DcuHVjDorhC for ; Fri, 19 Oct 2012 10:44:00 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98221F8862 for ; Fri, 19 Oct 2012 10:44:00 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q9JHhwXc018862; Sat, 20 Oct 2012 02:43:58 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q9JHhwjP015425; Sat, 20 Oct 2012 02:43:58 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id CAA15424; Sat, 20 Oct 2012 02:43:58 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q9JHhwV5022060; Sat, 20 Oct 2012 02:43:58 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9JHhwOF020334; Sat, 20 Oct 2012 02:43:58 +0900 (JST) Received: from [133.199.16.230] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MC500AW0IKY9A80@mail.po.toshiba.co.jp>; Sat, 20 Oct 2012 02:43:58 +0900 (JST) Date: Sat, 20 Oct 2012 02:43:57 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <5081915D.8070707@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50815F47.3010608@restena.lu> <5081704A.5090504@restena.lu> <50818CF2.1090902@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:44:01 -0000 (2012/10/20 2:35), Sam Hartman wrote: >>>>>> "Yoshihiro" == Yoshihiro Ohba writes: > Yoshihiro> I think the two options you provided below are two > Yoshihiro> extremes. It is too restrictive to have a requirement on > Yoshihiro> one of the two extremes. I can think of an application > Yoshihiro> that can choose to follow AAA-associatied authorization > Yoshihiro> lifetime or use its own (AAA-independent) lifetime > Yoshihiro> depending on use case. > > That's well within what I mean by option 1--leave it up to the > application. > One reasonable thing for applications to do in some usecases would be > to depend on AAA. OK. > > Would you be willing to review text to make sure we don't exclude this > sort of thing? I think "less is more" is the best stragegy here, i.e., no need to add text. Yoshihiro Ohba > > --Sam > From hartmans@painless-security.com Fri Oct 19 11:09:14 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF4E21F878A for ; Fri, 19 Oct 2012 11:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.355 X-Spam-Level: **** X-Spam-Status: No, score=4.355 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiTeFly3pwZA for ; Fri, 19 Oct 2012 11:09:14 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 135AE21F8799 for ; Fri, 19 Oct 2012 11:09:13 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 44B6120340; Fri, 19 Oct 2012 14:08:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6D2534AD5; Fri, 19 Oct 2012 14:09:11 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <50815F47.3010608@restena.lu> <5081704A.5090504@restena.lu> <50818CF2.1090902@toshiba.co.jp> <5081915D.8070707@toshiba.co.jp> Date: Fri, 19 Oct 2012 14:09:11 -0400 In-Reply-To: <5081915D.8070707@toshiba.co.jp> (Yoshihiro Ohba's message of "Sat, 20 Oct 2012 02:43:57 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:09:14 -0000 OK. If we're all agreed that it is clear I'm fine adding no text. However, Alper claimed that the EAP keying framework requires something close to option 2. It sounds like that's not my interpretation or your interpretation. If we think others might read things the same as Alper, then I think we should clarify things in the applicability statement. If we think that sort of reading is unlikely, I'm fine saying nothing. --Sam From yoshihiro.ohba@toshiba.co.jp Fri Oct 19 11:23:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED10621F85AE for ; Fri, 19 Oct 2012 11:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.842 X-Spam-Level: X-Spam-Status: No, score=-4.842 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fov4EuxuaXrN for ; Fri, 19 Oct 2012 11:23:52 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1C79121F851E for ; Fri, 19 Oct 2012 11:23:51 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q9JINpOD024192 for ; Sat, 20 Oct 2012 03:23:51 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q9JINper025567 for abfab@ietf.org; Sat, 20 Oct 2012 03:23:51 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id DAA25566; Sat, 20 Oct 2012 03:23:50 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q9JINoCg029065 for ; Sat, 20 Oct 2012 03:23:50 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9JINodW016989; Sat, 20 Oct 2012 03:23:50 +0900 (JST) Received: from [133.199.16.30] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MC500A8JKFE9A90@mail.po.toshiba.co.jp> for abfab@ietf.org; Sat, 20 Oct 2012 03:23:50 +0900 (JST) Date: Sat, 20 Oct 2012 03:23:49 +0900 From: Yoshihiro Ohba In-reply-to: To: abfab@ietf.org Message-id: <50819AB5.5000105@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:23:53 -0000 RFC 3748 also says: " When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as within [PIC]), the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. " This allows double-layer retransmissions in some cases. For example, EAP peer may be temporally busy and may have to discard received requests. In such a case, EAP-layer retransmissions on top of reliable lower layer can be useful. EAP retransmissions can be useful in some cases even with GSS-API, and I am wondering why GSS-EAP mandates option 2 (I am sorry for noticing this late). Having said that I don't think we need to add text on this matter. Thanks, Yoshihiro Ohba (2012/10/19 22:28), Sam Hartman wrote: > > Hi. Over in PCP we've been attempting to apply EAP to the application > authentication problem. My personal opinion is that GSS-EAP brings more > complexity than PCP needs. Three solutions are being considered: two > PANA-based solutions and one solution tuned for PCP. > > A few issues have come up where the requirements of EAP are unclear at > least to some participants. > > It seems to me like the EAP applicability update would be a great place > to cover these issues. > > The first is retransmission. > > As specified in RFC 3748, EAP handles retransmissions, and the EAP > authenticator is responsible for the retransmission. > > However, the EAP RFC allows a lower layer to set the retransmission > timeout to infinite. > > In terms of an applicability statement, I believe that applications > MUST choose one of the following options: > > 1) Have authenticator-initiated retransmissions at the EAP layer. > > 2) Set the timeout to infinite and require retransmissions at a lower > layer that is application specific. > > For example, since GSS-API provides reliability, we chose option 2 in > draft-ietf-abfab-gss-eap. This is particularly true because GSS-API > doesn't support the idea of unsolicited messages from server to client. > The applicability statement should point out that if applications choose > option 1 they need to be able to transmit messages from server to client > at any time during the authentication phase. > > If the WG agrees with this proposal I'll propose specific text. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From hartmans@painless-security.com Fri Oct 19 11:28:58 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7F621F8567 for ; Fri, 19 Oct 2012 11:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.354 X-Spam-Level: **** X-Spam-Status: No, score=4.354 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZEwJSZF62ml for ; Fri, 19 Oct 2012 11:28:57 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id C6CB421F8484 for ; Fri, 19 Oct 2012 11:28:57 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3DF6F20340; Fri, 19 Oct 2012 14:28:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A1EE54AD5; Fri, 19 Oct 2012 14:28:46 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <50819AB5.5000105@toshiba.co.jp> Date: Fri, 19 Oct 2012 14:28:46 -0400 In-Reply-To: <50819AB5.5000105@toshiba.co.jp> (Yoshihiro Ohba's message of "Sat, 20 Oct 2012 03:23:49 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:28:58 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> RFC 3748 also says: " When run over a reliable lower Yoshihiro> layer (e.g., EAP over ISAKMP/TCP, as within [PIC]), the Yoshihiro> authenticator retransmission timer SHOULD be set to an Yoshihiro> infinite value, so that retransmissions do not occur at Yoshihiro> the EAP layer. " Yoshihiro> This allows double-layer retransmissions in some cases. Yoshihiro> For example, EAP peer may be temporally busy and may have Yoshihiro> to discard received requests. In such a case, EAP-layer Yoshihiro> retransmissions on top of reliable lower layer can be Yoshihiro> useful. But would not actually happen if you set the timer to infinite. Yoshihiro> EAP retransmissions can be useful in some cases even with Yoshihiro> GSS-API, and I am wondering why GSS-EAP mandates option 2 Yoshihiro> (I am sorry for noticing this late). Because GSS-API requires each round trip be started by the initiator and receive at most one response from the acceptor. I.E. until the initiator sends another message, the acceptor cannot send anything. Yoshihiro> Having said that I don't think we need to add text on Yoshihiro> this matter. I actually think text on this point is quite important. It's easy to read RFC 3748 and assume that things need to be server-initiated in EAP. I think it's important to point out to people considering using EAP for their applications that if they take responsibility for retransmissions that the EAP messages can be client-driven. From yoshihiro.ohba@toshiba.co.jp Fri Oct 19 12:27:07 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D642221F8748 for ; Fri, 19 Oct 2012 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.813 X-Spam-Level: X-Spam-Status: No, score=-4.813 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2VK-VyfK0Aq for ; Fri, 19 Oct 2012 12:27:05 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1091121F874E for ; Fri, 19 Oct 2012 12:27:02 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q9JJQSZT029843; Sat, 20 Oct 2012 04:26:28 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q9JJQSGu006224; Sat, 20 Oct 2012 04:26:28 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id EAA06223; Sat, 20 Oct 2012 04:26:28 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q9JJQShR007431; Sat, 20 Oct 2012 04:26:28 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9JJQSti021692; Sat, 20 Oct 2012 04:26:28 +0900 (JST) Received: from [133.199.16.11] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MC500ALNNBS9A90@mail.po.toshiba.co.jp>; Sat, 20 Oct 2012 04:26:27 +0900 (JST) Date: Sat, 20 Oct 2012 04:26:26 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <5081A962.9070309@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50819AB5.5000105@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 19:27:07 -0000 Sam, (2012/10/20 3:28), Sam Hartman wrote: >>>>>> "Yoshihiro" == Yoshihiro Ohba writes: > Yoshihiro> RFC 3748 also says: " When run over a reliable lower > Yoshihiro> layer (e.g., EAP over ISAKMP/TCP, as within [PIC]), the > Yoshihiro> authenticator retransmission timer SHOULD be set to an > Yoshihiro> infinite value, so that retransmissions do not occur at > Yoshihiro> the EAP layer. " > > Yoshihiro> This allows double-layer retransmissions in some cases. > Yoshihiro> For example, EAP peer may be temporally busy and may have > Yoshihiro> to discard received requests. In such a case, EAP-layer > Yoshihiro> retransmissions on top of reliable lower layer can be > Yoshihiro> useful. > > But would not actually happen if you set the timer to infinite. > > Yoshihiro> EAP retransmissions can be useful in some cases even with > Yoshihiro> GSS-API, and I am wondering why GSS-EAP mandates option 2 > Yoshihiro> (I am sorry for noticing this late). > > Because GSS-API requires each round trip be started by the initiator and > receive at most one response from the acceptor. I.E. until the > initiator sends another message, the acceptor cannot send anything. I am rather seeing an issue here. What happens if an initiator has to discard a received EAP request for some reasons, e.g., lack of processing resource, the request is invalid due to message modification attack, etc.? How the request is retransmitted? > > Yoshihiro> Having said that I don't think we need to add text on > Yoshihiro> this matter. > > I actually think text on this point is quite important. It's easy to > read RFC 3748 and assume that things need to be server-initiated in EAP. > I think it's important to point out to people considering using EAP for > their applications that if they take responsibility for retransmissions > that the EAP messages can be client-driven. I think client-driven retransmission needs to be carefully designed. I am interested in seeing an answer for my question above. Yoshihiro Ohba From hartmans@painless-security.com Fri Oct 19 12:56:27 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD4521F87EE for ; Fri, 19 Oct 2012 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.353 X-Spam-Level: **** X-Spam-Status: No, score=4.353 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUhHEEFx4uXC for ; Fri, 19 Oct 2012 12:56:26 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA0E21F87EC for ; Fri, 19 Oct 2012 12:56:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 63C602010B; Fri, 19 Oct 2012 15:56:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D6B894AD5; Fri, 19 Oct 2012 15:56:19 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> Date: Fri, 19 Oct 2012 15:56:19 -0400 In-Reply-To: <5081A962.9070309@toshiba.co.jp> (Yoshihiro Ohba's message of "Sat, 20 Oct 2012 04:26:26 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 19:56:27 -0000 First I'm really excited that you're walking through this. By trying to explain this I've found some problems in how I'm thinking about the problem and have clarified my position significantly. To me, that's valuable. Also, in my mind the fact that the issue is complex enough that I've revised my understanding multiple times suggests there really is something here worth writing down once we reach clarity. >>>>> "Yoshihiro" == Yoshihiro Ohba writes: >> >> But would not actually happen if you set the timer to infinite. >> Yoshihiro> EAP retransmissions can be useful in some cases even with Yoshihiro> GSS-API, and I am wondering why GSS-EAP mandates option 2 Yoshihiro> (I am sorry for noticing this late). >> >> Because GSS-API requires each round trip be started by the >> initiator and receive at most one response from the acceptor. >> I.E. until the initiator sends another message, the acceptor >> cannot send anything. Yoshihiro> I am rather seeing an issue here. What happens if an Yoshihiro> initiator has to discard a received EAP request for some Yoshihiro> reasons, e.g., lack of processing resource, the request Yoshihiro> is invalid due to message modification attack, etc.? How Yoshihiro> the request is retransmitted? Hi. First, in writing this I've realized that I am incorrect when I describe GSS-EAP as client-driven retransmit. GSS-EAP is application-layer retransmit. So, GSS expects the application to provide reliable transport to it. Normally applications do this by running over TCP. In TCP, if a node discards a packet without acknowledging it, then it is retransmitted at the TCP layer. It's an error to discard a packet after acknowledging. If you're writing a sockets app, and you're using GSS-EAP inside TCP, then you shouldn't read from the socket if you're too busy. If your application runs over something like UDP, then yes designing retransmits is difficult. Clearly if you're providing generic retransmit capability, then the end sending a message needs to retransmit it. The question is how that retransmit is triggered. If you want the client to control the flow then here's roughly what I'd expect. 1) Client sends message. 2) If server has responded to that message already it retransmits its cached response. Server does not have a retransmit timer; it only responds when triggered by client. It does need to maintain a message in a buffer to retransmit. 3) If the server has not responded to the message before, it does respond and caches its response so it can be retransmitted. 4) Client has a retransmit timer if it doesn't receive a response to its message before the timer fires, it retransmits. Obviously exponential back-off etc applies. Also, note that you should never do this just for EAP. If you want retransmits for EAP, then use EAp's mechanisms for that. The point I want to capture for the applicability statement is that if your application already has a reliable layer over which it wants to run lock-step authentication, RFC 3748 permits you to turn off EAP retransmits. Once you do that the server will not send unsolicited messages in an ongoing EAP conversation. Because a lot of applications do have reliable layers over which they run lock-step authentication protocols without provision for unsolicited server messages, we should document that this does work. The question of server-initiated reauth is a separate issue that can also generate unsolicited server traffic. I think it's important to handle that issue separately. I can think of application protocols in which supporting server-initiated re-auth would be relatively easy but for which requiring EAP-layer retransmits would be a deal breaker. From yoshihiro.ohba@toshiba.co.jp Sun Oct 21 02:58:49 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D18A21F8967 for ; Sun, 21 Oct 2012 02:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.786 X-Spam-Level: X-Spam-Status: No, score=-6.786 tagged_above=-999 required=5 tests=[AWL=1.303, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAXslMotKNfo for ; Sun, 21 Oct 2012 02:58:48 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0F91221F896A for ; Sun, 21 Oct 2012 02:58:47 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q9L9wkkO004057; Sun, 21 Oct 2012 18:58:46 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q9L9wjEu003381; Sun, 21 Oct 2012 18:58:45 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id UAA03380; Sun, 21 Oct 2012 18:58:45 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q9L9wjw6021566; Sun, 21 Oct 2012 18:58:45 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9L9wji5001764; Sun, 21 Oct 2012 18:58:45 +0900 (JST) Received: from [133.199.16.125] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MC80002RMDL6700@mail.po.toshiba.co.jp>; Sun, 21 Oct 2012 18:58:45 +0900 (JST) Date: Sun, 21 Oct 2012 18:58:32 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <5083C748.5000004@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 09:58:49 -0000 There are two separate issues here. First, Regardless whether lower-layer provides reliabilty or not, I believe EAP-layer retransmissions can improve robustness against DoS attack by sending malformed EAP requests, which otherwise can stall the EAP conversation. EAP-layer retransmission is not needed if the lower-layer provides secure reliable transport of EAP, such as IKEv2. I am not an expert of GSS-API, but it would have been better if EAP-layer retrasnmissions were allowed in GSS-EAP. Second, Regarding peer-initiated lower-layer retransmission, it is characterized by authenticator lower-layer to retransmit an EAP request based on an external event of receiving a peer-initiated duplicate request, instead of use of an internal timer event. This means that if the peer lower-layer receives a lower-layer response carrying an EAP request (so the corresponding lower-layer request is no longer outstanding) and the EAP request is discarded by EAP peer layer for some reason, then the peer lower-layer will not retransmit the lower-layer request to serve as the external event for the authenticator lower-layer to retransmit the EAP request. As a result, if my understanding is correct, the EAP conversation will stall unless there is some additional mechanism that can keep the EAP conversation going. The issue is more significant for insecure lower-layers where attackers can inject malformed EAP requests. The issue is less significant for secure lower-layers such as IKEv2. I agree that this issue is complex. Note that PANA does not have this issue because it is based on authenticator-initiated lower layer retransmission. Hope this helps, Yoshihiro Ohba (2012/10/20 4:56), Sam Hartman wrote: > First I'm really excited that you're walking through this. By trying to > explain this I've found some problems in how I'm thinking about the > problem and have clarified my position significantly. To me, that's > valuable. Also, in my mind the fact that the issue is complex enough > that I've revised my understanding multiple times suggests there really > is something here worth writing down once we reach clarity. > >>>>>> "Yoshihiro" == Yoshihiro Ohba writes: > >> > >> But would not actually happen if you set the timer to infinite. > > >> > Yoshihiro> EAP retransmissions can be useful in some cases even with > Yoshihiro> GSS-API, and I am wondering why GSS-EAP mandates option 2 > Yoshihiro> (I am sorry for noticing this late). > >> > >> Because GSS-API requires each round trip be started by the > >> initiator and receive at most one response from the acceptor. > >> I.E. until the initiator sends another message, the acceptor > >> cannot send anything. > > Yoshihiro> I am rather seeing an issue here. What happens if an > Yoshihiro> initiator has to discard a received EAP request for some > Yoshihiro> reasons, e.g., lack of processing resource, the request > Yoshihiro> is invalid due to message modification attack, etc.? How > Yoshihiro> the request is retransmitted? > > Hi. > First, in writing this I've realized that I am incorrect when I describe > GSS-EAP as client-driven retransmit. > > GSS-EAP is application-layer retransmit. > > So, GSS expects the application to provide reliable transport to it. > Normally applications do this by running over TCP. In TCP, if a node > discards a packet without acknowledging it, then it is retransmitted at > the TCP layer. > It's an error to discard a packet after acknowledging. > > If you're writing a sockets app, and you're using GSS-EAP inside TCP, > then you shouldn't read from the socket if you're too busy. > > If your application runs over something like UDP, then yes designing > retransmits is difficult. > > Clearly if you're providing generic retransmit capability, then the > end sending a message needs to retransmit it. > The question is how that retransmit is triggered. > > If you want the client to control the flow then here's roughly what I'd > expect. > > 1) Client sends message. > > 2) If server has responded to that message already it retransmits its > cached response. Server does not have a retransmit timer; it only > responds when triggered by client. It does need to maintain a message in > a buffer to retransmit. > > 3) If the server has not responded to the message before, it does > respond and caches its response so it can be retransmitted. > > 4) Client has a retransmit timer if it doesn't receive a response to its > message before the timer fires, it retransmits. > > Obviously exponential back-off etc applies. > > Also, note that you should never do this just for EAP. If you want > retransmits for EAP, then use EAp's mechanisms for that. > The point I want to capture for the applicability statement is that if > your application already has a reliable layer over which it wants to run > lock-step authentication, RFC 3748 permits you to turn off EAP > retransmits. Once you do that the server will not send unsolicited > messages in an ongoing EAP conversation. > Because a lot of applications do have reliable layers over which they > run lock-step authentication protocols without provision for unsolicited > server messages, we should document that this does work. > > > > The question of server-initiated reauth is a separate issue that can > also generate unsolicited server traffic. I think it's important to > handle that issue separately. I can think of application protocols in > which supporting server-initiated re-auth would be relatively easy but > for which requiring EAP-layer retransmits would be a deal breaker. > From leifj@mnt.se Sun Oct 21 05:39:01 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16E621F849A for ; Sun, 21 Oct 2012 05:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLZ+Wfm53vqh for ; Sun, 21 Oct 2012 05:39:00 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 82CB221F8480 for ; Sun, 21 Oct 2012 05:38:59 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q9LCcs5Q017406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 21 Oct 2012 14:38:58 +0200 (CEST) Message-ID: <5083ECDE.4030601@mnt.se> Date: Sun, 21 Oct 2012 14:38:54 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 12:39:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > It seems to me like the EAP applicability update would be a great > place to cover these issues. Didn't we have the discussion on general vs specific eap applicability stmt for abfab already and decided we couldn't figure out a way to make sure a general applicability stmt would get enough review? Isn't this re-opening this issue? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCD7N4ACgkQ8Jx8FtbMZndwlwCeILK1UFuwAZkYHCondunheifE OUAAn1ryE/p6KdvmHv08c987KHcsAvsG =Nk9o -----END PGP SIGNATURE----- From alper.yegin@yegin.org Mon Oct 22 03:07:09 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E6021F8B03; Mon, 22 Oct 2012 03:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+Y3biSGU7iN; Mon, 22 Oct 2012 03:07:08 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7300621F89EC; Mon, 22 Oct 2012 03:07:08 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LyEBR-1TKh2J2VdN-015PtV; Mon, 22 Oct 2012 06:07:04 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Mon, 22 Oct 2012 13:06:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:jhPbu8Oj6KWdzEYlfaIoDuhMQrjQ4xqCIECf2LoJGHC +j92+N5fqRsq9PwkP2R9BgB9MBkY/UfKFRuAWYkQHPPxCQBeux S/qbKOoJfCbin68fVU9oj2GlNVMFL+D0SvKVJXAzb3RlCdqhwy fzyLvZDYVdO0j1hqlpBclxtSAmdQp+O/UMIYrpKIDgxrxmGR3Y 4hWfzq3YQkSaJkp5Hu/Lbed6cvNnKqApL5QFmiKdJMQbA/ad7Q gAZsTueGuzReLWEFUG5SjkgM2kA+oUGY/QoLLwm9HrrldUEc3A 0o+jMZC3e2bi2PNp7gdd2zr+CQtCanhM8XAoHhZaeJCD8ttiu+ sgIPEUJADxvn0dVl+3gxk0aJv2ewI3Sega2F2dfNss8V/mMZX2 wqfjjYMqw6qjw== Cc: radext@ietf.org, abfab@ietf.org, pcp-chairs@tools.ietf.org, emu@ietf.org, "Zhangdacheng \(Dacheng\)" , dime@ietf.org, eap@frascone.com Subject: [abfab] Tweaking EAP (RFC 3748) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 10:07:09 -0000 On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> Hi Sam, Please also share this discussion with EAP WG and = EMU > Alper> WG mailing lists. That's where the EAP expertise is and they > Alper> should chime in, given that you are proposing to modify EAP > Alper> applicability statement. >=20 > The eap applicability statement update is a charter item of > ABFAB. We've agreed it will be last called in EMU. > Since it's a work item of abfab, it should be discussed on that list. > You're certainly free to let people know that the discussion if taking > place, although we've done that several times before. Sam, The type of changes you are talking about are well beyond the = "applicability statement changes" that ABFAB is chartered to make. Now you are discussing how EAP can be executed in a client-driven style = (as opposed to network driven), how server-initiated EAP = re-authentication may not be supported, how authorization parameters = (especially the session lifetime) is not set by the AAA server.=20 We need EAP and AAA expertise to get involved in the discussion. Not = only when ABFAB WG thinks it is done, but especially from the get go. This, IMHO, is re-engineering EAP and associated AAA procedures. Alper From alper.yegin@yegin.org Mon Oct 22 03:56:46 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BBD21F8A10 for ; Mon, 22 Oct 2012 03:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiNoxXNykcuB for ; Mon, 22 Oct 2012 03:56:46 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id D850D21F8612 for ; Mon, 22 Oct 2012 03:56:45 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0McV0i-1Thv3o1ucq-00I6EF; Mon, 22 Oct 2012 06:56:44 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Mon, 22 Oct 2012 13:56:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <476420B3-CCB6-4FB2-ADCF-A368331AF1B7@yegin.org> References: <50815F47.3010608@restena.lu> <5081704A.5090504@restena.lu> <50818CF2.1090902@toshiba.co.jp> <5081915D.8070707@toshiba.co.jp> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:3+1BJQ3nUZ86EXlNJhPrUr+FT8SW9BYykQ30/mZEnX5 FiF3OaUledI+ZzWu0z9xyrC5D9dK4TDbz8JpYIjxhFX5xOyVvK SyHHqSpBkjRUEwnSC1UKORyc02wLKDGiJtPsLfhIea4oR5Ipw1 xQ5rj7ZbWtowP+vp6mmdBnEBc9ftWWfO3Y+pRUoMGjCGGlytDw JxlPNa1blgEp+1WBZt0f5iykfxKx+9696bUdSO02W7LfoFYX3S 6aCbTA0P39I42DsbrVFTKp4/IkHiWGhWcgeKjvvymlccy1R/Rc KWaqGCV8KHWwuU3EsACj4pNsQF+nfq+eASjpIYeXP7zV3RIgSv /igWheG0YsRYEqaOnFYgxeh1zj288ybUaFTFl9/CJ38p0kp3Wk NUYGaR1VQvlHA== Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 10:56:46 -0000 Like I said over PCP ML, the AAA message that delivers EAP Success and MSK also delivers the = authorized lifetime. This is one of the tasks of the = Authentication-"Authorization"-Accounting (AAA) server. To tell the NAS = for how long the authenticated entity is authorized to access the = requested service. The session lifetime can be set to this received value, or a smaller = value by the NAS and the authenticated client -- hopefully in a = coordinated way. The MSK lifetime is set to this value as well. Now, if someone tells me the NAS can set the lifetime value to anything = irrespective of the lifetime received from the AAA, then I say he's = using a centralized AA (authentication and accounting) server with = distributed A (Authorization). An interesting case, not typical but = doable. Someone may have a very special reason to do that. Regarding the application state that is created within the authorized = application session, yes I understand and agree that it may survive = beyond the authorized session. But that's very application specific. We = need to discuss that in the scope of specific applications. Alper On Oct 19, 2012, at 9:09 PM, Sam Hartman wrote: > OK. > If we're all agreed that it is clear I'm fine adding no text. > However, Alper claimed that the EAP keying framework requires = something > close to option 2. >=20 > It sounds like that's not my interpretation or your interpretation. > If we think others might read things the same as Alper, then I think = we > should clarify things in the applicability statement. > If we think that sort of reading is unlikely, I'm fine saying nothing. >=20 > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From aland@deployingradius.com Mon Oct 22 04:01:56 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE44D21F8B03 for ; Mon, 22 Oct 2012 04:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBedLA+8HZSd for ; Mon, 22 Oct 2012 04:01:55 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA21D21F8A2F for ; Mon, 22 Oct 2012 04:01:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 646CD2240563; Mon, 22 Oct 2012 13:01:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK3+6F8CBPg8; Mon, 22 Oct 2012 13:01:07 +0200 (CEST) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by power.freeradius.org (Postfix) with ESMTPSA id 0BBF72240274; Mon, 22 Oct 2012 13:01:07 +0200 (CEST) Message-ID: <50852772.4000308@deployingradius.com> Date: Mon, 22 Oct 2012 13:01:06 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alper Yegin References: <50815F47.3010608@restena.lu> <5081704A.5090504@restena.lu> <50818CF2.1090902@toshiba.co.jp> <5081915D.8070707@toshiba.co.jp> <476420B3-CCB6-4FB2-ADCF-A368331AF1B7@yegin.org> In-Reply-To: <476420B3-CCB6-4FB2-ADCF-A368331AF1B7@yegin.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:01:56 -0000 Alper Yegin wrote: > Now, if someone tells me the NAS can set the lifetime value to anything irrespective of the lifetime received from the AAA, then I say he's using a centralized AA (authentication and accounting) server with distributed A (Authorization). An interesting case, not typical but doable. Someone may have a very special reason to do that. NASes have always had "creative" interpretations of authorization policies coming from an AAA servers. So this behavior is well within the traditional AAA. > Regarding the application state that is created within the authorized application session, yes I understand and agree that it may survive beyond the authorized session. But that's very application specific. We need to discuss that in the scope of specific applications. I agree. I would phrase the difference as being either the ability to *do* something, or the ability to *have* something. Items like "session timeout" control the ability to have a session. Once the session is over, the ability goes away. Other items could be allowed to continue, even after the session has been finished. Alan DeKok. From hartmans@painless-security.com Mon Oct 22 05:51:02 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F0821F8A87; Mon, 22 Oct 2012 05:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.909 X-Spam-Level: X-Spam-Status: No, score=0.909 tagged_above=-999 required=5 tests=[AWL=3.508, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrcmBfjH27p0; Mon, 22 Oct 2012 05:51:01 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4B29921F8842; Mon, 22 Oct 2012 05:51:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 1A7632026C; Mon, 22 Oct 2012 08:50:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6B5CB4AD5; Mon, 22 Oct 2012 08:50:56 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> Date: Mon, 22 Oct 2012 08:50:56 -0400 In-Reply-To: <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> (Alper Yegin's message of "Mon, 22 Oct 2012 13:06:40 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, abfab@ietf.org, pcp-chairs@tools.ietf.org, emu@ietf.org, "Zhangdacheng \(Dacheng\)" , dime@ietf.org, eap@frascone.com Subject: Re: [abfab] Tweaking EAP (RFC 3748) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:51:02 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: >>>>>> "Alper" == Alper Yegin writes: >> Alper> Hi Sam, Please also share this discussion with EAP WG and EMU Alper> WG mailing lists. That's where the EAP expertise is and they Alper> should chime in, given that you are proposing to modify EAP Alper> applicability statement. >> >> The eap applicability statement update is a charter item of >> ABFAB. We've agreed it will be last called in EMU. Since it's a >> work item of abfab, it should be discussed on that list. You're >> certainly free to let people know that the discussion if taking >> place, although we've done that several times before. Alper> Sam, Alper> The type of changes you are talking about are well beyond the Alper> "applicability statement changes" that ABFAB is chartered to Alper> make. First, I definitely encourage you to involve anyone in any IETF WG discussion you believe will help form a better consensus. So, absolutely, encourage people who you believe should join the discussion to do so. I am a bit confused by your message, because I'm not discussing changing EAP, only discussing how some issues that seem relatively likely to come up will influence applying EAP authentication to application authentication. My intent is to document existing, potentially hard to understand aspects of EAP so that people can better apply EAP to their applications. Thanks, --Sam From hartmans@painless-security.com Mon Oct 22 05:55:01 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D035F21F8B87 for ; Mon, 22 Oct 2012 05:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.856 X-Spam-Level: X-Spam-Status: No, score=0.856 tagged_above=-999 required=5 tests=[AWL=3.455, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7z1+uANZ-kI for ; Mon, 22 Oct 2012 05:55:00 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id E8AE921F88D5 for ; Mon, 22 Oct 2012 05:54:59 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 05B4C20355; Mon, 22 Oct 2012 08:54:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4716C4AD5; Mon, 22 Oct 2012 08:54:55 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <5083ECDE.4030601@mnt.se> Date: Mon, 22 Oct 2012 08:54:55 -0400 In-Reply-To: <5083ECDE.4030601@mnt.se> (Leif Johansson's message of "Sun, 21 Oct 2012 14:38:54 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:55:01 -0000 >>>>> "Leif" == Leif Johansson writes: >> It seems to me like the EAP applicability update would be a great >> place to cover these issues. Leif> Didn't we have the discussion on general vs specific eap Leif> applicability stmt for abfab already and decided we couldn't Leif> figure out a way to make sure a general applicability stmt Leif> would get enough review? Isn't this re-opening this issue? Yes, we had that discussion. I actually think all the issues I'm bringing up would be kind of tricky to cover in a general applicability statement. It's precisely because they are scoped to using EAP for application authentication--which is ABFAB's scope--that I think we can address them. Remember ABFAB's scope is not GSS-EAP; we're scoped to using EAP authentication and AAA for application federation. GSS-EAP is the only method currently on our charter to do that. However, the applicability statement needs to be broad enough to cover the ABFAB scope, and I'm fairly sure ABFAB-specific is where we got in the EAP applicability scoping discussion. Am I misremembering that discussion? From internet-drafts@ietf.org Mon Oct 22 16:39:13 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508A421F8232; Mon, 22 Oct 2012 16:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Onim12mSDJLY; Mon, 22 Oct 2012 16:39:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BDC21F847F; Mon, 22 Oct 2012 16:39:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022233912.12271.697.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 16:39:12 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-arch-04.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:39:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : Application Bridging for Federated Access Beyond Web (AB= FAB) Architecture Author(s) : Josh Howlett Sam Hartman Hannes Tschofenig Eliot Lear Jim Schaad Filename : draft-ietf-abfab-arch-04.txt Pages : 45 Date : 2012-10-22 Abstract: Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use-cases: network and web-based access. However, the solutions to these use-cases that have been proposed and deployed tend to have few common building blocks in common. This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) and the Diameter protocol, the Generic Security Service (GSS), the GS2 family, the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-arch-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-arch-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alper.yegin@yegin.org Tue Oct 23 01:09:16 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D0321F8464; Tue, 23 Oct 2012 01:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leU1FS7HICmv; Tue, 23 Oct 2012 01:09:14 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 4975921F84B1; Tue, 23 Oct 2012 01:09:14 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MKHde-1TOvdh1gIA-0025Fn; Tue, 23 Oct 2012 04:08:33 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Tue, 23 Oct 2012 11:08:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <47A4DA97-971F-4292-98D7-FF28A9CAB88C@yegin.org> References: <6AB91560-84B9-4311-B383-95C0A01911E4@yegin.org> <81B15FE2-DD05-411B-A35B-0E0AB3E213A3@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:8yeC5v3uIkV11ucL5pEiYfjPbV6/f2fypAHjb2NVST0 geVIFTCbBDuhj83eim+SDdQjIgI0l/jpj11Txyi29qmH2IUgE+ dFVlITB/0YnWBWB1ka7vA9+M/gOi51biZf7CMVDx5AXttz193s j+M+9Ttd4QzlsiXuaHFWoeZUFCYHqkeaW3paXuHGFsVW5invpU GkzPw2V1niY2lJDeiEEXXoMIWHk84gdMioEHMcQYBomxXdj9zV Fv/Ea24uMFyXjYRBZSSiGi8cCGkt+ZuCvod+HoW8/I8qWzDlTe xCbNdLp8OOj8Fu7dbI16+NOLK9FcA+c5LEU5kj1rh48NcMUz/7 lDU8dcAf0b1s6PzeC+mOfIhDo8hV7D0stM/pJmxK8gHmyFbtFG SRXPZ2frzcwHw== Cc: radext@ietf.org, abfab@ietf.org, pcp-chairs@tools.ietf.org, emu@ietf.org, "Zhangdacheng \(Dacheng\)" , dime@ietf.org, eap@frascone.com Subject: Re: [abfab] [radext] Tweaking EAP (RFC 3748) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:09:16 -0000 >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: >=20 >>>>>>> "Alper" =3D=3D Alper Yegin writes: >>>=20 > Alper> Hi Sam, Please also share this discussion with EAP WG and = EMU > Alper> WG mailing lists. That's where the EAP expertise is and they > Alper> should chime in, given that you are proposing to modify EAP > Alper> applicability statement. >>>=20 >>> The eap applicability statement update is a charter item of >>> ABFAB. We've agreed it will be last called in EMU. Since it's a >>> work item of abfab, it should be discussed on that list. You're >>> certainly free to let people know that the discussion if taking >>> place, although we've done that several times before. >=20 > Alper> Sam, >=20 > Alper> The type of changes you are talking about are well beyond = the > Alper> "applicability statement changes" that ABFAB is chartered to > Alper> make. =20 >=20 > First, I definitely encourage you to involve anyone in any IETF WG > discussion you believe will help form a better consensus. > So, absolutely, encourage people who you believe should join the > discussion to do so. >=20 Good. Please remember to keep these groups updated as you progress the = discussion. > I am a bit confused by your message, because I'm not discussing = changing > EAP, only discussing how some issues that seem relatively likely to = come > up will influence applying EAP authentication to application > authentication. I captured the issues you are raising as below: > how EAP can be executed in a client-driven style (as opposed to = network driven), how server-initiated EAP re-authentication may not be = supported, how authorization parameters (especially the session = lifetime) is not set by the AAA server.=20 These have potential impact on the EAP layer, and EAP lower-layer (both = the EAP peer to EAP Authenticator leg, and the EAP Authenticator to EAP = Authentication Server leg [a.k.a, the AAA protocol]). We need to fully = understand the implications. These are not mere "applicability" issues.=20= The ABFAB applicability update in my understanding is nothing more than = removing the somewhat artificial constraints in RFC 3748 that was = blocking the use of EAP for anything other than network access = authentication. The types of issues you are discussing now are well = beyond that. > My intent is to document existing, potentially hard to understand > aspects of EAP so that people can better apply EAP to their > applications. >=20 Alper > Thanks, >=20 > --Sam > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From yoshihiro.ohba@toshiba.co.jp Wed Oct 24 00:15:01 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84A221F8D0E for ; Wed, 24 Oct 2012 00:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMWu-nmlQNWF for ; Wed, 24 Oct 2012 00:15:00 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id A254A21F8D09 for ; Wed, 24 Oct 2012 00:15:00 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q9O7EwEJ001300 for ; Wed, 24 Oct 2012 16:14:58 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q9O7EwL2013334 for abfab@ietf.org; Wed, 24 Oct 2012 16:14:58 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id SAA13332; Wed, 24 Oct 2012 16:14:58 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q9O7Ew2B004424 for ; Wed, 24 Oct 2012 16:14:58 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9O7EwpN010755; Wed, 24 Oct 2012 16:14:58 +0900 (JST) Received: from [133.199.18.41] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MCD00F8UYST86H0@mail.po.toshiba.co.jp> for abfab@ietf.org; Wed, 24 Oct 2012 16:14:58 +0900 (JST) Date: Wed, 24 Oct 2012 16:14:53 +0900 From: Yoshihiro Ohba In-reply-to: To: abfab@ietf.org Message-id: <5087956D.3020205@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 07:15:02 -0000 RFC 5247 discusses EAP re-authentication in several sections. Here is one part: " Where TSKs are derived from or are wrapped by exported EAP keying material, compromise of that exported EAP keying material implies compromise of TSKs. Therefore, if EAP keying material is considered stale, not only SHOULD EAP re-authentication be initiated, but also replacement of child keys, including TSKs. " Since EAP keying material can be considered stale by either peer or authenticator, it makes sense to support both peer-initiated and authenticator-initiated re-authentication. If an application protocol has a design restriction that prevents from suppporting authenticator-initiated re-authentication, then it is better to let each application specification have some text in their Security Considerations section to assess potential impact on the application due to lack of the functionality. Having said that I don't agree with having text like "applications MAY support server-initiated re-authentication" in EAP applicability statement. What we sould have in EAP applicability statement is that the key management framework described in RFC 5247 is applicable to both network access and application usage of EAP. Regards, Yoshihiro Ohba (2012/10/19 22:41), Sam Hartman wrote: > Second issue relates to EAP requirements surrounding server-initiated > re-authentication. We've had one claim that EAP lower layers MUST > support re-authentication initiated by the server. > > If that's true, we have kind of a big problem with GSS-EAP. > > As best I can tell though that's not true. RFC 3748 doesn't really talk > about server-initiated re-authentication. The RADIUS EAP support > doesn't seem to support it, and the COA informational RFC explicitly > says it cannot be used for re-authentication. The Diameter EAP > application says that if the lower layer supports EAP re-authentication > then the Diameter NAS MUST support re-authentication as well. > I have looked up citations for the above in a PCP discussion and am > happy to dig that all up if they would help anyone here. > > As best I can tell, the motivation for re-authentication is an > interesting different between network access and application > authentication. In network access, there is a significant disruption if > your connection drops and you have to re-authenticate before you can > send your next packet. > It's strongly desirable to re-authenticate before your lifetime expires. > (This doesn't speak to server-initiated re-auth, I realize) > > Some applications work like that. > However there are a lot of applications where the server can close the > connection and when the client wants to do the next thing, it will > re-authenticate at that time. > For example with SMTP, it's not going to be a big deal if the next time > I want to send mail it takes a bit longer because my server has closed a > connection to force me to reauthenticate. > > My recommendation is that the applicability statement should discuss > the issue of re-authentication. We should recommend that applications > that will be disrupted by authentication expiration have a mechanism > to re-authenticate while the existing authentication is still live. > > I think we need to say very little about server-initiated > re-authentication. I think we should say that applications MAY support > server-initiated re-authentication. If they do, then the server can send > authentication packets at any time. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From hartmans@painless-security.com Wed Oct 24 03:35:43 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661A421F8B86 for ; Wed, 24 Oct 2012 03:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.756 X-Spam-Level: X-Spam-Status: No, score=0.756 tagged_above=-999 required=5 tests=[AWL=3.355, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiqvU8D8DoVF for ; Wed, 24 Oct 2012 03:35:42 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8879C21F8A6A for ; Wed, 24 Oct 2012 03:35:41 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id D71CA20340; Wed, 24 Oct 2012 06:35:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1F20E412A; Wed, 24 Oct 2012 06:35:38 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <5087956D.3020205@toshiba.co.jp> Date: Wed, 24 Oct 2012 06:35:38 -0400 In-Reply-To: <5087956D.3020205@toshiba.co.jp> (Yoshihiro Ohba's message of "Wed, 24 Oct 2012 16:14:53 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:35:43 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> RFC 5247 discusses EAP re-authentication in several Yoshihiro> sections. Here is one part: Yoshihiro> " Where TSKs are derived from or are wrapped by exported Yoshihiro> EAP keying material, compromise of that exported EAP Yoshihiro> keying material implies compromise of TSKs. Therefore, Yoshihiro> if EAP keying material is considered stale, not only Yoshihiro> SHOULD EAP re-authentication be initiated, but also Yoshihiro> replacement of child keys, including TSKs. " Yoshihiro> Since EAP keying material can be considered stale by Yoshihiro> either peer or authenticator, it makes sense to support Yoshihiro> both peer-initiated and authenticator-initiated Yoshihiro> re-authentication. If an application protocol has a Yoshihiro> design restriction that prevents from suppporting Yoshihiro> authenticator-initiated re-authentication, then it is Yoshihiro> better to let each application specification have some Yoshihiro> text in their Security Considerations section to assess Yoshihiro> potential impact on the application due to lack of the Yoshihiro> functionality. A few points. First, I agree with you that stale keying is an important thing to consider when integrating EAP into an application. So, I think we should make sure applications have the advice they need with regard to this topic. I also agree with you that the keying framework applies. However, we disagree about the need to discuss application-specific issues. Here are some things to consider: 1) If your application uses TLS for confidentiality and integrity, say because it uses EAP with the eap-aes128 SASL mechanism, then compromise of the MSK does not affect traffic keys for your application. If the MSK was compromised at time of generation--say because a long-term password was compromised--then your entire authentication is compromised. If on the other hand the MSK is compromised after authentication, no harm appears to be done in this case. 2) The EAP keying framework is written in the context of network access. In that context, shutting down a session in response to needing to re-key is a disruptive event. However, for something like SMTP, it seems entirely reasonable to just take down the session, which the server can do at an appropriate sequence point. If the client still wants to talk it will reconnect. There are actually a number of applications that work this way. 3) As you point out, if an application doesn't have a way to respond to key compromise, there are likely to be security considerations. One thing applicability statements often do is point out security issues people should consider when applying a technology. Especially where application use differs from network access use, we should document that sort of thing. Various aspects of the "detailed security analysis" provided by RFC 5247 are different, or the common assumptions are different for applications rather than network access. This is why you can't just change the one sentence in section 1.3 of RFC 3748 and be done. In conclusion, thanks for pointing out the really interesting issue of key compromise. We'll want to handle that. From hartmans@painless-security.com Wed Oct 24 04:02:57 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5312221F88B5 for ; Wed, 24 Oct 2012 04:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.708 X-Spam-Level: X-Spam-Status: No, score=0.708 tagged_above=-999 required=5 tests=[AWL=3.307, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfg4K+lVhhFk for ; Wed, 24 Oct 2012 04:02:56 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5A78921F88A7 for ; Wed, 24 Oct 2012 04:02:56 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 23D8320167; Wed, 24 Oct 2012 07:02:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 10C56412A; Wed, 24 Oct 2012 07:02:53 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> Date: Wed, 24 Oct 2012 07:02:53 -0400 In-Reply-To: <5083C748.5000004@toshiba.co.jp> (Yoshihiro Ohba's message of "Sun, 21 Oct 2012 18:58:32 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 11:02:57 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> There are two separate issues here. First, Regardless Yoshihiro> whether lower-layer provides reliabilty or not, I believe Yoshihiro> EAP-layer retransmissions can improve robustness against Yoshihiro> DoS attack by sending malformed EAP requests, which Yoshihiro> otherwise can stall the EAP conversation. EAP-layer Yoshihiro> retransmission is not needed if the lower-layer provides Yoshihiro> secure reliable transport of EAP, such as IKEv2. I am Yoshihiro> not an expert of GSS-API, but it would have been better Yoshihiro> if EAP-layer retrasnmissions were allowed in GSS-EAP. We both agree that a reliable lower layer needs to be sufficient to deal with network problems. As I understand it, we're exploring the case where retransmissions would deal with an attacker. So, I think what you're saying is that if an implementation performs a retransmit when it gets a malicious packet, it can be more robust. We're presumably talking about an attacker that can insert packets but not modify them or suppress them. An attacker who can modify or suppress packets can fairly clearly DOS the EAP conversation. If nothing else, they can simply make sure the packet is always corrupted. For this to be valuable there need to be EAP methods that are robust under EAP-layer retransmission but not other higher-layer retransmission. It's not good enough for EAP layer retransmissions to help with some packets in a method if it doesn't help with others. If there's some packet an attacker can easily send that will break the conversation, the method is not robust under EAP layer transmission. For example it wouldn't be particularly valuable if EAP layer retransmission protects against garbled packets but not packets with unknown critical options added, because an attacker could easily add an unknown critical option. I then started to consider the existing EAP methods. I am not able to think of an EAP method that is robust under EAP layer retransmission. I think you can fairly consistently break an EAP conversation by inserting packets. The most obvious thing to try is an EAP failure packet, then an EAP NACK. I also quickly considered methods like GPSK and TLS-based methods, and am fairly sure those are not robust either. So, would you be willing to pick an EAP method that is robust and go through a fairly detailed argument about how insertion DOS attacks are avoided? Yoshihiro> Second, Regarding peer-initiated lower-layer Yoshihiro> retransmission, it is characterized by authenticator Yoshihiro> lower-layer to retransmit an EAP request based on an Yoshihiro> external event of receiving a peer-initiated duplicate Yoshihiro> request, instead of use of an internal timer event. This Yoshihiro> means that if the peer lower-layer receives a lower-layer Yoshihiro> response carrying an EAP request (so the corresponding Yoshihiro> lower-layer request is no longer outstanding) and the EAP Yoshihiro> request is discarded by EAP peer layer for some reason, Yoshihiro> then the peer lower-layer will not retransmit the Yoshihiro> lower-layer request to serve as the external event for Yoshihiro> the authenticator lower-layer to retransmit the EAP Yoshihiro> request. As a result, if my understanding is correct, the Yoshihiro> EAP conversation will stall unless there is some Yoshihiro> additional mechanism that can keep the EAP conversation Yoshihiro> going. The issue is more significant for insecure Yoshihiro> lower-layers where attackers can inject malformed EAP Yoshihiro> requests. The issue is less significant for secure Yoshihiro> lower-layers such as IKEv2. I agree that this issue is Yoshihiro> complex. Note that PANA does not have this issue because Yoshihiro> it is based on authenticator-initiated lower layer Yoshihiro> retransmission. It's absolutely true that if a peer discards an EAP request in such a scheme, the conversation stalls. If you're introducing that into an application, that would decrease robustness. There are a lot of TCP applications though where it is a violation of a protocol to discard a message. LDAP clients do not just get to ignore a SASL challenge or any other non-authentication protocol message. If an IMAP client ignores the capability response (happens before authentication), things will stall. If your application already depends on people not discarding responses, depending on that for authentication is fine. I think more or less all of our security layers are vulnerable to DOS attacks from people inserting or modifying their negotiations. The only thing I can think of that clearly does not have this vulnerability is statically keyed TCP-AO or IPSec. I'm fairly sure very little of anything we standardize gives the robustness you're looking for. From alper.yegin@yegin.org Wed Oct 24 04:11:58 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C9821F8B14 for ; Wed, 24 Oct 2012 04:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9d4R+JYco6C1 for ; Wed, 24 Oct 2012 04:11:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6636D21F8918 for ; Wed, 24 Oct 2012 04:11:57 -0700 (PDT) Received: from [192.168.2.2] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LhOBc-1T4taZ15uK-00mxbz; Wed, 24 Oct 2012 07:11:55 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Wed, 24 Oct 2012 14:11:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1AA88C76-9771-4443-B4CA-44ACF59F628A@yegin.org> References: <5087956D.3020205@toshiba.co.jp> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:XCvTNSs3giM4F1VvjNefq3nKI0iZNB66f+fS0AgPkFW 3oIbHMla19B02kMylwGRiLZyi1jy1rhpc0c5QEGRSyVJdXL2wM K3FttGi7JhzVKnn1u5v8pss9FpXbwmD4mOVCI9Q7jRp7rGPSJy 5/Q+gTOLSDteatLzmYxG0JQWlAOTIdL1K9Vwzvx11EOTuHqAKH DmC3QHAiokSjUyPCgdj9Q+EuvBQ5Tz86NWJkEVvDTknX/OmFnr ljO1v5X170HjDIghNC9ZeXWodAuyEnFd+3XW+LWsQdbi7+MAmL 1mG04ZRavaow4aDFgD43OfGj1g8PxgXdntHBERPcI+LU2Afu0V cJCXDCEM0QUKussgcmAVqsLzMGRPuK/lM7yoaNobyr6GkE2pQK 0XVLHopy5hUmQ== Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 11:11:58 -0000 Sam, I recommend starting from identifying what aspects of "applications" are = different from "network access", and how such differences play into EAP. Below you are talking about one such difference.=20 (In that, in my understanding, you are OK with server initiated re-auth = for network access, but you think this is not needed for applications.=20= What is the root cause of this difference? ) There may be other differences.=20 Alper On Oct 24, 2012, at 1:35 PM, Sam Hartman wrote: >>>>>> "Yoshihiro" =3D=3D Yoshihiro Ohba = writes: >=20 > Yoshihiro> RFC 5247 discusses EAP re-authentication in several > Yoshihiro> sections. Here is one part: >=20 > Yoshihiro> " Where TSKs are derived from or are wrapped by exported > Yoshihiro> EAP keying material, compromise of that exported EAP > Yoshihiro> keying material implies compromise of TSKs. Therefore, > Yoshihiro> if EAP keying material is considered stale, not only > Yoshihiro> SHOULD EAP re-authentication be initiated, but also > Yoshihiro> replacement of child keys, including TSKs. " >=20 > Yoshihiro> Since EAP keying material can be considered stale by > Yoshihiro> either peer or authenticator, it makes sense to support > Yoshihiro> both peer-initiated and authenticator-initiated > Yoshihiro> re-authentication. If an application protocol has a > Yoshihiro> design restriction that prevents from suppporting > Yoshihiro> authenticator-initiated re-authentication, then it is > Yoshihiro> better to let each application specification have some > Yoshihiro> text in their Security Considerations section to assess > Yoshihiro> potential impact on the application due to lack of the > Yoshihiro> functionality. >=20 > A few points. >=20 > First, I agree with you that stale keying is an important thing to > consider when integrating EAP into an application. > So, I think we should make sure applications have the advice they need > with regard to this topic. >=20 > I also agree with you that the keying framework applies. >=20 > However, we disagree about the need to discuss application-specific > issues. > Here are some things to consider: >=20 > 1) If your application uses TLS for confidentiality and integrity, say > because it uses EAP with the eap-aes128 SASL mechanism, then = compromise > of the MSK does not affect traffic keys for your application. If the > MSK was compromised at time of generation--say because a long-term > password was compromised--then your entire authentication is > compromised. > If on the other hand the MSK is compromised after authentication, no > harm appears to be done in this case. >=20 > 2) The EAP keying framework is written in the context of network > access. In that context, shutting down a session in response to = needing > to re-key is a disruptive event. However, for something like SMTP, it > seems entirely reasonable to just take down the session, which the > server can do at an appropriate sequence point. If the client still > wants to talk it will reconnect. There are actually a number of > applications that work this way. >=20 > 3) As you point out, if an application doesn't have a way to respond = to > key compromise, there are likely to be security considerations. > One thing applicability statements often do is point out security = issues > people should consider when applying a technology. >=20 > Especially where application use differs from network access use, we > should document that sort of thing.=20 >=20 > Various aspects of the "detailed security analysis" provided by RFC = 5247 > are different, or the common assumptions are different for = applications > rather than network access. > This is why you can't just change the one sentence in section 1.3 of = RFC > 3748 and be done. >=20 > In conclusion, thanks for pointing out the really interesting issue of > key compromise. We'll want to handle that. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From yoshihiro.ohba@toshiba.co.jp Wed Oct 24 05:37:25 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEC821F8A2F for ; Wed, 24 Oct 2012 05:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[AWL=1.199, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctmPFQ6MZFzp for ; Wed, 24 Oct 2012 05:37:25 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id B7D5321F8A2A for ; Wed, 24 Oct 2012 05:37:24 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q9OCbMmd002735; Wed, 24 Oct 2012 21:37:22 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q9OCbMw9017170; Wed, 24 Oct 2012 21:37:22 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id XAA17169; Wed, 24 Oct 2012 21:37:22 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q9OCbMfF020656; Wed, 24 Oct 2012 21:37:22 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9OCbL28018208; Wed, 24 Oct 2012 21:37:21 +0900 (JST) Received: from [133.199.16.209] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MCE005R2DQ4G320@mail.po.toshiba.co.jp>; Wed, 24 Oct 2012 21:37:21 +0900 (JST) Date: Wed, 24 Oct 2012 21:37:16 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <5087E0FC.7090000@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 12:37:25 -0000 Sam, EAP-IKEv2 supports silent discarsion. Yoshihiro Ohba (2012/10/24 20:02), Sam Hartman wrote: >>>>>> "Yoshihiro" == Yoshihiro Ohba writes: > Yoshihiro> There are two separate issues here. First, Regardless > Yoshihiro> whether lower-layer provides reliabilty or not, I believe > Yoshihiro> EAP-layer retransmissions can improve robustness against > Yoshihiro> DoS attack by sending malformed EAP requests, which > Yoshihiro> otherwise can stall the EAP conversation. EAP-layer > Yoshihiro> retransmission is not needed if the lower-layer provides > Yoshihiro> secure reliable transport of EAP, such as IKEv2. I am > Yoshihiro> not an expert of GSS-API, but it would have been better > Yoshihiro> if EAP-layer retrasnmissions were allowed in GSS-EAP. > > We both agree that a reliable lower layer needs to be sufficient to deal > with network problems. > > As I understand it, we're exploring the case where retransmissions would > deal with an attacker. > So, I think what you're saying is that if an implementation performs a > retransmit when it gets a malicious packet, it can be more robust. > > We're presumably talking about an attacker that can insert packets but > not modify them or suppress them. > An attacker who can modify or suppress packets can fairly clearly DOS > the EAP conversation. > If nothing else, they can simply make sure the packet is always > corrupted. > > For this to be valuable there need to be EAP methods that are robust > under EAP-layer retransmission but not other higher-layer > retransmission. > It's not good enough for EAP layer retransmissions to help with some > packets in a method if it doesn't help with others. If there's some > packet an attacker can easily send that will break the conversation, the method > is not robust under EAP layer transmission. > For example it wouldn't be particularly valuable if EAP layer > retransmission protects against garbled packets but not packets with > unknown critical options added, because an attacker could easily add an > unknown critical option. > > I then started to consider the existing EAP methods. > I am not able to think of an EAP method that is robust under EAP layer > retransmission. I think you can fairly consistently break an EAP > conversation by inserting packets. > The most obvious thing to try is an EAP failure packet, then an EAP > NACK. > I also quickly considered methods like GPSK and TLS-based methods, and > am fairly sure those are not robust either. > So, would you be willing to pick an EAP method that is robust and go > through a fairly detailed argument about how insertion DOS attacks are > avoided? > > > > Yoshihiro> Second, Regarding peer-initiated lower-layer > Yoshihiro> retransmission, it is characterized by authenticator > Yoshihiro> lower-layer to retransmit an EAP request based on an > Yoshihiro> external event of receiving a peer-initiated duplicate > Yoshihiro> request, instead of use of an internal timer event. This > Yoshihiro> means that if the peer lower-layer receives a lower-layer > Yoshihiro> response carrying an EAP request (so the corresponding > Yoshihiro> lower-layer request is no longer outstanding) and the EAP > Yoshihiro> request is discarded by EAP peer layer for some reason, > Yoshihiro> then the peer lower-layer will not retransmit the > Yoshihiro> lower-layer request to serve as the external event for > Yoshihiro> the authenticator lower-layer to retransmit the EAP > Yoshihiro> request. As a result, if my understanding is correct, the > Yoshihiro> EAP conversation will stall unless there is some > Yoshihiro> additional mechanism that can keep the EAP conversation > Yoshihiro> going. The issue is more significant for insecure > Yoshihiro> lower-layers where attackers can inject malformed EAP > Yoshihiro> requests. The issue is less significant for secure > Yoshihiro> lower-layers such as IKEv2. I agree that this issue is > Yoshihiro> complex. Note that PANA does not have this issue because > Yoshihiro> it is based on authenticator-initiated lower layer > Yoshihiro> retransmission. > > It's absolutely true that if a peer discards an EAP request in such a > scheme, the conversation stalls. > If you're introducing that into an application, that would decrease > robustness. > There are a lot of TCP applications though where it is a violation of a > protocol to discard a message. LDAP clients do not just get to ignore a > SASL challenge or any other non-authentication protocol message. > If an IMAP client ignores the capability response (happens before > authentication), things will stall. > If your application already depends on people not discarding responses, > depending on that for authentication is fine. > > I think more or less all of our security layers are vulnerable to DOS > attacks from people inserting or modifying their negotiations. > The only thing I can think of that clearly does not have this > vulnerability is statically keyed TCP-AO or IPSec. > I'm fairly sure very little of anything we standardize gives the > robustness you're looking for. > From yoshihiro.ohba@toshiba.co.jp Wed Oct 24 06:16:03 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397B221F8B3E for ; Wed, 24 Oct 2012 06:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[AWL=1.187, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoSTMvJz+YXd for ; Wed, 24 Oct 2012 06:16:02 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id C85D321F8B3D for ; Wed, 24 Oct 2012 06:16:01 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q9ODG0ZA008819; Wed, 24 Oct 2012 22:16:00 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q9ODG0Q5027373; Wed, 24 Oct 2012 22:16:00 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA27372; Wed, 24 Oct 2012 22:16:00 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q9ODG0SZ027210; Wed, 24 Oct 2012 22:16:00 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9ODG09u018221; Wed, 24 Oct 2012 22:16:00 +0900 (JST) Received: from [133.199.17.18] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MCE005CBFIIG330@mail.po.toshiba.co.jp>; Wed, 24 Oct 2012 22:16:00 +0900 (JST) Date: Wed, 24 Oct 2012 22:15:54 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <5087EA0A.5050504@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 13:16:03 -0000 Sam, > I also quickly considered methods like GPSK and TLS-based methods, and > am fairly sure those are not robust either. I also checked EAP-GPSK and it supports silent discarsion. Yoshihiro Ohba From klaas@cisco.com Thu Oct 25 02:47:11 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE68221F89A9 for ; Thu, 25 Oct 2012 02:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqytcA6FOXnm for ; Thu, 25 Oct 2012 02:47:11 -0700 (PDT) Received: from out25-ams.mf.surf.net (out25-ams.mf.surf.net [145.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF5321F89A0 for ; Thu, 25 Oct 2012 02:47:04 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9P9l2rS018137 for ; Thu, 25 Oct 2012 11:47:02 +0200 Received: from 128-107-239-233.cisco.com ([128.107.239.233] helo=sjc-vpn4-657.cisco.com) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TRJwp-00057s-9o for abfab@ietf.org; Thu, 25 Oct 2012 11:41:55 +0200 From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Thu, 25 Oct 2012 11:47:39 +0200 To: "" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uIflL2Xp - dc53987829c8 - 20121025 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [abfab] Abfab @ IETF85 agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 09:47:12 -0000 Hi, I have just uploaded the following agenda: Abfab MONDAY, November 5, 2012 1300-1500 Salon B ----------------------------------------------------------- - Agenda Bashing and Note Well (Chairs, 5 min) - Document status * EAP Applicability (Joe Salowey, 10 min) * Architecture Draft (Jim Schaad, 20 min) - Milestones and remaining document status (Chairs, 10 min) - Open Mic (All, 45 min) If you want a slot on the agenda as well please let us know. Klaas & Leif From hartmans@painless-security.com Thu Oct 25 03:20:52 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B34D21F8992 for ; Thu, 25 Oct 2012 03:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.53 X-Spam-Level: X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=3.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSIbuEQs8x07 for ; Thu, 25 Oct 2012 03:20:48 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C3F5D21F89AF for ; Thu, 25 Oct 2012 03:20:47 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 4683920180; Thu, 25 Oct 2012 06:20:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1172C412A; Thu, 25 Oct 2012 06:20:45 -0400 (EDT) From: Sam Hartman To: Klaas Wierenga References: Date: Thu, 25 Oct 2012 06:20:45 -0400 In-Reply-To: (Klaas Wierenga's message of "Thu, 25 Oct 2012 11:47:39 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "" Subject: Re: [abfab] Abfab @ IETF85 agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 10:20:52 -0000 I'd like a slot for my EAP applicability comments; I'm happy to coordinate with the chairs an authors on how to organize it. Josh and I are discussing aaa-saml tomorrow and figuring out what needs group discussion. Jim, or others are there specific issues you'd like us to discuss in person? From kwiereng@cisco.com Thu Oct 25 04:03:05 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BD621F8992 for ; Thu, 25 Oct 2012 04:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mge3LoqXZoRl for ; Thu, 25 Oct 2012 04:03:04 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4965621F893C for ; Thu, 25 Oct 2012 04:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=517; q=dns/txt; s=iport; t=1351162984; x=1352372584; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YoPkgVRMNq3y9eX8Hn7L5nym7DB6mEymUzrQFL0Z+XY=; b=l0yuGeMUulCyRUcZrKgItIeSDKHxPxs+uSyUDwgTbJW1TmWz0aeE1NiX 701F9cSWqBawkKdQZGkVCuemULFeWz8H98nTHcvurIN1OFP4z8AXYfrIm GyErtB1pzXlrIAztdN6sIBi6R/d1CqZ9qWKP5E8Wt08Oz2zJlsZCKMwss 0=; X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="132228681" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 25 Oct 2012 11:03:04 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9PB33w8019949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Oct 2012 11:03:04 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 06:03:03 -0500 From: "Klaas Wierenga (kwiereng)" To: Sam Hartman Thread-Topic: [abfab] Abfab @ IETF85 agenda Thread-Index: AQHNspW4x7A5VKQIPE+D4MCtvtmVJ5fJz6RggAALytM= Date: Thu, 25 Oct 2012 11:03:02 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19306.000 x-tm-as-result: No--37.025500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [abfab] Abfab @ IETF85 agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 11:03:05 -0000 Sam, That is why I put the EAP applicability draft on the agenda ;-) Klaas Sent from my iPhone On 25 okt. 2012, at 12:20, "Sam Hartman" w= rote: > I'd like a slot for my EAP applicability comments; I'm happy to > coordinate with the chairs an authors on how to organize it. >=20 >=20 > Josh and I are discussing aaa-saml tomorrow and figuring out what needs > group discussion. > Jim, or others are there specific issues you'd like us to discuss in > person? From ietf@augustcellars.com Thu Oct 25 09:17:20 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4119021F8869 for ; Thu, 25 Oct 2012 09:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdydbJEGppVo for ; Thu, 25 Oct 2012 09:17:19 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF4A21F879C for ; Thu, 25 Oct 2012 09:17:19 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 49AE62CA11; Thu, 25 Oct 2012 09:17:19 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "'Klaas Wierenga'" References: In-Reply-To: Date: Thu, 25 Oct 2012 09:15:46 -0700 Message-ID: <03eb01cdb2cb$fe170880$fa451980$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHOe2ToEDX3cHLVY0GAVw/fI6P0ewKYa1Tfl7Pdx2A= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Abfab @ IETF85 agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:17:20 -0000 I am sure there are, but I have not yet had time to scan the draft > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Thursday, October 25, 2012 3:21 AM > To: Klaas Wierenga > Cc: > Subject: Re: [abfab] Abfab @ IETF85 agenda > > I'd like a slot for my EAP applicability comments; I'm happy to coordinate with > the chairs an authors on how to organize it. > > > Josh and I are discussing aaa-saml tomorrow and figuring out what needs > group discussion. > Jim, or others are there specific issues you'd like us to discuss in person? > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Thu Oct 25 20:11:24 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA98B21F84B5 for ; Thu, 25 Oct 2012 20:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.343 X-Spam-Level: X-Spam-Status: No, score=-3.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X77HhHqnvdra for ; Thu, 25 Oct 2012 20:11:24 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2D69321F8481 for ; Thu, 25 Oct 2012 20:11:24 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id B221A38F0E; Thu, 25 Oct 2012 20:11:23 -0700 (PDT) From: "Jim Schaad" To: "'Yoshihiro Ohba'" , "'Sam Hartman'" References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> In-Reply-To: <5087E0FC.7090000@toshiba.co.jp> Date: Thu, 25 Oct 2012 20:09:50 -0700 Message-ID: <040b01cdb327$5d166e60$17434b20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEZytxIIaFEdNJhDJM7vx/kOAZ2BwGjPaFHAqnWy/gBl88lagJaWb/DAf3zB/YB3x+6vwFe2PVXmMbfIMA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 03:11:25 -0000 I have been looking at TEAP and am worried about silent discarding of packets. Since in the ABFAB environment, it is assumed that the transport is reliable, there is a possibility that a difference of opinion about what constitutes a good packet between the server and the client could cause a dead-lock situation in the protocol. For TEAP, it says that you silently discard if the flags are wrong, but if the server and the client disagree if the EAP length field should be present then the server will discard and the client will wait forever for a response. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Yoshihiro Ohba > Sent: Wednesday, October 24, 2012 5:37 AM > To: Sam Hartman > Cc: abfab@ietf.org > Subject: Re: [abfab] EAP Applicability: retransmissions > > Sam, > > EAP-IKEv2 supports silent discarsion. > > Yoshihiro Ohba > > > (2012/10/24 20:02), Sam Hartman wrote: > >>>>>> "Yoshihiro" == Yoshihiro Ohba > writes: > > Yoshihiro> There are two separate issues here. First, Regardless > > Yoshihiro> whether lower-layer provides reliabilty or not, I believe > > Yoshihiro> EAP-layer retransmissions can improve robustness against > > Yoshihiro> DoS attack by sending malformed EAP requests, which > > Yoshihiro> otherwise can stall the EAP conversation. EAP-layer > > Yoshihiro> retransmission is not needed if the lower-layer provides > > Yoshihiro> secure reliable transport of EAP, such as IKEv2. I am > > Yoshihiro> not an expert of GSS-API, but it would have been better > > Yoshihiro> if EAP-layer retrasnmissions were allowed in GSS-EAP. > > > > We both agree that a reliable lower layer needs to be sufficient to deal > > with network problems. > > > > As I understand it, we're exploring the case where retransmissions > > would deal with an attacker. > > So, I think what you're saying is that if an implementation performs a > > retransmit when it gets a malicious packet, it can be more robust. > > > > We're presumably talking about an attacker that can insert packets but > > not modify them or suppress them. > > An attacker who can modify or suppress packets can fairly clearly DOS > > the EAP conversation. > > If nothing else, they can simply make sure the packet is always > > corrupted. > > > > For this to be valuable there need to be EAP methods that are robust > > under EAP-layer retransmission but not other higher-layer > > retransmission. > > It's not good enough for EAP layer retransmissions to help with some > > packets in a method if it doesn't help with others. If there's some > > packet an attacker can easily send that will break the conversation, > > the method is not robust under EAP layer transmission. > > For example it wouldn't be particularly valuable if EAP layer > > retransmission protects against garbled packets but not packets with > > unknown critical options added, because an attacker could easily add > > an unknown critical option. > > > > I then started to consider the existing EAP methods. > > I am not able to think of an EAP method that is robust under EAP layer > > retransmission. I think you can fairly consistently break an EAP > > conversation by inserting packets. > > The most obvious thing to try is an EAP failure packet, then an EAP > > NACK. > > I also quickly considered methods like GPSK and TLS-based methods, and > > am fairly sure those are not robust either. > > So, would you be willing to pick an EAP method that is robust and go > > through a fairly detailed argument about how insertion DOS attacks are > > avoided? > > > > > > > > Yoshihiro> Second, Regarding peer-initiated lower-layer > > Yoshihiro> retransmission, it is characterized by authenticator > > Yoshihiro> lower-layer to retransmit an EAP request based on an > > Yoshihiro> external event of receiving a peer-initiated duplicate > > Yoshihiro> request, instead of use of an internal timer event. This > > Yoshihiro> means that if the peer lower-layer receives a lower-layer > > Yoshihiro> response carrying an EAP request (so the corresponding > > Yoshihiro> lower-layer request is no longer outstanding) and the EAP > > Yoshihiro> request is discarded by EAP peer layer for some reason, > > Yoshihiro> then the peer lower-layer will not retransmit the > > Yoshihiro> lower-layer request to serve as the external event for > > Yoshihiro> the authenticator lower-layer to retransmit the EAP > > Yoshihiro> request. As a result, if my understanding is correct, the > > Yoshihiro> EAP conversation will stall unless there is some > > Yoshihiro> additional mechanism that can keep the EAP conversation > > Yoshihiro> going. The issue is more significant for insecure > > Yoshihiro> lower-layers where attackers can inject malformed EAP > > Yoshihiro> requests. The issue is less significant for secure > > Yoshihiro> lower-layers such as IKEv2. I agree that this issue is > > Yoshihiro> complex. Note that PANA does not have this issue because > > Yoshihiro> it is based on authenticator-initiated lower layer > > Yoshihiro> retransmission. > > > > It's absolutely true that if a peer discards an EAP request in such a > > scheme, the conversation stalls. > > If you're introducing that into an application, that would decrease > > robustness. > > There are a lot of TCP applications though where it is a violation of > > a protocol to discard a message. LDAP clients do not just get to > > ignore a SASL challenge or any other non-authentication protocol message. > > If an IMAP client ignores the capability response (happens before > > authentication), things will stall. > > If your application already depends on people not discarding > > responses, depending on that for authentication is fine. > > > > I think more or less all of our security layers are vulnerable to DOS > > attacks from people inserting or modifying their negotiations. > > The only thing I can think of that clearly does not have this > > vulnerability is statically keyed TCP-AO or IPSec. > > I'm fairly sure very little of anything we standardize gives the > > robustness you're looking for. > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Thu Oct 25 21:53:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD06521F8630 for ; Thu, 25 Oct 2012 21:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.488 X-Spam-Level: X-Spam-Status: No, score=0.488 tagged_above=-999 required=5 tests=[AWL=3.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raoA3wbXsj5h for ; Thu, 25 Oct 2012 21:53:51 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 82B9C21F85E7 for ; Thu, 25 Oct 2012 21:53:51 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 26FF72003E; Fri, 26 Oct 2012 00:53:21 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B1DD3412A; Fri, 26 Oct 2012 00:53:47 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> Date: Fri, 26 Oct 2012 00:53:47 -0400 In-Reply-To: <040b01cdb327$5d166e60$17434b20$@augustcellars.com> (Jim Schaad's message of "Thu, 25 Oct 2012 20:09:50 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 04:53:53 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> I have been looking at TEAP and am worried about silent Jim> discarding of packets. Jim> Since in the ABFAB environment, it is assumed that the Jim> transport is reliable, there is a possibility that a difference Jim> of opinion about what constitutes a good packet between the Jim> server and the client could cause a dead-lock situation in the Jim> protocol. Silent discard seems kind of inconsistent with a lower layer with infinite timeout, don't you think? Actually fixing that seems out of scope for just an applicability update and is something we should discuss in EMU. we can definitely discuss the TEAP specific version there. For the applicability statement it seems like we should note this. I've reviewed eap-ikev2, and it does seemed that it could be part of a solution to provide DOS robustness. A lot of other things about the EAP implementation, lower layer, security association protocol, etc all need to be true for you to actually get that benefit. I think this discussion has been quite useful and I'll try to work on text to propose for the applicability statement focusing on how this all impacts applications. From jsalowey@cisco.com Sun Oct 28 20:12:48 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2995A21F8458 for ; Sun, 28 Oct 2012 20:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bl5LyWro6IJY for ; Sun, 28 Oct 2012 20:12:47 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1639A21F8449 for ; Sun, 28 Oct 2012 20:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5350; q=dns/txt; s=iport; t=1351480367; x=1352689967; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8n2ewWiX8aH68anEYqoJ1I3nsNVzdJALZdw9UHkynBU=; b=J9yHHo6ZFPgPeEL1IlQRwcla8KImzQTzzhzpNvApXMX5VwcLyewOM5by qz3C4rtaNOCvLdeziFtccU4qwUMLJNSQspqMkNMEhcEdjzOo2ZCWcpDgr +oICK2nO/D0CzJIPiE9imuFXSC7yqX/m+Y8VREQFNo9a7buwRFrhLkMbC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGLzjVCtJV2c/2dsb2JhbABEwl+BCIIeAQEBAwEBAQEPASc0CwULAgEIGAoOBhAnCyUCBA4FCBqHXgYLm3yfIgSLdYM7gkFhA6RLgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,668,1344211200"; d="scan'208";a="133292551" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 29 Oct 2012 03:12:46 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9T3CkNp027904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Oct 2012 03:12:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Sun, 28 Oct 2012 22:12:46 -0500 From: "Joseph Salowey (jsalowey)" To: Alper Yegin Thread-Topic: [abfab] EAP Applicability: server-initiated re-authentication Thread-Index: AQHNrf90/7jppe91PUOQgxedfghj8JfIZlmA///kUJqAAF3UgIAHVdwA Date: Mon, 29 Oct 2012 03:12:45 +0000 Message-ID: References: <5087956D.3020205@toshiba.co.jp> <1AA88C76-9771-4443-B4CA-44ACF59F628A@yegin.org> In-Reply-To: <1AA88C76-9771-4443-B4CA-44ACF59F628A@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.93] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19314.001 x-tm-as-result: No--54.548400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <62DB371BDC76D847B30E01162EAB3B38@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 03:12:48 -0000 For the purposes of whether "server initiated re-authentication" is require= d, I think it is up to the lower layer to determine what this means. As ha= s been pointed out for network access you usually want to re-authenticate u= sing a mechanism that does not disrupt the session. For an application, th= is may not be an important consideration. It may be feasible to just termi= nate the session and start a new one with a fresh authentication. An appli= cation needs to determine how it will handle the following cases: 1) refresh in keying material is required - (key overuse, PN/nonce exhaust= ion,etc) 2) handling key/session compromise I do not think it will be too hard to provide text for this in the applicab= ility considerations and security considerations if that is what the group = wants to do. =20 Cheers, Joe On Oct 24, 2012, at 4:11 AM, Alper Yegin wrote: > Sam, >=20 > I recommend starting from identifying what aspects of "applications" are = different from "network access", and how such differences play into EAP. >=20 > Below you are talking about one such difference.=20 >=20 > (In that, in my understanding, you are OK with server initiated re-auth f= or network access, but you think this is not needed for applications.=20 > What is the root cause of this difference? ) >=20 > There may be other differences.=20 >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 > On Oct 24, 2012, at 1:35 PM, Sam Hartman wrote: >=20 >>>>>>> "Yoshihiro" =3D=3D Yoshihiro Ohba wr= ites: >>=20 >> Yoshihiro> RFC 5247 discusses EAP re-authentication in several >> Yoshihiro> sections. Here is one part: >>=20 >> Yoshihiro> " Where TSKs are derived from or are wrapped by exported >> Yoshihiro> EAP keying material, compromise of that exported EAP >> Yoshihiro> keying material implies compromise of TSKs. Therefore, >> Yoshihiro> if EAP keying material is considered stale, not only >> Yoshihiro> SHOULD EAP re-authentication be initiated, but also >> Yoshihiro> replacement of child keys, including TSKs. " >>=20 >> Yoshihiro> Since EAP keying material can be considered stale by >> Yoshihiro> either peer or authenticator, it makes sense to support >> Yoshihiro> both peer-initiated and authenticator-initiated >> Yoshihiro> re-authentication. If an application protocol has a >> Yoshihiro> design restriction that prevents from suppporting >> Yoshihiro> authenticator-initiated re-authentication, then it is >> Yoshihiro> better to let each application specification have some >> Yoshihiro> text in their Security Considerations section to assess >> Yoshihiro> potential impact on the application due to lack of the >> Yoshihiro> functionality. >>=20 >> A few points. >>=20 >> First, I agree with you that stale keying is an important thing to >> consider when integrating EAP into an application. >> So, I think we should make sure applications have the advice they need >> with regard to this topic. >>=20 >> I also agree with you that the keying framework applies. >>=20 >> However, we disagree about the need to discuss application-specific >> issues. >> Here are some things to consider: >>=20 >> 1) If your application uses TLS for confidentiality and integrity, say >> because it uses EAP with the eap-aes128 SASL mechanism, then compromise >> of the MSK does not affect traffic keys for your application. If the >> MSK was compromised at time of generation--say because a long-term >> password was compromised--then your entire authentication is >> compromised. >> If on the other hand the MSK is compromised after authentication, no >> harm appears to be done in this case. >>=20 >> 2) The EAP keying framework is written in the context of network >> access. In that context, shutting down a session in response to needing >> to re-key is a disruptive event. However, for something like SMTP, it >> seems entirely reasonable to just take down the session, which the >> server can do at an appropriate sequence point. If the client still >> wants to talk it will reconnect. There are actually a number of >> applications that work this way. >>=20 >> 3) As you point out, if an application doesn't have a way to respond to >> key compromise, there are likely to be security considerations. >> One thing applicability statements often do is point out security issues >> people should consider when applying a technology. >>=20 >> Especially where application use differs from network access use, we >> should document that sort of thing.=20 >>=20 >> Various aspects of the "detailed security analysis" provided by RFC 5247 >> are different, or the common assumptions are different for applications >> rather than network access. >> This is why you can't just change the one sentence in section 1.3 of RFC >> 3748 and be done. >>=20 >> In conclusion, thanks for pointing out the really interesting issue of >> key compromise. We'll want to handle that. >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From jsalowey@cisco.com Sun Oct 28 20:29:11 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B7521F84F6 for ; Sun, 28 Oct 2012 20:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+tub+tXHI0h for ; Sun, 28 Oct 2012 20:29:10 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A420321F8545 for ; Sun, 28 Oct 2012 20:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1787; q=dns/txt; s=iport; t=1351481350; x=1352690950; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pdFfaeZfzvQqtOUwPfhvbQblyZ9vIbSqOWPgY1bx+Ho=; b=Afmr3GlfsVG2lFCeoM+7tVs9pIQ6SmWy3SI7GC02VJt09cJKTFs2ey3P qsgB8gJQNoLOWajAH9CS28mkM8tpXxS6/c/XBxmARraR1gkcpn866v7Y2 xpaOH1HMRdQicFqUBAh+kU6BmtX4fF2qA+9m/8HWhMgFgvN8tPlO9GS7A g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADz3jVCtJV2b/2dsb2JhbABEwl+BCIIeAQEBAwEBAQEPASc0CwULAgEIGAoUECcLJQIEDgUIGodeBgube58jBIt1hXxhA6RLgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,668,1344211200"; d="scan'208";a="136302019" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 29 Oct 2012 03:29:10 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9T3TAM5032212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Oct 2012 03:29:10 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Sun, 28 Oct 2012 22:29:09 -0500 From: "Joseph Salowey (jsalowey)" To: Alan DeKok Thread-Topic: [abfab] EAP Applicability: Lifetime of Authorizations Thread-Index: AQHNrgILGTluYLkKDUy6XczbdCI0aJfA/rmA//+2TdCAAF36AP//sUF9gABw6QD//68vpwAKwq2A//+zQwyABJHSgIAAAVsAgAqCDIA= Date: Mon, 29 Oct 2012 03:29:09 +0000 Message-ID: References: <50815F47.3010608@restena.lu> <5081704A.5090504@restena.lu> <50818CF2.1090902@toshiba.co.jp> <5081915D.8070707@toshiba.co.jp> <476420B3-CCB6-4FB2-ADCF-A368331AF1B7@yegin.org> <50852772.4000308@deployingradius.com> In-Reply-To: <50852772.4000308@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.93] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19314.001 x-tm-as-result: No--33.748200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [abfab] EAP Applicability: Lifetime of Authorizations X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 03:29:11 -0000 It seems that most of this discussion has to do with application authoriza= tion and AAA and not with EAP. As Alan points out there are several diffe= rent ways session lifetime can be dealt with in current deployments ome of = which put more control int he AAA and others more in the NAS. Its not cl= ear to me that this belongs in an applicability statement. =20 Joe On Oct 22, 2012, at 4:01 AM, Alan DeKok wrote: > Alper Yegin wrote: >> Now, if someone tells me the NAS can set the lifetime value to anything = irrespective of the lifetime received from the AAA, then I say he's using a= centralized AA (authentication and accounting) server with distributed A (= Authorization). An interesting case, not typical but doable. Someone may ha= ve a very special reason to do that. >=20 > NASes have always had "creative" interpretations of authorization > policies coming from an AAA servers. So this behavior is well within > the traditional AAA. >=20 >> Regarding the application state that is created within the authorized ap= plication session, yes I understand and agree that it may survive beyond th= e authorized session. But that's very application specific. We need to disc= uss that in the scope of specific applications. >=20 > I agree. >=20 > I would phrase the difference as being either the ability to *do* > something, or the ability to *have* something. Items like "session > timeout" control the ability to have a session. Once the session is > over, the ability goes away. Other items could be allowed to continue, > even after the session has been finished. >=20 > Alan DeKok. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From jsalowey@cisco.com Sun Oct 28 20:36:45 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F0F21F84F6 for ; Sun, 28 Oct 2012 20:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGL3Mtlc7zwk for ; Sun, 28 Oct 2012 20:36:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C083421F85E1 for ; Sun, 28 Oct 2012 20:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1772; q=dns/txt; s=iport; t=1351481805; x=1352691405; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=F4aWq3YK1x82vVZb1JRYW82DFzNhPFy9uJJyov8x6zA=; b=Gd5bwbZpxlgE3PzFCN8wxhM4fot9YVOlwH5Z12qnGRAHeE3mXWKSxaKM 7saR8/RfGe1BEYdZk8J6kv4pyA5PayDkPAyaXbS0W2HF3enMf5soXFf7a S+kUE89VoyArvgyYer4QdAb8db6jqklPeu2Gfv6+k7/TRqydLEPpPn1Eu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFz4jVCtJV2Y/2dsb2JhbABEwmCBCIIfAQEEAQEBDwEnNAsQAgEIIhQQJwslAgQOBQgTB4dkC5t8nyMEi3WFfGEDpEuBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,668,1344211200"; d="scan'208";a="136300067" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 29 Oct 2012 03:36:44 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9T3aiYF008644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Oct 2012 03:36:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Sun, 28 Oct 2012 22:36:43 -0500 From: "Joseph Salowey (jsalowey)" To: Sam Hartman Thread-Topic: [abfab] EAP Applicability: retransmissions Thread-Index: AQHNrf2UhKI0u6N/6UCRfnOyERWodpfLD9WKgAT1O4A= Date: Mon, 29 Oct 2012 03:36:43 +0000 Message-ID: References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.93] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19314.001 x-tm-as-result: No--36.392600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <84FEED72899DE248B06E790B8A0337D3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jim Schaad , "" Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 03:36:45 -0000 This discussion points out behavior that can result in some problems so I t= hink we need to cover this somewhere either in the applicability statement = or in EAP-GSS. We need to consider it in TEAP, but the issue is broader th= an TEAP. =20 Joe On Oct 25, 2012, at 9:53 PM, Sam Hartman wrote: >>>>>> "Jim" =3D=3D Jim Schaad writes: >=20 > Jim> I have been looking at TEAP and am worried about silent > Jim> discarding of packets. >=20 > Jim> Since in the ABFAB environment, it is assumed that the > Jim> transport is reliable, there is a possibility that a difference > Jim> of opinion about what constitutes a good packet between the > Jim> server and the client could cause a dead-lock situation in the > Jim> protocol. >=20 > Silent discard seems kind of inconsistent with a lower layer with > infinite timeout, don't you think? >=20 > Actually fixing that seems out of scope for just an applicability update > and is something we should discuss in EMU. > we can definitely discuss the TEAP specific version there. > For the applicability statement it seems like we should note this. >=20 > I've reviewed eap-ikev2, and it does seemed that it could be part of a > solution to provide DOS robustness. A lot of other things about the EAP > implementation, lower layer, security association protocol, etc all need > to be true for you to actually get that benefit. >=20 > I think this discussion has been quite useful and I'll try to work on > text to propose for the applicability statement focusing on how this all > impacts applications. >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From alper.yegin@yegin.org Mon Oct 29 04:24:40 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E71E21F85C6 for ; Mon, 29 Oct 2012 04:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.959 X-Spam-Level: X-Spam-Status: No, score=-101.959 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAUkLiS2siBB for ; Mon, 29 Oct 2012 04:24:38 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5863821F88FB for ; Mon, 29 Oct 2012 04:24:38 -0700 (PDT) Received: from [192.168.2.6] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M5uD3-1TDlZh24ef-00xfvn; Mon, 29 Oct 2012 07:24:36 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Mon, 29 Oct 2012 13:24:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7842773C-FD9B-4066-BFCA-6FAA0707455B@yegin.org> References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:I8W8wnW9iDyD6jXBpvHAMe5VodfvdkGYfonOMO9PeZ+ e01zlAmJRS3AfIrERZPPHCW1XndRllDGOr0iETsc5H1MFsxhNS EJMbhhGgN02nTaJoSnVoo6PFyQ2y4V7B8IwYJVMiM2QmyJrunw OHLqQ/6le+AUDl4m1zTVbhBzSP336pMIkTfWtRncmKu7dakpp6 UyOBxzFuVxcM3iNqxcMqEQsGYW8H85QYpj9HxxODIYdqKW7CeX mY30CiYqbJJ3GMI5TZhLUqLQvtQYoVrjQhPnz3/yHcmdf5Ot9O 18B3kEjjUtnrWZgAO6yzySLIAL61vYl1RWjzGuvPTLSq0Bpf5n jd17NIVMvn7oJ8Zcp8/aDO/j5iNO2PZ7NImfp+Yn5iF1xH/KUX pzpu/4vn3nWeQ== Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 11:24:40 -0000 > So, GSS expects the application to provide reliable transport to it. > Normally applications do this by running over TCP. In TCP, if a node > discards a packet without acknowledging it, then it is retransmitted = at > the TCP layer. > It's an error to discard a packet after acknowledging. >=20 The important thing is, who is acknowledging the receipt and who is = discarding packet. It's perfectly fine when the EAP lower layer (who provides reliable = delivery) is acknowledging the receipt, but then the EAP layer or the = EAP method (i.e., the higher layers) is discarding the packet. Alper From alper.yegin@yegin.org Mon Oct 29 05:02:35 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACABB21F848D for ; Mon, 29 Oct 2012 05:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.065 X-Spam-Level: X-Spam-Status: No, score=-102.065 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLzkWk9evBoS for ; Mon, 29 Oct 2012 05:02:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 38AF221F848A for ; Mon, 29 Oct 2012 05:02:34 -0700 (PDT) Received: from [192.168.2.6] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MU0ld-1TtNSD3iuv-00RScj; Mon, 29 Oct 2012 08:02:22 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_DD2B0F61-B015-4FC5-84FE-30670F0C66F1" From: Alper Yegin In-Reply-To: Date: Mon, 29 Oct 2012 14:02:02 +0200 Message-Id: <5372D8E5-7464-4977-BF22-D581EB0C77E9@yegin.org> References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:A1T3jpvdC+B3B8Dvp7nqPdtm/it1djwUikJR2FBjsO/ CdnWiR6DaB4Y3kS7P14sEVXV7B+t1CrQbkUWAjM5S6VFAdbEAd xnWRr21gKIH+wAbyNe/HJgfnHKGXO35jNKJNPvWpdvRE7g7U0u nHXInUluS4jYvIteB8O4XNZUB5EGw2MgEDCYHImdpFFCc+yYc5 xsBj+QXRSxP2/OoGMfNOR1P2mKEkZHGVqbZHJowUBOE9AKQE4T jDlqG0WbmHuI+vvZc4c5sMqipbaMmEUx/5ZYnfGoHKgGv1irqV Tr45LpJMug7iGzONXFlH0z4UiG9NCmpNsb7kyNS3AQBdf9Slsw Ru4FkpBlLrqVrMKPkGLNtp3+0g2iwI9QyHXhY+XKScfUZGni50 fBOsBsfz4fJHQ== Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 12:02:35 -0000 --Apple-Mail=_DD2B0F61-B015-4FC5-84FE-30670F0C66F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 24, 2012, at 2:02 PM, Sam Hartman wrote: >>>>>> "Yoshihiro" =3D=3D Yoshihiro Ohba = writes: >=20 > Yoshihiro> There are two separate issues here. First, Regardless > Yoshihiro> whether lower-layer provides reliabilty or not, I = believe > Yoshihiro> EAP-layer retransmissions can improve robustness against > Yoshihiro> DoS attack by sending malformed EAP requests, which > Yoshihiro> otherwise can stall the EAP conversation. EAP-layer > Yoshihiro> retransmission is not needed if the lower-layer provides > Yoshihiro> secure reliable transport of EAP, such as IKEv2. I am > Yoshihiro> not an expert of GSS-API, but it would have been better > Yoshihiro> if EAP-layer retrasnmissions were allowed in GSS-EAP. >=20 > We both agree that a reliable lower layer needs to be sufficient to = deal > with network problems. >=20 > As I understand it, we're exploring the case where retransmissions = would > deal with an attacker. > So, I think what you're saying is that if an implementation performs a > retransmit when it gets a malicious packet, it can be more robust. >=20 > We're presumably talking about an attacker that can insert packets but > not modify them or suppress them. > An attacker who can modify or suppress packets can fairly clearly DOS > the EAP conversation. > If nothing else, they can simply make sure the packet is always > corrupted. >=20 > For this to be valuable there need to be EAP methods that are robust > under EAP-layer retransmission but not other higher-layer > retransmission.=20 Sam, Correction to your statement above: We are talking about the necessity of EAP-layer or EAP lower-layer = server-side re-transmission being necessary. You are proposing getting by with client-side re-transmissions. > It's not good enough for EAP layer retransmissions to help with some > packets in a method if it doesn't help with others. If there's some > packet an attacker can easily send that will break the conversation, = the method > is not robust under EAP layer transmission. > For example it wouldn't be particularly valuable if EAP layer > retransmission protects against garbled packets but not packets with > unknown critical options added, because an attacker could easily add = an > unknown critical option. >=20 > I then started to consider the existing EAP methods. > I am not able to think of an EAP method that is robust under EAP layer > retransmission. I think you can fairly consistently break an EAP > conversation by inserting packets. Nope. A random EAP payload to your EAP-o-PCP method that is sent from = the server side can totally stall your solution. EAP layer or the EAP method layer on the client will discard that = message. But since your EAP-o-PCP on the client side thinks it happily got a = response to its earlier request, it'll sit there by itself. The = discarded message won't generate a response from the EAP layer or EAP = method layer on the client, so nothing will tell the EAP-o-PCP to send = its next request. =20 This situation does not happen to server-driven rexmits, as the server = would rexmit the request if it does not receive a response. A random = packet injected cannot stall the flow. > The most obvious thing to try is an EAP failure packet, then an EAP > NACK. =46rom 3748: A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request after an initial non-Nak Response has been sent. Since spoofed EAP Request packets may be sent by an attacker, an authenticator receiving an unexpected Nak SHOULD discard it and log the event. ... Success and Failure packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not explicitly permit the method to finish at that point. A peer EAP implementation receiving a Success or Failure packet where sending one is not explicitly permitted MUST silently discard it.=20 Alper > I also quickly considered methods like GPSK and TLS-based methods, and > am fairly sure those are not robust either. > So, would you be willing to pick an EAP method that is robust and go > through a fairly detailed argument about how insertion DOS attacks are > avoided? >=20 >=20 >=20 > Yoshihiro> Second, Regarding peer-initiated lower-layer > Yoshihiro> retransmission, it is characterized by authenticator > Yoshihiro> lower-layer to retransmit an EAP request based on an > Yoshihiro> external event of receiving a peer-initiated duplicate > Yoshihiro> request, instead of use of an internal timer event. This > Yoshihiro> means that if the peer lower-layer receives a = lower-layer > Yoshihiro> response carrying an EAP request (so the corresponding > Yoshihiro> lower-layer request is no longer outstanding) and the = EAP > Yoshihiro> request is discarded by EAP peer layer for some reason, > Yoshihiro> then the peer lower-layer will not retransmit the > Yoshihiro> lower-layer request to serve as the external event for > Yoshihiro> the authenticator lower-layer to retransmit the EAP > Yoshihiro> request. As a result, if my understanding is correct, = the > Yoshihiro> EAP conversation will stall unless there is some > Yoshihiro> additional mechanism that can keep the EAP conversation > Yoshihiro> going. The issue is more significant for insecure > Yoshihiro> lower-layers where attackers can inject malformed EAP > Yoshihiro> requests. The issue is less significant for secure > Yoshihiro> lower-layers such as IKEv2. I agree that this issue is > Yoshihiro> complex. Note that PANA does not have this issue = because > Yoshihiro> it is based on authenticator-initiated lower layer > Yoshihiro> retransmission. >=20 > It's absolutely true that if a peer discards an EAP request in such a > scheme, the conversation stalls. > If you're introducing that into an application, that would decrease > robustness. > There are a lot of TCP applications though where it is a violation of = a > protocol to discard a message. LDAP clients do not just get to ignore = a > SASL challenge or any other non-authentication protocol message. > If an IMAP client ignores the capability response (happens before > authentication), things will stall. > If your application already depends on people not discarding = responses, > depending on that for authentication is fine. >=20 > I think more or less all of our security layers are vulnerable to DOS > attacks from people inserting or modifying their negotiations. > The only thing I can think of that clearly does not have this > vulnerability is statically keyed TCP-AO or IPSec. > I'm fairly sure very little of anything we standardize gives the > robustness you're looking for. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --Apple-Mail=_DD2B0F61-B015-4FC5-84FE-30670F0C66F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
"Yoshihiro" =3D=3D Yoshihiro = Ohba <yoshihiro.ohba@toshiba.co.jp<= /a>> = writes:

   Yoshihiro> There are two separate issues = here.  First, Regardless
   Yoshihiro> = whether lower-layer provides reliabilty or not, I believe
=    Yoshihiro> EAP-layer retransmissions can improve = robustness against
   Yoshihiro> DoS attack by = sending malformed EAP requests, which
=    Yoshihiro> otherwise can stall the EAP = conversation. EAP-layer
   Yoshihiro> = retransmission is not needed if the lower-layer provides
=    Yoshihiro> secure reliable transport of EAP, such = as IKEv2.  I am
   Yoshihiro> not an expert = of GSS-API, but it would have been better
=    Yoshihiro> if EAP-layer retrasnmissions were = allowed in GSS-EAP.

We both agree that a reliable lower layer = needs to be sufficient to deal
with network problems.

As I = understand it, we're exploring the case where retransmissions = would
deal with an attacker.
So, I think what you're saying is = that if an implementation performs a
retransmit when it gets a = malicious packet, it can be more robust.

We're presumably talking = about an attacker that can insert packets but
not modify them or = suppress them.
An attacker who can modify or suppress packets can = fairly clearly DOS
the EAP conversation.
If nothing else, they can = simply make sure the packet is always
corrupted.

For this to = be valuable there need to be EAP methods that are robust
under = EAP-layer retransmission but not other higher-layer
retransmission. =







It's not good enough for EAP layer = retransmissions to help with some
packets in a method if it doesn't = help with others. If there's some
packet an attacker can easily send = that will break the conversation, the method
is not robust under EAP = layer transmission.
For example it wouldn't be particularly valuable = if EAP layer
retransmission protects against garbled packets but not = packets with
unknown critical options added, because an attacker = could easily add an
unknown critical option.

I then started to = consider the existing EAP methods.
I am not able to think of an EAP = method that is robust under EAP layer
retransmission. I think you can = fairly consistently break an EAP
conversation by inserting = packets.

Nope. A random EAP = payload to your EAP-o-PCP method that is sent from the server side can = totally stall your solution.
EAP layer or the EAP method layer = on the client will discard that message.
But since your = EAP-o-PCP on the client side thinks it happily got a response to its = earlier request, it'll sit there by itself. The discarded message won't = generate a response from the EAP layer or EAP method layer on the = client, so nothing will tell the EAP-o-PCP to send its next request. =  

This situation does not happen to = server-driven rexmits, as the server would rexmit the request if it does = not receive a response. A random packet injected cannot stall the = flow.


The most = obvious thing to try is an EAP failure packet, then an = EAP
NACK.

=46rom = 3748:

   A peer MUST NOT send a Nak (legacy or =
expanded) in reply to a Request
   after an initial non-Nak Response has been sent.  Since spoofed EAP
   Request packets may be sent by an attacker, an authenticator
   receiving an unexpected Nak SHOULD discard it and log the =
event.

...

Success and Failure = packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not explicitly permit the method to finish at that point. A peer EAP implementation receiving a Success or Failure packet where sending one is not explicitly permitted MUST silently discard it. =

Alper



I also quickly considered = methods like GPSK and TLS-based methods, and
am fairly sure those are = not robust either.
So, would you be willing to pick an EAP method = that is robust and go
through a fairly detailed argument about how = insertion DOS attacks are
avoided?



=    Yoshihiro> Second, Regarding peer-initiated = lower-layer
   Yoshihiro> retransmission, it is = characterized by authenticator
   Yoshihiro> = lower-layer to retransmit an EAP request based on an
=    Yoshihiro> external event of receiving a = peer-initiated duplicate
   Yoshihiro> request, = instead of use of an internal timer event. This
=    Yoshihiro> means that if the peer lower-layer = receives a lower-layer
   Yoshihiro> response = carrying an EAP request (so the corresponding
=    Yoshihiro> lower-layer request is no longer = outstanding) and the EAP
   Yoshihiro> request is = discarded by EAP peer layer for some reason,
=    Yoshihiro> then the peer lower-layer will not = retransmit the
   Yoshihiro> lower-layer request = to serve as the external event for
   Yoshihiro> = the authenticator lower-layer to retransmit the EAP
=    Yoshihiro> request. As a result, if my = understanding is correct, the
   Yoshihiro> EAP = conversation will stall unless there is some
=    Yoshihiro> additional mechanism that can keep the = EAP conversation
   Yoshihiro> going.  The = issue is more significant for insecure
=    Yoshihiro> lower-layers where attackers can inject = malformed EAP
   Yoshihiro> requests.  The = issue is less significant for secure
   Yoshihiro> = lower-layers such as IKEv2.  I agree that this issue is
=    Yoshihiro> complex.  Note that PANA does not = have this issue because
   Yoshihiro> it is based = on authenticator-initiated lower layer
=    Yoshihiro> retransmission.

It's absolutely = true that if a peer  discards an EAP request in such a
scheme, = the conversation stalls.
If you're introducing that into an = application, that would decrease
robustness.
There are a lot of = TCP applications though where it is a violation of a
protocol to = discard a message. LDAP clients do not just get to ignore a
SASL = challenge or any other non-authentication protocol message.
If an = IMAP client ignores the capability response (happens = before
authentication), things will stall.
If your application = already depends on people not discarding responses,
depending on that = for authentication is fine.

I think more or less all of our = security layers are vulnerable to DOS
attacks from people inserting = or modifying their negotiations.
The only thing I can think of that = clearly does not have this
vulnerability is statically keyed TCP-AO = or IPSec.
I'm fairly sure very little of anything we standardize = gives the
robustness you're looking = for.
_______________________________________________
abfab mailing = list
abfab@ietf.org
https://www.ietf.org/= mailman/listinfo/abfab

= --Apple-Mail=_DD2B0F61-B015-4FC5-84FE-30670F0C66F1-- From alper.yegin@yegin.org Mon Oct 29 05:07:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67F21F8509 for ; Mon, 29 Oct 2012 05:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eaVNjy1flmA for ; Mon, 29 Oct 2012 05:07:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 4A39E21F8507 for ; Mon, 29 Oct 2012 05:07:47 -0700 (PDT) Received: from [192.168.2.6] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M4G3X-1TB0I10GdH-00rpvd; Mon, 29 Oct 2012 08:07:22 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Mon, 29 Oct 2012 14:07:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:WE87i1NZE+vRUNLzYSKMY40Vmc3NqmaE4cK6GyMplfe ZDvIH1RmKjPL6olzPozVrYXE6cCH0pnX+lWpMq7LKIX00hYIul 7iAbmW4V9+a9sZ6TlXkoN5n21BWHYuIJInRjCoGzBqdyJGZnbm BpdJ13wuZ+ZPgHCJWkQlNQlIOEjb8i0kK1sjbz+e336Bg2WURl YKgIP5uLDniWfVOQFun1Pu1fvZG6M7UzJmP0eJZp7/rieyGUlx ik9J05KnqxaLdBGZPxcnue76LNGW/2Ud50oT1qr0In3i20IoZ3 ZJdBXpAzxHrncNkzQnvlYExxRfdgfDLxa2E4C5w21waIQM7HOE 4OoMBRZgRHomnG/dQUQfGzgkIyulox8CKsQ/VB7+t/UsKn9Tcp aEXl3xIQo/uOQ== Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 12:07:53 -0000 On Oct 26, 2012, at 7:53 AM, Sam Hartman wrote: >>>>>> "Jim" =3D=3D Jim Schaad writes: >=20 > Jim> I have been looking at TEAP and am worried about silent > Jim> discarding of packets. >=20 > Jim> Since in the ABFAB environment, it is assumed that the > Jim> transport is reliable, there is a possibility that a = difference > Jim> of opinion about what constitutes a good packet between the > Jim> server and the client could cause a dead-lock situation in the > Jim> protocol. >=20 > Silent discard seems kind of inconsistent with a lower layer with > infinite timeout, don't you think? >=20 What's being discussed is "EAP layer timeout being infinite, EAP = lower-layer server-side timeout being finite". In that case, silent discarding is not a problem. Alper > Actually fixing that seems out of scope for just an applicability = update > and is something we should discuss in EMU. > we can definitely discuss the TEAP specific version there. > For the applicability statement it seems like we should note this. >=20 > I've reviewed eap-ikev2, and it does seemed that it could be part of a > solution to provide DOS robustness. A lot of other things about the = EAP > implementation, lower layer, security association protocol, etc all = need > to be true for you to actually get that benefit. >=20 > I think this discussion has been quite useful and I'll try to work on > text to propose for the applicability statement focusing on how this = all > impacts applications. >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Mon Oct 29 05:47:04 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323F721F865B for ; Mon, 29 Oct 2012 05:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xbL+rE6hbLH for ; Mon, 29 Oct 2012 05:47:03 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id B10A821F8647 for ; Mon, 29 Oct 2012 05:47:03 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 2BC3220200; Mon, 29 Oct 2012 08:46:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 92D56412A; Mon, 29 Oct 2012 08:46:58 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5372D8E5-7464-4977-BF22-D581EB0C77E9@yegin.org> Date: Mon, 29 Oct 2012 08:46:58 -0400 In-Reply-To: <5372D8E5-7464-4977-BF22-D581EB0C77E9@yegin.org> (Alper Yegin's message of "Mon, 29 Oct 2012 14:02:02 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 12:47:04 -0000 >>>>> "Alper" == Alper Yegin writes: > We both agree that a reliable lower layer needs to be > sufficient to deal with network problems. > As I understand it, we're exploring the case where > retransmissions would deal with an attacker. So, I think > what you're saying is that if an implementation performs a > retransmit when it gets a malicious packet, it can be more > robust. > We're presumably talking about an attacker that can > insert packets but not modify them or suppress them. An > attacker who can modify or suppress packets can fairly > clearly DOS the EAP conversation. If nothing else, they can > simply make sure the packet is always corrupted. > For this to be valuable there need to be EAP methods that > are robust under EAP-layer retransmission but not other > higher-layer retransmission. > Sam, Alper> Correction to your statement above: Alper> We are talking about the necessity of EAP-layer or EAP Alper> lower-layer server-side re-transmission being necessary. You Alper> are proposing getting by with client-side re-transmissions. For the record, I believe my original statement accurately reflects my meaning and your correction does not. --Sam From hartmans@painless-security.com Mon Oct 29 06:02:54 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5E421F851F for ; Mon, 29 Oct 2012 06:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeQaKT-EdERL for ; Mon, 29 Oct 2012 06:02:53 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id CABAB21F84B6 for ; Mon, 29 Oct 2012 06:02:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 058BD20200; Mon, 29 Oct 2012 09:02:17 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 90B67412A; Mon, 29 Oct 2012 09:02:49 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> Date: Mon, 29 Oct 2012 09:02:49 -0400 In-Reply-To: <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> (Alper Yegin's message of "Mon, 29 Oct 2012 14:07:03 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 13:02:54 -0000 As part of writing this reply I realized that I don't fully understand how this works at the AAA layer. Alan, what happens when a RADIUS server gets an access request and the EAP layer doesn't produce an EAP message? The NAS's RADIUS client is waiting for an answer; it will eventually time out, but that's not going to help things so much. From aland@deployingradius.com Mon Oct 29 07:30:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077F721F870D for ; Mon, 29 Oct 2012 07:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebiE+c8Cc7VB for ; Mon, 29 Oct 2012 07:30:52 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B64921F870C for ; Mon, 29 Oct 2012 07:30:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 44FE12240AAA; Mon, 29 Oct 2012 15:29:57 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WJB6VVDKfCb; Mon, 29 Oct 2012 15:29:55 +0100 (CET) Received: from Thor.local (pas38-7-83-153-93-21.fbx.proxad.net [83.153.93.21]) by power.freeradius.org (Postfix) with ESMTPSA id 4431C2240952; Mon, 29 Oct 2012 15:29:55 +0100 (CET) Message-ID: <508E92E2.9060702@deployingradius.com> Date: Mon, 29 Oct 2012 15:29:54 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 14:30:53 -0000 Sam Hartman wrote: > As part of writing this reply I realized that I don't fully understand > how this works at the AAA layer. > Alan, what happens when a RADIUS server gets an access request and the > EAP layer doesn't produce an EAP message? I'm presuming that this is the EAP side on the RADIUS server. The answer is that the RADIUS server really *should* respond to the Access-Request. Without any EAP data, the only thing it can return is Access-Reject. Alan DeKok. From ietf@augustcellars.com Mon Oct 29 21:34:13 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1361E21F849E for ; Mon, 29 Oct 2012 21:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahOGWbsLuIUZ for ; Mon, 29 Oct 2012 21:34:12 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 87A3D21F8464 for ; Mon, 29 Oct 2012 21:34:12 -0700 (PDT) Received: from Philemon (50-39-218-206.bvtn.or.frontiernet.net [50.39.218.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id A0E972C9BB; Mon, 29 Oct 2012 21:34:11 -0700 (PDT) From: "Jim Schaad" To: "'Alan DeKok'" , "'Sam Hartman'" References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> <508E92E2.9060702@deployingradius.com> In-Reply-To: <508E92E2.9060702@deployingradius.com> Date: Mon, 29 Oct 2012 21:34:06 -0700 Message-ID: <004c01cdb657$ce9df200$6bd9d600$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEZytxIIaFEdNJhDJM7vx/kOAZ2BwGjPaFHAqnWy/gBl88lagJaWb/DAf3zB/YB3x+6vwFe2PVXASv/R5UCD9L2AQJ6s1F6Am7DiBECGWV0w5h7SVnA Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 04:34:13 -0000 I have an added worry in that an additional "attacker" that I worry about is a stupid or slightly incorrectly encoded client. This means that part of what I worry about is what happens if the client decides to drop an EAP message for some unknown reason that may or may not be a correct thing for it to do. A RADIUS server will not cause a re-transmission on a timeout because it only operates in a response mode. That is the client is always the entity that sends a request that RADIUS server responds to. However the RADIUS server will have cached the last message it sent out. The acceptor (GSS-API RP) is not currently setup to deal with re-transmission of EAP messages in either direction. The initiator is the one which dropped the EAP message on the floor when it received the GSS-API wrapper on the message. It is not clear that it has anything to send to the acceptor to trigger the RADIUS messages from the acceptor to the RADIUS server. It is not clear that the GSS-API acceptor would send a new RADIUS message to the RADIUS server unless there is an EAP component to the GSS-API message sent from the initiator to the acceptor. Jim -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Monday, October 29, 2012 7:30 AM To: Sam Hartman Cc: Alper Yegin; Jim Schaad; abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions Sam Hartman wrote: > As part of writing this reply I realized that I don't fully understand > how this works at the AAA layer. > Alan, what happens when a RADIUS server gets an access request and the > EAP layer doesn't produce an EAP message? I'm presuming that this is the EAP side on the RADIUS server. The answer is that the RADIUS server really *should* respond to the Access-Request. Without any EAP data, the only thing it can return is Access-Reject. Alan DeKok. From hartmans@painless-security.com Tue Oct 30 03:03:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2030921F84A4 for ; Tue, 30 Oct 2012 03:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inVfrJ5tuj+i for ; Tue, 30 Oct 2012 03:03:11 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 95F1D21F849E for ; Tue, 30 Oct 2012 03:03:11 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 9CE1D20200; Tue, 30 Oct 2012 06:02:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EE7EF412A; Tue, 30 Oct 2012 06:03:07 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> <508E92E2.9060702@deployingradius.com> <004c01cdb657$ce9df200$6bd9d600$@augustcellars.com> Date: Tue, 30 Oct 2012 06:03:07 -0400 In-Reply-To: <004c01cdb657$ce9df200$6bd9d600$@augustcellars.com> (Jim Schaad's message of "Mon, 29 Oct 2012 21:34:06 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 10:03:12 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> I have an added worry in that an additional "attacker" that I Jim> worry about is a stupid or slightly incorrectly encoded client. Jim> This means that part of what I worry about is what happens if Jim> the client decides to drop an EAP message for some unknown Jim> reason that may or may not be a correct thing for it to do. I actually think this is not specific to GSS. Even if the authenticator retransmits, it will retransmit the same request. Assuming the peer's behavior is deterministic, such a peer will fail with any lower layer. --Sam From ietf@augustcellars.com Tue Oct 30 10:27:42 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114D021F85B6 for ; Tue, 30 Oct 2012 10:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCxF12HKqp3T for ; Tue, 30 Oct 2012 10:27:41 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 648FF21F85B3 for ; Tue, 30 Oct 2012 10:27:41 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 023712CA36; Tue, 30 Oct 2012 10:27:40 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> <508E92E2.9060702@deployingradius.com> <004c01cdb657$ce9df200$6bd9d600$@augustcellars.com> In-Reply-To: Date: Tue, 30 Oct 2012 10:27:38 -0700 Message-ID: <009c01cdb6c3$dc1f9e30$945eda90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEZytxIIaFEdNJhDJM7vx/kOAZ2BwGjPaFHAqnWy/gBl88lagJaWb/DAf3zB/YB3x+6vwFe2PVXASv/R5UCD9L2AQJ6s1F6Am7DiBECGWV0wwJ8TT80AcLs2ouYWijA0A== Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:27:42 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Tuesday, October 30, 2012 3:03 AM > To: Jim Schaad > Cc: 'Alan DeKok'; 'Alper Yegin'; abfab@ietf.org > Subject: Re: [abfab] EAP Applicability: retransmissions > > >>>>> "Jim" == Jim Schaad writes: > > Jim> I have an added worry in that an additional "attacker" that I > Jim> worry about is a stupid or slightly incorrectly encoded client. > Jim> This means that part of what I worry about is what happens if > Jim> the client decides to drop an EAP message for some unknown > Jim> reason that may or may not be a correct thing for it to do. > > I actually think this is not specific to GSS. > Even if the authenticator retransmits, it will retransmit the same request. > Assuming the peer's behavior is deterministic, such a peer will fail with any > lower layer. It is true that any peer will fail, however it is also true that the server in this case will do good things if it can originate messages as it knows when and how to shut down the session and not send an EAP failure message to the client. If one has a lock step transport then there is no current good way on how to shut down the session and send a failure message back towards the client. This is a general issue for RADIUS, but is not a problem in many other transports. Jim > > --Sam From hartmans@painless-security.com Tue Oct 30 10:51:31 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A90921F86F0 for ; Tue, 30 Oct 2012 10:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reriBfDW7u+d for ; Tue, 30 Oct 2012 10:51:30 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A97B321F86E5 for ; Tue, 30 Oct 2012 10:51:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [18.111.3.224]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 2D529201E2; Tue, 30 Oct 2012 13:50:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 839ED412A; Tue, 30 Oct 2012 13:51:29 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> <508E92E2.9060702@deployingradius.com> <004c01cdb657$ce9df200$6bd9d600$@augustcellars.com> <009c01cdb6c3$dc1f9e30$945eda90$@augustcellars.com> Date: Tue, 30 Oct 2012 13:51:29 -0400 In-Reply-To: <009c01cdb6c3$dc1f9e30$945eda90$@augustcellars.com> (Jim Schaad's message of "Tue, 30 Oct 2012 10:27:38 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:51:31 -0000 In gss-eap, I'd expect an implementation that gets an access reject to send an error token and shut down that way. From ietf@augustcellars.com Tue Oct 30 11:02:41 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC3621F85B3 for ; Tue, 30 Oct 2012 11:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdLPp-qSwXSx for ; Tue, 30 Oct 2012 11:02:41 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1380421F85B0 for ; Tue, 30 Oct 2012 11:02:41 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 1B97638F2F; Tue, 30 Oct 2012 11:02:39 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> <508E92E2.9060702@deployingradius.com> <004c01cdb657$ce9df200$6bd9d600$@augustcellars.com> <009c01cdb6c3$dc1f9e30$945eda90$@augustcellars.com> In-Reply-To: Date: Tue, 30 Oct 2012 11:02:37 -0700 Message-ID: <00a101cdb6c8$bf932b60$3eb98220$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEZytxIIaFEdNJhDJM7vx/kOAZ2BwGjPaFHAqnWy/gBl88lagJaWb/DAf3zB/YB3x+6vwFe2PVXASv/R5UCD9L2AQJ6s1F6Am7DiBECGWV0wwJ8TT80AcLs2osCy+hMBgJS6SC9mDE8lGA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 18:02:41 -0000 I agree that an access reject from RADIUS is the correct way to shut down. Who sends it and when? > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Tuesday, October 30, 2012 10:51 AM > To: Jim Schaad > Cc: 'Alan DeKok'; 'Alper Yegin'; abfab@ietf.org > Subject: Re: [abfab] EAP Applicability: retransmissions > > In gss-eap, I'd expect an implementation that gets an access reject to send > an error token and shut down that way. From hartmans@painless-security.com Tue Oct 30 12:36:44 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983BE21F862A for ; Tue, 30 Oct 2012 12:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5E10Xpl6ybB for ; Tue, 30 Oct 2012 12:36:42 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8B12921F8621 for ; Tue, 30 Oct 2012 12:36:42 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [18.111.3.224]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 84CF7201E2; Tue, 30 Oct 2012 15:36:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2C449412A; Tue, 30 Oct 2012 15:36:41 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> <508E92E2.9060702@deployingradius.com> <004c01cdb657$ce9df200$6bd9d600$@augustcellars.com> <009c01cdb6c3$dc1f9e30$945eda90$@augustcellars.com> <00a101cdb6c8$bf932b60$3eb98220$@augustcellars.com> Date: Tue, 30 Oct 2012 15:36:41 -0400 In-Reply-To: <00a101cdb6c8$bf932b60$3eb98220$@augustcellars.com> (Jim Schaad's message of "Tue, 30 Oct 2012 11:02:37 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 19:36:44 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> I agree that an access reject from RADIUS is the correct way to Jim> shut down. Who sends it and when? Alan implied that when the eap stack fails to produce an answer the RADIUS server doesn't have anything else to do. From ietf@augustcellars.com Tue Oct 30 14:43:27 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E2921F85DB for ; Tue, 30 Oct 2012 14:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjjEcE6edQiq for ; Tue, 30 Oct 2012 14:43:27 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5522B21F858F for ; Tue, 30 Oct 2012 14:43:27 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 6EC302CA59; Tue, 30 Oct 2012 14:43:26 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> <508E92E2.9060702@deployingradius.com> <004c01cdb657$ce9df200$6bd9d600$@augustcellars.com> <009c01cdb6c3$dc1f9e30$945eda90$@augustcellars.com> <00a101cdb6c8$bf932b60$3eb98220$@augustcellars.com> In-Reply-To: Date: Tue, 30 Oct 2012 14:43:23 -0700 Message-ID: <00bf01cdb6e7$96848420$c38d8c60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEZytxIIaFEdNJhDJM7vx/kOAZ2BwGjPaFHAqnWy/gBl88lagJaWb/DAf3zB/YB3x+6vwFe2PVXASv/R5UCD9L2AQJ6s1F6Am7DiBECGWV0wwJ8TT80AcLs2osCy+hMBgJS6SC9AYsWd9IBRTk5oJga9oYA Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 21:43:27 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Tuesday, October 30, 2012 12:37 PM > To: Jim Schaad > Cc: 'Alan DeKok'; 'Alper Yegin'; abfab@ietf.org > Subject: Re: [abfab] EAP Applicability: retransmissions > > >>>>> "Jim" == Jim Schaad writes: > > Jim> I agree that an access reject from RADIUS is the correct way to > Jim> shut down. Who sends it and when? > > Alan implied that when the eap stack fails to produce an answer the RADIUS > server doesn't have anything else to do. I think he was talking about the RADIUS server not having any EAP data to send back to the client. And that in that case the server SHOULD send a reject message back. I am looking at the case of the EAP client not having any data to send. The RADIUS server will not have an opportunity to send a reject message, but it will still have some state data for a while (as will the EAP server). Also the GSS-EAP acceptor will have state data that it keeps around because the session has not been shut down from either the RADIUS side or the initiator side. This means that there are three entities waiting for something to happen and nothing going on. Some of this could be fixed if the initiator closes the session in the case that it ignores the EAP packet on the grounds that there is a reliable transport and it knows that it is dead locked. This could force a shutdown of state back to the IdP from the acceptor, although I am not sure at this point what RADIUS message it would send back to spin down state. From yoshihiro.ohba@toshiba.co.jp Tue Oct 30 15:37:49 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDE321F845C for ; Tue, 30 Oct 2012 15:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA1iCQAtLlSN for ; Tue, 30 Oct 2012 15:37:49 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id B6BE421F8448 for ; Tue, 30 Oct 2012 15:37:48 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q9UMbhN9010617; Wed, 31 Oct 2012 07:37:43 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q9UMbh41010164; Wed, 31 Oct 2012 07:37:43 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id HAA10163; Wed, 31 Oct 2012 07:37:43 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q9UMbg3F001914; Wed, 31 Oct 2012 07:37:43 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9UMbgQW015810; Wed, 31 Oct 2012 07:37:42 +0900 (JST) Received: from [133.196.20.219] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MCQ00II99IUSKE0@mail.po.toshiba.co.jp>; Wed, 31 Oct 2012 07:37:42 +0900 (JST) Date: Wed, 31 Oct 2012 07:37:42 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <509056B6.4010501@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> <508E92E2.9060702@deployingradius.com> <004c01cdb657$ce9df200$6bd9d600$@augustcellars.com> <009c01cdb6c3$dc1f9e30$945eda90$@augustcellars.com> <00a101cdb6c8$bf932b60$3eb98220$@augustcellars.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 22:37:49 -0000 (2012/10/31 4:36), Sam Hartman wrote: > > Alan implied that when the eap stack fails to produce an answer the > RADIUS server doesn't have anything else to do. This is not always the case. See the following text in Section 2.2 of RFC 3579: " A RADIUS server determining that a non-fatal error has occurred MAY send an Access-Challenge to the NAS including EAP-Message attribute(s) as well as an Error-Cause attribute [RFC3576] with value 202 (decimal), "Invalid EAP Packet (Ignored)". The Access-Challenge SHOULD encapsulate within EAP-Message attribute(s) the most recently sent EAP-Request packet (including the same Identifier value). On receiving such an Access-Challenge, a NAS implementing previous versions of this specification will decapsulate the EAP-Request and send it to the peer, which will retransmit the EAP-Response. A NAS compliant with this specification, on receiving an Access-Challenge with an Error-Cause attribute of value 202 (decimal) SHOULD discard the EAP-Response packet most recently transmitted to the RADIUS server and check whether additional EAP-Response packets have been received matching the current Identifier value. If so, a new EAP-Response packet, if available, MUST be sent to the RADIUS server within an Access-Request, and the EAP-Message attribute(s) included within the Access-Challenge are silently discarded. If no EAP-Response packet is available, then the EAP-Request encapsulated within the Access-Challenge is sent to the peer, and the retransmission timer is reset. " Yoshihiro Ohba > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From alper.yegin@yegin.org Wed Oct 31 02:25:48 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E9D21F8733 for ; Wed, 31 Oct 2012 02:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gTo8LZvuciK for ; Wed, 31 Oct 2012 02:25:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B73CF21F871E for ; Wed, 31 Oct 2012 02:25:47 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MX1My-1TqV1v1xMy-00WPlg; Wed, 31 Oct 2012 05:25:17 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <00bf01cdb6e7$96848420$c38d8c60$@augustcellars.com> Date: Wed, 31 Oct 2012 11:24:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> <508E92E2.9060702@deployingradius.com> <004c01cdb657$ce9df200$6bd9d600$@augustcellars.com> <009c01cdb6c3$dc1f9e30$945eda90$@augustcellars.com> <00a101cdb6c8$bf932b60$3eb98220$@augustcellars.com> <00bf01cdb6e7$96848420$c38d8c60$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:uGhanmbQqG4/SrMa7OHJPpMKlQrImvyQj+jy9ITkLED odjjzcr13AA7R79l+x8X68RswYVclNqmVHVlVzC6DLAaShs0FV /1A1oVEBSRBjcgs+A3dsU/KSyN++jQzmt5Ukx9ehs4SVziOgno 1801ycQD4SBjc1bA+Aj2EUZksvCJ/Oy7ugU8AMpuPzWENV4X5h M0UhwG2T1Xgj3OQ0QiqEOLgquQuHSW9mZbz31+LNeZfnKtnMK1 Baz2zNnPIFDubKHgjokndYIak0wY191k5zPsd8WahTrhNrHeoJ tndHd1X4H/HjyBxZtS1Sh60pi3UvPa/vFHtIB70YP/+Gwugk2V zUPxj83naqwM5gtX/TpbZjNKGbpvRpGIz5jfxqB+m/ByDMmgFm 1w1QQgvFOY28g== Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 09:25:48 -0000 >=20 >> -----Original Message----- >> From: Sam Hartman [mailto:hartmans@painless-security.com] >> Sent: Tuesday, October 30, 2012 12:37 PM >> To: Jim Schaad >> Cc: 'Alan DeKok'; 'Alper Yegin'; abfab@ietf.org >> Subject: Re: [abfab] EAP Applicability: retransmissions >>=20 >>>>>>> "Jim" =3D=3D Jim Schaad writes: >>=20 >> Jim> I agree that an access reject from RADIUS is the correct way = to >> Jim> shut down. Who sends it and when? >>=20 >> Alan implied that when the eap stack fails to produce an answer the > RADIUS >> server doesn't have anything else to do. >=20 > I think he was talking about the RADIUS server not having any EAP data = to > send back to the client. And that in that case the server SHOULD send = a > reject message back. >=20 > I am looking at the case of the EAP client not having any data to = send. The > RADIUS server will not have an opportunity to send a reject message, = but it > will still have some state data for a while (as will the EAP server).=20= >=20 > Also the GSS-EAP acceptor will have state data that it keeps around = because > the session has not been shut down from either the RADIUS side or the > initiator side. >=20 > This means that there are three entities waiting for something to = happen > and nothing going on. Some of this could be fixed if the initiator = closes > the session in the case that it ignores the EAP packet Well, the EAP packet may be ignored at the EAP layer or at the EAP = authentication method layer.=20 The EAP lower layer does not know when such a thing happens.=20 Alper > on the grounds that > there is a reliable transport and it knows that it is dead locked. = This > could force a shutdown of state back to the IdP from the acceptor, = although > I am not sure at this point what RADIUS message it would send back to = spin > down state. >=20 >=20 >=20 From hartmans@painless-security.com Wed Oct 31 04:57:13 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C9F21F87B6 for ; Wed, 31 Oct 2012 04:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFrkF1RnhpvT for ; Wed, 31 Oct 2012 04:57:13 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id CAA2821F87B5 for ; Wed, 31 Oct 2012 04:57:12 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 09A35201D1; Wed, 31 Oct 2012 07:56:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8A294412A; Wed, 31 Oct 2012 07:57:10 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> <508E92E2.9060702@deployingradius.com> <004c01cdb657$ce9df200$6bd9d600$@augustcellars.com> <009c01cdb6c3$dc1f9e30$945eda90$@augustcellars.com> <00a101cdb6c8$bf932b60$3eb98220$@augustcellars.com> <00bf01cdb6e7$96848420$c38d8c60$@augustcellars.com> Date: Wed, 31 Oct 2012 07:57:10 -0400 In-Reply-To: <00bf01cdb6e7$96848420$c38d8c60$@augustcellars.com> (Jim Schaad's message of "Tue, 30 Oct 2012 14:43:23 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 11:57:13 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> I think he was talking about the RADIUS server not having any Jim> EAP data to send back to the client. And that in that case the Jim> server SHOULD send a reject message back. Jim> I am looking at the case of the EAP client not having any data Jim> to send. The RADIUS server will not have an opportunity to Jim> send a reject message, but it will still have some state data Jim> for a while (as will the EAP server). OK. I'm sorry, I should not have tried to respond to mail while paying attention to a session in a conference. What happens here on the initiator is that the initiator needs to return some status other than GSS_S_CONTINUE_NEEDED. GSS_S_COMPLETE is kind of implausible, so GSS_ERROR will be true for that status. The initiator then should call gss_delete_sec_context. At this point, the initiator is done and has cleaned up state. Alper claims that the initiator will not know that the EAP layers have failed to produce output and are done processing the packet. I cannot think of a plausible EAP implementation strategy with this characteristic, so I suspect Alper is not correct for likely EAP implementations. Anything that lets you examine the RFC 4137 state will allow you to determine what's going on. Certainly anything that you can use for implementing GSS-EAP has the property that you'll know when it's done with a packet. The existing GSS C bindings are sufficiently synchronous that you'll need that property. After experimenting with other strategies, we've generally come to the conclusion that applications rather than GSS mechanisms need to be responsible for signaling initiator failure. In some protocols you do this with a TCP close. In some protocols such as IMAP, there's a SASL abort that you signal. I think that the GSS mechanism could return an error token at this point; a quick reading of RFC 2743 2.2.1 is unclear. However, I'd recommend against changing gss-eap to permit this. I think returning an output token with an error status will confuse a lot of applications. I do think it would be desirable to add text to draft-ietf-abfab-arch noting that applications SHOULD have a way to signal authentication aborts. --Sam