From Josh.Howlett@ja.net Mon Oct 3 13:55:23 2011 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 C85C521F8EC8 for ; Mon, 3 Oct 2011 13:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.579 X-Spam-Level: X-Spam-Status: No, score=-101.579 tagged_above=-999 required=5 tests=[AWL=-1.580, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaxUu+k1VIVv for ; Mon, 3 Oct 2011 13:55:23 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0DA21F8EC1 for ; Mon, 3 Oct 2011 13:55:23 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 555B24A6B64_E8A21F1B; Mon, 3 Oct 2011 20:58:25 +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 30C984A6B62_E8A21F1F; Mon, 3 Oct 2011 20:58:25 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Mon, 3 Oct 2011 21:58:18 +0100 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] Core documents: where we are Thread-Index: AQHMefoDTBUf+ktgM0iyUHPFjBmhZJVbEjPo///vpQCAAAmNgIAAOKCAgAAanpSAABbdgIAAHCpcgA+YtwA= Date: Mon, 3 Oct 2011 20:58:17 +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.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <93A9BB11FE07A849AA5DACDB8431D07C@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Core documents: where we are 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, 03 Oct 2011 20:55:23 -0000 > >Or fold it all into aaa-saml. Ok, I'll have an updated revision within a week or two. Josh. JANET(UK) 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 leifj@mnt.se Tue Oct 4 05:26:11 2011 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 EAAFA21F8CCD for ; Tue, 4 Oct 2011 05:26: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGc8URMpkT1u for ; Tue, 4 Oct 2011 05:26:11 -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 0C5D921F8CA6 for ; Tue, 4 Oct 2011 05:26:10 -0700 (PDT) Received: from [198.86.189.214] (fmm-mcncday-189-214.internet2.edu [198.86.189.214]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p94CT9fq027441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Oct 2011 14:29:13 +0200 (CEST) Message-ID: <4E8AFC15.1070806@mnt.se> Date: Tue, 04 Oct 2011 14:29:09 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Core documents: where we are 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, 04 Oct 2011 12:26:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/03/2011 10:58 PM, Josh Howlett wrote: > >> >> Or fold it all into aaa-saml. > > Ok, I'll have an updated revision within a week or two. Good! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6K/BUACgkQ8Jx8FtbMZneIGACgvutcY35jlkno+Xz9h+Am+2+M q5sAn2nLpmIyMk/XF8uXNCREt0uwBjfG =DH/O -----END PGP SIGNATURE----- From ietf@augustcellars.com Tue Oct 4 13:44:37 2011 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 2710C21F8D59 for ; Tue, 4 Oct 2011 13:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC-0FgI2HiDS for ; Tue, 4 Oct 2011 13:44:36 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 54A5021F8D39 for ; Tue, 4 Oct 2011 13:44:35 -0700 (PDT) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (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 DFA8938F2F; Tue, 4 Oct 2011 12:56:15 -0700 (PDT) From: "Jim Schaad" To: , "Sam Hartman" , Date: Tue, 4 Oct 2011 13:34:44 -0700 Message-ID: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us thread-index: AcxInUV8CgnQzAy9RwisFpKHs6dSMw== Subject: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 04 Oct 2011 20:44:37 -0000 Sam and Josh, I apologize; I have been going through unsent mail and other files where I make comments. I had actually done most of a review, but had not completed it and therefore had not sent the review to the list. I thought it was out but was in error, thus my earlier message. Jim 1. In section 1.2, under what circumstances would an acceptor fail to respond to an initiator short of a transport failure? Can this ever happen in a success case? If it cannot then I would suggest that /acceptor may respond/ be changed to /acceptor responds/ I guess there would also be a question of the initial negotiation being anything other than query/response - for example an EAP retry would be sourced from the acceptor and might not be expected by the initiator. 2. In section 1.2 para #2 - we have not established what the peer and authenticator are for EAP. It would be a good idea to identify who is whom. Suggest adding a sentence similar to the first sentence in the previous paragraph. 3. In section 1.2 - I have always been worried about the statement that EAP authentication can start w/ the peer, but the first message is always from the authenticator. I believe that it would be more correct to state that EAP authentication always starts with the authenticator, but it may start with the peer for any given EAP mechanism. 4. In section 1.2 - I would suggest that /GSS-API peer/ becomes /GSS-API acceptor/ This keeps the term peer to be used only for EAP and only for the GSS-API initiator (possibly unless we are dealing with terms for an EAP pass-through system) 5. In section 1.2 - You say that the GSS-API acceptor acts as an EAP pass-through authenticator. I am not sure if that means that the GSS-API acceptor needs to deal with the requirements for an EAP pass-through such as the fact that it is supposed to check the record value of EAP item rather than just pass-it through. 6. In section 3 - I have a real problem with the first sentence in the section. I don't believe that it is a true statement. What is authenticated is going to be based on what the EAP method is and what is expected. I have always assumed that it starts by authenticating a user to a realm as the single authentication and different things for mutual authentication. It might be that the sentence was supposed to be "EAP authenticates within a realm." 7. Is the BNF in section 3.1 supposed to ensure that a name cannot be "shartman@janet.edu"? Currently you would need to say "shartman/@janet.edu" 8. In section 3.1 An example of a GSS_C_NT_HOSTBASED_SERVICE name would be useful for people w/o sufficient background. I would need to look farther on this, but based on this text I would end up with something like "smtp.example.com@SMTP" as a host name. However this looks very strange to me. 9. In section 3.3 -- Which acceptor name must be sent in the AAA transport? There are three different ones listed above, or this could be a completely different field. It might also be that the portions are to be re-composed in order to send onto the client in the EAP channel, if this is the case then why do the decomposition? 10. In section 3.3 - is the client signaling mutual authentication on the EAP channel or on the GSS-API channel? 11. In section 5.5 - who does the initiator return the error message to? What state should it transition to? Should it still accept an error from the acceptor in the GSS-API protocol? 12. In section 5.6 - It is not clear to me if one can progress from the Extension State to the Extension state rather than the completed state as part of negotiation of option features. Is this something that needs to be clarified? 13. In Section 5.6.1 - is the flag bit of 0x1 reserved for some purpose? If so this needs to be documented. If not then why not start with mutual auth at 0x1 rather than 0x2. 14. In section 5.6.3 - Do I assume that it is so obvious that it does not need to be stated that the EAP negotiated key is used for the MIC w/o any further key derivation work? 15. In section 5.7 - I am not clear what set of channel binding data needs to be included in the EAP method. Would this be data about the channel carrying the GSS-API methods or the GSS-API/AAA channel or both? I assume this should really include channel data all the way from the acceptor to the EAP server but I don't know that. How much does this differ from the acceptor name referenced in question 9? Typos: s/thearchitecture/the architectural/ or /the architectures/ s/authorisation/authorization/ - American English spellings preferred check if passthrough is a single word or should be pass-through. My dictionary dislikes it as a single word. s/receievs/receives/ s/faris/far is/ From klaas@cisco.com Wed Oct 5 00:44:32 2011 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 20A9721F8AFE for ; Wed, 5 Oct 2011 00:44:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyIzlO3BZ2AQ for ; Wed, 5 Oct 2011 00:44:31 -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 197BE21F8AFB for ; Wed, 5 Oct 2011 00:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=5449; q=dns/txt; s=iport; t=1317800858; x=1319010458; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8NGFH+ucFGzZ1WnQ3TpeRGc6mK8sdwCXThRHcNMk9Qc=; b=kKdHprutQDhWp5fPqwVYa7dK3VLGU6MBArrZ0XAqIOeu00I/RxM9ouuV NXBIIXZIRZCbukCSq/T+xJp+4ApPWwHTeEOxN2xY+PiGKKQ51QKP2DN+N PiCkgML5gl3T6+CYC4xnQtg44GYVun85O4Bim4j7yuxh2tHzB2oiJuFrg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADALjE6tJV2c/2dsb2JhbAA4CqgPgQWBUwEBAQECAQEBAQ8BJzQLBQsLDjgnMAYTIodbBpkyAZ4FA4N3gkthBJNnkUY X-IronPort-AV: E=Sophos;i="4.68,490,1312156800"; d="scan'208";a="26152063" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 05 Oct 2011 07:47:38 +0000 Received: from rtp-kwiereng-87113.cisco.com (rtp-kwiereng-87113.cisco.com [10.116.7.46]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p957laBL021506; Wed, 5 Oct 2011 07:47:37 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Klaas Wierenga In-Reply-To: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> Date: Wed, 5 Oct 2011 09:47:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) Cc: abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 07:44:32 -0000 Thanks Jim! Klaas On Oct 4, 2011, at 10:34 PM, Jim Schaad wrote: > Sam and Josh, >=20 > I apologize; I have been going through unsent mail and other files = where I > make comments. I had actually done most of a review, but had not = completed > it and therefore had not sent the review to the list. I thought it = was out > but was in error, thus my earlier message. >=20 > Jim >=20 >=20 >=20 > 1. In section 1.2, under what circumstances would an acceptor fail to > respond to an initiator short of a transport failure? Can this ever = happen > in a success case? If it cannot then I would suggest that /acceptor = may > respond/ be changed to /acceptor responds/ I guess there would = also be > a question of the initial negotiation being anything other than > query/response - for example an EAP retry would be sourced from the = acceptor > and might not be expected by the initiator. >=20 > 2. In section 1.2 para #2 - we have not established what the peer and > authenticator are for EAP. It would be a good idea to identify who is = whom. > Suggest adding a sentence similar to the first sentence in the = previous > paragraph. >=20 > 3. In section 1.2 - I have always been worried about the statement = that EAP > authentication can start w/ the peer, but the first message is always = from > the authenticator. I believe that it would be more correct to state = that > EAP authentication always starts with the authenticator, but it may = start > with the peer for any given EAP mechanism. >=20 > 4. In section 1.2 - I would suggest that /GSS-API peer/ becomes = /GSS-API > acceptor/ This keeps the term peer to be used only for EAP and only = for the > GSS-API initiator (possibly unless we are dealing with terms for an = EAP > pass-through system) >=20 > 5. In section 1.2 - You say that the GSS-API acceptor acts as an EAP > pass-through authenticator. I am not sure if that means that the = GSS-API > acceptor needs to deal with the requirements for an EAP pass-through = such as > the fact that it is supposed to check the record value of EAP item = rather > than just pass-it through. >=20 > 6. In section 3 - I have a real problem with the first sentence in the > section. I don't believe that it is a true statement. What is > authenticated is going to be based on what the EAP method is and what = is > expected. I have always assumed that it starts by authenticating a = user to > a realm as the single authentication and different things for mutual > authentication. It might be that the sentence was supposed to be "EAP > authenticates within a realm." >=20 > 7. Is the BNF in section 3.1 supposed to ensure that a name cannot be > "shartman@janet.edu"? Currently you would need to say = "shartman/@janet.edu" >=20 > 8. In section 3.1 An example of a GSS_C_NT_HOSTBASED_SERVICE name = would be > useful for people w/o sufficient background. I would need to look = farther > on this, but based on this text I would end up with something like > "smtp.example.com@SMTP" as a host name. However this looks very = strange to > me. >=20 > 9. In section 3.3 -- Which acceptor name must be sent in the AAA = transport? > There are three different ones listed above, or this could be a = completely > different field. It might also be that the portions are to be = re-composed > in order to send onto the client in the EAP channel, if this is the = case > then why do the decomposition? >=20 > 10. In section 3.3 - is the client signaling mutual authentication on = the > EAP channel or on the GSS-API channel? >=20 > 11. In section 5.5 - who does the initiator return the error message = to? > What state should it transition to? Should it still accept an error = from > the acceptor in the GSS-API protocol? >=20 > 12. In section 5.6 - It is not clear to me if one can progress from = the > Extension State to the Extension state rather than the completed state = as > part of negotiation of option features. Is this something that needs = to be > clarified? >=20 > 13. In Section 5.6.1 - is the flag bit of 0x1 reserved for some = purpose? > If so this needs to be documented. If not then why not start with = mutual > auth at 0x1 rather than 0x2. >=20 > 14. In section 5.6.3 - Do I assume that it is so obvious that it does = not > need to be stated that the EAP negotiated key is used for the MIC w/o = any > further key derivation work? >=20 > 15. In section 5.7 - I am not clear what set of channel binding data = needs > to be included in the EAP method. Would this be data about the = channel > carrying the GSS-API methods or the GSS-API/AAA channel or both? I = assume > this should really include channel data all the way from the acceptor = to the > EAP server but I don't know that. How much does this differ from the > acceptor name referenced in question 9? >=20 >=20 >=20 > Typos: >=20 > s/thearchitecture/the architectural/ or /the architectures/ > s/authorisation/authorization/ - American English spellings = preferred > check if passthrough is a single word or should be pass-through. My > dictionary dislikes it as a single word. > s/receievs/receives/ > s/faris/far is/ >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From lukeh@padl.com Wed Oct 5 00:57:53 2011 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 ECD1921F8AFB for ; Wed, 5 Oct 2011 00:57:52 -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=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSSCxOm4YAsk for ; Wed, 5 Oct 2011 00:57:52 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE1B21F8AE1 for ; Wed, 5 Oct 2011 00:57:52 -0700 (PDT) Received: by us.padl.com with ESMTP id p9580tVv014146; Wed, 5 Oct 2011 04:00:58 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Luke Howard In-Reply-To: <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> Date: Wed, 5 Oct 2011 19:00:55 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <06E50535-280E-46F5-92F7-D358733EB791@padl.com> References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> To: abfab@ietf.org X-Mailer: Apple Mail (2.1244.3) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 07:57:53 -0000 > 8. In section 3.1 An example of a GSS_C_NT_HOSTBASED_SERVICE name = would be > useful for people w/o sufficient background. I would need to look = farther > on this, but based on this text I would end up with something like > "smtp.example.com@SMTP" as a host name. However this looks very = strange to > me. smtp@smtp.example.com would be correct, I agree this notation is = confusing, given that most administrators are more familiar with the SPN = notation used by Kerberos (smtp/smtp.example.com). > 13. In Section 5.6.1 - is the flag bit of 0x1 reserved for some = purpose? > If so this needs to be documented. If not then why not start with = mutual > auth at 0x1 rather than 0x2. The flags are from RFC 2744 (e.g. GSS_C_MUTUAL_FLAG is 2). Whilst the = initiator should only disclose flags that are relevant to completing the = authentication, this allows for future expansion (for example, an = initiator that supports DCE-style authentication might use this to = select GSS_C_DCE_STYLE). > 14. In section 5.6.3 - Do I assume that it is so obvious that it does = not > need to be stated that the EAP negotiated key is used for the MIC w/o = any > further key derivation work? I'm wondering actually whether should derive a new key and use RFC 3961 = directly rather than GSS_GetMIC(). This might avoid some sequencing = issues; the MIT Unwrap/VerifyMIC code checks sequence numbers within a = window, and I'm wondering if there might be some attacks because of = this. (Of course, this may just be an implementation bug, I need to do = more research.) -- Luke= From hartmans@painless-security.com Wed Oct 5 08:04:57 2011 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 E75E221F8CEC for ; Wed, 5 Oct 2011 08:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCRgpIOGavvl for ; Wed, 5 Oct 2011 08:04:57 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 021DA21F8CEA for ; Wed, 5 Oct 2011 08:04:56 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0B2D120246; Wed, 5 Oct 2011 11:09:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4AFA54235; Wed, 5 Oct 2011 11:08:04 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> Date: Wed, 05 Oct 2011 11:08:04 -0400 In-Reply-To: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> (Jim Schaad's message of "Tue, 4 Oct 2011 13:34:44 -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] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 15:04:58 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> Sam and Josh, I apologize; I have been going through unsent Jim> mail and other files where I make comments. I had actually Jim> done most of a review, but had not completed it and therefore Jim> had not sent the review to the list. I thought it was out but Jim> was in error, thus my earlier message. Jim> Jim Jim> 1. In section 1.2, under what circumstances would an acceptor Jim> fail to respond to an initiator short of a transport failure? Jim> Can this ever happen in a success case? If it cannot then I Jim> would suggest that /acceptor may respond/ be changed to Jim> /acceptor responds/ I've made the change. Technically some protocols declare failure at a level higher than GSS and abandon the authentication at the GSS layer. In this case, the acceptor never responds at the gss layer ever though gss has not failed. However, I don't think this complexity is worth going into so I've adopted your proposed change. Jim> I guess there would also be a question of Jim> the initial negotiation being anything other than Jim> query/response - for example an EAP retry would be sourced from Jim> the acceptor and might not be expected by the initiator. EAP retries MUST never happen with gss-eap. We don't seem to say that though. I've added a sentence to that affect in 1.2. Jim> 2. In section 1.2 para #2 - we have not established what the Jim> peer and authenticator are for EAP. It would be a good idea to Jim> identify who is whom. Suggest adding a sentence similar to the Jim> first sentence in the previous paragraph. I did so, it's much more complicated though because of the split between the passthrough authenticator and EAP server. Jim> 3. In section 1.2 - I have always been worried about the Jim> statement that EAP authentication can start w/ the peer, but Jim> the first message is always from the authenticator. I believe Jim> that it would be more correct to state that EAP authentication Jim> always starts with the authenticator, but it may start with the Jim> peer for any given EAP mechanism. No. What's meant by that statement is that either the peer or the authenticator's lower layer machinery may trigger the EAP state machine into action. That always happens with the peer in our lower layer, so I'm removing the statement. I've also added a note that we need to prod the EAP authenticator into doing something to get things started. Jim> 4. In section 1.2 - I would suggest that /GSS-API peer/ Jim> becomes /GSS-API acceptor/ This keeps the term peer to be used Jim> only for EAP and only for the GSS-API initiator (possibly Jim> unless we are dealing with terms for an EAP pass-through Jim> system) right. Jim> 5. In section 1.2 - You say that the GSS-API acceptor acts as Jim> an EAP pass-through authenticator. I am not sure if that means Jim> that the GSS-API acceptor needs to deal with the requirements Jim> for an EAP pass-through such as the fact that it is supposed to Jim> check the record value of EAP item rather than just pass-it Jim> through. It should. Jim> 6. In section 3 - I have a real problem with the first sentence Jim> in the section. I don't believe that it is a true statement. Jim> What is authenticated is going to be based on what the EAP Jim> method is and what is expected. I have always assumed that it Jim> starts by authenticating a user to a realm as the single Jim> authentication and different things for mutual authentication. Jim> It might be that the sentence was supposed to be "EAP Jim> authenticates within a realm." The sentence reads "EAP authenticates a user to a realm," now. Jim> 7. Is the BNF in section 3.1 supposed to ensure that a name Jim> cannot be "shartman@janet.edu"? Currently you would need to Jim> say "shartman/@janet.edu" The BNF is wrong; I have review comments on this and will deal. Sorry that failed to happen for the last update. Jim> 8. In section 3.1 An example of a GSS_C_NT_HOSTBASED_SERVICE Jim> name would be useful for people w/o sufficient background. I Jim> would need to look farther on this, but based on this text I Jim> would end up with something like "smtp.example.com@SMTP" as a Jim> host name. However this looks very strange to me. You'd actually have something like smtp@example.com imported as GSS_C_NT_HOSTBASED_SERVICE would become smtp/example.com@ .Any chance you could provide example text that would clarify what you found confusing? Jim> 9. In section 3.3 -- Which acceptor name must be sent in the Jim> AAA transport? There are three different ones listed above, or Jim> this could be a completely different field. It might also be Jim> that the portions are to be re-composed in order to send onto Jim> the client in the EAP channel, if this is the case then why do Jim> the decomposition? You want to send all the non-empty portions. The reason to decompose is to make life easier for proxies; different portions are verified at different places. Also, acceptors may not known their realm, but proxies may insert this. Jim> 10. In section 3.3 - is the client signaling mutual Jim> authentication on the EAP channel or on the GSS-API channel? GSS channel; clarified. Jim> 11. In section 5.5 - who does the initiator return the error Jim> message to? What state should it transition to? Should it Jim> still accept an error from the acceptor in the GSS-API Jim> protocol? GSS_Init_Sec_context returns an error. I clarified no output token is produced in this case. That terminates the initiator state machine; the context is invalid at that point according to 2743. Jim> 12. In section 5.6 - It is not clear to me if one can progress Jim> from the Extension State to the Extension state rather than the Jim> completed state as part of negotiation of option features. Is Jim> this something that needs to be clarified? Not currently. There is not currently a transition from extensions to extensions. You could presumably include messages in earlier states as optional tokens indicating support for that and then include an extension that required that, but the current state machine does not support this. I think we don't need the complexity now and I think it's sufficiently future-proofed that we can get it when we need it. Jim> 13. In Section 5.6.1 - is the flag bit of 0x1 reserved for Jim> some purpose? If so this needs to be documented. If not then Jim> why not start with mutual auth at 0x1 rather than 0x2. These flags are intended to align with flags in RFC 2744 for convenience of implementation. Jim> 14. In section 5.6.3 - Do I assume that it is so obvious that Jim> it does not need to be stated that the EAP negotiated key is Jim> used for the MIC w/o any further key derivation work? No; that's actually kind of non-sensical. The EAP key is a bit string. GSS_GetMIC requires indirectly an RFC 3961 key. The CRK is used. I've added a reference. Jim> 15. In section 5.7 - I am not clear what set of channel binding Jim> data needs to be included in the EAP method. Would this be Jim> data about the channel carrying the GSS-API methods or the Jim> GSS-API/AAA channel or both? I assume this should really Jim> include channel data all the way from the acceptor to the EAP Jim> server but I don't know that. How much does this differ from Jim> the acceptor name referenced in question 9? It's exactly the same; there is already a reference to 3.3 in that Jim> paragraph. What additional text would you like? Jim> Typos: Jim> s/thearchitecture/the architectural/ or /the architectures/ Jim> s/authorisation/authorization/ - American English spellings Jim> preferred check if passthrough is a single word or should be Jim> pass-through. My dictionary dislikes it as a single word. Jim> s/receievs/receives/ s/faris/far is/ fixed, thanks. All appearing in the next update to be published within a week or two. From hartmans@painless-security.com Wed Oct 5 08:18:06 2011 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 5A85921F8D49 for ; Wed, 5 Oct 2011 08:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPG2-z2z1HlD for ; Wed, 5 Oct 2011 08:18:06 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E958121F8D48 for ; Wed, 5 Oct 2011 08:18:05 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7011720246; Wed, 5 Oct 2011 11:22:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AC4D74235; Wed, 5 Oct 2011 11:21:13 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> Date: Wed, 05 Oct 2011 11:21:13 -0400 In-Reply-To: <06E50535-280E-46F5-92F7-D358733EB791@padl.com> (Luke Howard's message of "Wed, 5 Oct 2011 19:00:55 +1100") 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] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 15:18:06 -0000 >>>>> "Luke" == Luke Howard writes: >> 14. In section 5.6.3 - Do I assume that it is so obvious that it >> does not need to be stated that the EAP negotiated key is used >> for the MIC w/o any further key derivation work? Luke> I'm wondering actually whether should derive a new key and use Luke> RFC 3961 directly rather than GSS_GetMIC(). This might avoid Luke> some sequencing issues; the MIT Unwrap/VerifyMIC code checks Luke> sequence numbers within a window, and I'm wondering if there Luke> might be some attacks because of this. (Of course, this may Luke> just be an implementation bug, I need to do more research.) I'd prefer an RFC 3961 getmic directly using the CRK and a new key usage. Rationale: makes prot_ready more possible if we ever want to do that. I thought there was some reason you didn't want to do that though. I thought I brought up using 3961 directly here. Reauth? From lukeh@padl.com Wed Oct 5 08:32:29 2011 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 5262921F8C93 for ; Wed, 5 Oct 2011 08:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDPitzXfkF8t for ; Wed, 5 Oct 2011 08:32:28 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id AE9EB21F8C6C for ; Wed, 5 Oct 2011 08:32:28 -0700 (PDT) Received: by us.padl.com with ESMTP id p95FZNGh028597; Wed, 5 Oct 2011 11:35:29 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Thu, 6 Oct 2011 02:35:23 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> To: Sam Hartman X-Mailer: Apple Mail (2.1244.3) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 15:32:29 -0000 > I'd prefer an RFC 3961 getmic directly using the CRK and a new key > usage. Sounds good -- and simple to implement. If we do this for channel = bindings too then we can allow the acceptor to ignore them without = disturbing the sequence state. That avoids the overhead of sending a = wrap token which we currently do. Can you propose some key usage = numbers? > I thought there was some reason you didn't want to do that though. I > thought I brought up using 3961 directly here. > Reauth? No, the reason was I was hoping that it might be possible to reuse = existing RFC 4121 implementations (e.g. on Windows). But I realise now = that both options are equally (im)practical. -- Luke= From hartmans@painless-security.com Wed Oct 5 10:15:47 2011 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 6655E21F8CF2 for ; Wed, 5 Oct 2011 10:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPJh1fW0GTzY for ; Wed, 5 Oct 2011 10:15:47 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id F3DFD21F8C9E for ; Wed, 5 Oct 2011 10:15:46 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 545B320239; Wed, 5 Oct 2011 13:20:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 851894235; Wed, 5 Oct 2011 13:18:48 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> Date: Wed, 05 Oct 2011 13:18:48 -0400 In-Reply-To: (Luke Howard's message of "Thu, 6 Oct 2011 02:35:23 +1100") 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] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 17:15:47 -0000 >>>>> "Luke" == Luke Howard writes: >> I'd prefer an RFC 3961 getmic directly using the CRK and a new >> key usage. Luke> Sounds good -- and simple to implement. If we do this for Luke> channel bindings too then we can allow the acceptor to ignore Luke> them without disturbing the sequence state. That avoids the Luke> overhead of sending a wrap token which we currently do. Can Luke> you propose some key usage numbers? Do we want our own key usage registry or do we want to use krb-wg's? If krb-wg's then I need to ask Tom Yu right now. If we want our own we can add a registry in gss-eap. Using krb-wg's makes it very sure there won't be any attacks that result. However it's probably fine for us to use our own if we guarantee that our key usages will only be used with keys that we get from a GMSK rather than say from a KDC. From ietf@augustcellars.com Wed Oct 5 11:40:19 2011 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 444B111E80A1 for ; Wed, 5 Oct 2011 11:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kFMgriajMiI for ; Wed, 5 Oct 2011 11:40:18 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id C86D211E809A for ; Wed, 5 Oct 2011 11:40:18 -0700 (PDT) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (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 12C772C9F8; Wed, 5 Oct 2011 11:43:27 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "'Luke Howard'" References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> In-Reply-To: Date: Wed, 5 Oct 2011 12:22:03 -0700 Message-ID: <04cf01cc8394$10d05930$32710b90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us thread-index: AQKDdjBVwz0c7/dteMiMEi7SbQlCdQHbf+8uAd/LlwcB4hzehAG3rhqKAsRnceCTr2+akA== Cc: abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 18:40:19 -0000 Emotionally I think that I would say take them from the krb-wg registry so that they are not used there in the future which might lead to problems. Logically, I don't think it matters. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Wednesday, October 05, 2011 10:19 AM > To: Luke Howard > Cc: abfab@ietf.org > Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 > > >>>>> "Luke" == Luke Howard writes: > > >> I'd prefer an RFC 3961 getmic directly using the CRK and a new > >> key usage. > > Luke> Sounds good -- and simple to implement. If we do this for > Luke> channel bindings too then we can allow the acceptor to ignore > Luke> them without disturbing the sequence state. That avoids the > Luke> overhead of sending a wrap token which we currently do. Can > Luke> you propose some key usage numbers? > > Do we want our own key usage registry or do we want to use krb-wg's? If > krb-wg's then I need to ask Tom Yu right now. If we want our own we can > add a registry in gss-eap. > > Using krb-wg's makes it very sure there won't be any attacks that result. > However it's probably fine for us to use our own if we guarantee that our key > usages will only be used with keys that we get from a GMSK rather than say > from a KDC. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From lukeh@padl.com Wed Oct 5 14:59:41 2011 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 A849F11E80B1 for ; Wed, 5 Oct 2011 14:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1wdRHWALFij for ; Wed, 5 Oct 2011 14:59:41 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0FE11E8082 for ; Wed, 5 Oct 2011 14:59:40 -0700 (PDT) Received: by us.padl.com with ESMTP id p95M0wL7002019; Wed, 5 Oct 2011 18:01:05 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <04cf01cc8394$10d05930$32710b90$@augustcellars.com> Date: Thu, 6 Oct 2011 09:00:57 +1100 Content-Transfer-Encoding: 7bit Message-Id: <6D378EE1-5AAB-4D69-A3A9-9FCE130FBE06@padl.com> References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> <04cf01cc8394$10d05930$32710b90$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 21:59:41 -0000 On 06/10/2011, at 6:22 AM, Jim Schaad wrote: > Emotionally I think that I would say take them from the krb-wg registry so > that they are not used there in the future which might lead to problems. Well, there's already quite a lot of reuse in the krb-wg registry :-) But sure, I agree. I'll ask Tom. -- Luke From lukeh@padl.com Wed Oct 5 15:46:11 2011 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 4CD9111E8122 for ; Wed, 5 Oct 2011 15:46:11 -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.727, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSrlneOW4t-8 for ; Wed, 5 Oct 2011 15:46:10 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id BCE8611E812D for ; Wed, 5 Oct 2011 15:46:10 -0700 (PDT) Received: by us.padl.com with ESMTP id p95MnEk5003997; Wed, 5 Oct 2011 18:49:17 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Luke Howard In-Reply-To: <04cf01cc8394$10d05930$32710b90$@augustcellars.com> Date: Thu, 6 Oct 2011 09:49:14 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> <04cf01cc8394$10d05930$32710b90$@augustcellars.com> To: abfab@ietf.org X-Mailer: Apple Mail (2.1244.3) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 22:46:11 -0000 So, I propose that we replace the existing GSS channel binding and = extension wrap/MIC tokens (respectively) with RFC 3961 checksums using = the CRK with the following key usage numbers: KEY_USAGE_CHANNEL_BINDINGS_MIC TBD KEY_USAGE_ACCEPTOR_TOKEN_MIC TBD KEY_USAGE_INITIATOR_TOKEN_MIC TBD A nice property of this is that we can efficiently deal with large GSS = channel bindings (because we are sending a checksum rather than a wrap = token; recall, we previously sent a wrap token so that the acceptor = could ignore channel bindings without disturbing its sequence state). Comments? -- Luke From nico@cryptonector.com Wed Oct 5 15:54:40 2011 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 2B6EA11E812D for ; Wed, 5 Oct 2011 15:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIl36S9-zVz2 for ; Wed, 5 Oct 2011 15:54:39 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 70EC811E8109 for ; Wed, 5 Oct 2011 15:54:39 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 36D18778075 for ; Wed, 5 Oct 2011 15:57:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=RQWBljWQdRdpnfkcM0yzoQCbG+hfHU7MU5UVFvWfMUKq lnqILroIDe7T5GN2+fpXBr3Ri1fM1i7RvganOvE9IMxkAkeSqgERGkRYPc/pQBJ3 DbkvNbCW3fBU8tr0w+8P1BvgvTu2m/JHmM68YzA5x8ahJgmgc5c8nJ0nhuCvuEU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=isGzHJvITNyr4RTj1yXrkkrP+nQ=; b=mgzeHWpsQzr w+XVueFvYjY3zvrwt653maw3JZXfOR3+rSmduJ82/l5GAzJsru/r+3jZ7X1w3NZT DaAP7DqiMNORYFNZE0Rgmny6MoFIaIZyxOuZ3Qxdtjxin5vfxoCdrGG1bKb57WUu uEV7obXpchFyKCd2sJnzN9K0f5y9y6h0= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 3395877805F for ; Wed, 5 Oct 2011 15:57:40 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2236744vcb.31 for ; Wed, 05 Oct 2011 15:57:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.87.14 with SMTP id u14mr9976vcl.39.1317855458777; Wed, 05 Oct 2011 15:57:38 -0700 (PDT) Received: by 10.220.27.68 with HTTP; Wed, 5 Oct 2011 15:57:38 -0700 (PDT) In-Reply-To: References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> Date: Wed, 5 Oct 2011 17:57:38 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 22:54:40 -0000 On Wed, Oct 5, 2011 at 10:08 AM, Sam Hartman wrote: >>>>>> "Jim" =3D=3D Jim Schaad writes: > =C2=A0 =C2=A0Jim> 1. =C2=A0In section 1.2, under what circumstances would= an acceptor > =C2=A0 =C2=A0Jim> fail to respond to an initiator short of a transport fa= ilure? > =C2=A0 =C2=A0Jim> Can this ever happen in a success case? =C2=A0If it can= not then I > =C2=A0 =C2=A0Jim> would suggest that /acceptor may respond/ be changed to > =C2=A0 =C2=A0Jim> /acceptor responds/ > > I've made the change. > Technically some protocols declare failure at a level higher than GSS > and abandon the authentication at the GSS layer. > In this case, the acceptor never responds at the gss layer ever though > gss has not failed. > However, I don't think this complexity is worth going into so I've > adopted your proposed change. It would be more accurate to say that the GSS-API mechanism can fail without a context token (a token which could only communicate the error, and supplementary information) to send to the other side, and that even when there is such an "error token" the application is not required to send it. Generally only the acceptor would produce an error token. However, it is good form for GSS mechanisms to both, specify and output such error tokens. It should be up to applications whether to send them. And, of course, applications must cope with errors that come with no error token. If EAP has no message suitable for constructing a GSS error token, well, either GSS-EAP could specify one, or you could leave it unspecified and c'est la vie. But spell this out :) Nico -- From lukeh@padl.com Wed Oct 5 15:57:42 2011 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 3814711E80B7 for ; Wed, 5 Oct 2011 15:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI5eE419y+MT for ; Wed, 5 Oct 2011 15:57:41 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 865AC11E80DC for ; Wed, 5 Oct 2011 15:57:41 -0700 (PDT) Received: by us.padl.com with ESMTP id p95N09A1028211; Wed, 5 Oct 2011 19:00:11 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_6C9F6DA0-6E6F-42F9-ACA3-EC388AD8CD75" From: Luke Howard In-Reply-To: Date: Thu, 6 Oct 2011 10:00:08 +1100 Message-Id: <5767853B-B8F1-48D3-965D-CB6D1A0203B4@padl.com> References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> To: Nico Williams X-Mailer: Apple Mail (2.1244.3) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 22:57:42 -0000 --Apple-Mail=_6C9F6DA0-6E6F-42F9-ACA3-EC388AD8CD75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > If EAP has no message suitable for constructing a GSS error token, > well, either GSS-EAP could specify one, or you could leave it > unspecified and c'est la vie. But spell this out :) Well, we have errors at the GSS EAP layer anyway, so there is a GSS EAP = error token. The draft just needs to be filled in with the minor status = codes, which will be something like this. error_code GSSEAP_WRONG_SIZE, "Buffer is incorrect = size" error_code GSSEAP_WRONG_MECH, "Mechanism OID is = incorrect" error_code GSSEAP_BAD_TOK_HEADER, "Token header is = malformed or corrupt" error_code GSSEAP_TOK_TRUNC, "Token is missing data" error_code GSSEAP_BAD_DIRECTION, "Packet was replayed in = wrong direction" error_code GSSEAP_WRONG_TOK_ID, "Received token ID does = not match expected token ID" error_code GSSEAP_CRIT_ITOK_UNAVAILABLE, "Critical inner token = type unavailable" error_code GSSEAP_MISSING_REQUIRED_ITOK, "Missing required inner = token" error_code GSSEAP_DUPLICATE_ITOK, "Duplicate inner token = received" error_code GSSEAP_WRONG_ITOK, "Recieved invalid inner = token for current state" error_code GSSEAP_KEY_UNAVAILABLE, "EAP key unavailable" error_code GSSEAP_KEY_TOO_SHORT, "EAP key too short" error_code GSSEAP_RADIUS_AUTH_FAILURE, "Authentication rejected = by RADIUS server" error_code GSSEAP_UNKNOWN_RADIUS_CODE, "Received unknown = response code from RADIUS server" error_code GSSEAP_MISSING_EAP_REQUEST, "RADIUS response is = missing EAP request" error_code GSSEAP_RADIUS_PROT_FAILURE, "Generic RADIUS failure" -- Luke= --Apple-Mail=_6C9F6DA0-6E6F-42F9-ACA3-EC388AD8CD75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
If EAP has no message suitable for = constructing a GSS error token,
well, either GSS-EAP could specify = one, or you could leave it
unspecified and c'est la vie.  But = spell this out :)

Well, = we have errors at the GSS EAP layer anyway, so there is a GSS EAP error = token. The draft just needs to be filled in with the minor status codes, = which will be something like this.

error_code = GSSEAP_WRONG_SIZE,               =     "Buffer is incorrect size"
error_code = GSSEAP_WRONG_MECH,               =     "Mechanism OID is incorrect"
error_code = GSSEAP_BAD_TOK_HEADER,               = "Token header is malformed or corrupt"
error_code = GSSEAP_TOK_TRUNC,               =      "Token is missing data"
error_code = GSSEAP_BAD_DIRECTION,               =  "Packet was replayed in wrong direction"
error_code = GSSEAP_WRONG_TOK_ID,               =   "Received token ID does not match expected = token ID"
error_code GSSEAP_CRIT_ITOK_UNAVAILABLE,       =  "Critical inner token type unavailable"
error_code = GSSEAP_MISSING_REQUIRED_ITOK,        "Missing = required inner token"
error_code GSSEAP_DUPLICATE_ITOK,         =       "Duplicate inner token = received"
error_code GSSEAP_WRONG_ITOK,           =         "Recieved invalid inner token for current = state"
error_code GSSEAP_KEY_UNAVAILABLE,         =      "EAP key unavailable"
error_code = GSSEAP_KEY_TOO_SHORT,               =  "EAP key too short"
error_code = GSSEAP_RADIUS_AUTH_FAILURE,         =  "Authentication rejected by RADIUS server"
error_code = GSSEAP_UNKNOWN_RADIUS_CODE,          "Received = unknown response code from RADIUS server"
error_code = GSSEAP_MISSING_EAP_REQUEST,          "RADIUS = response is missing EAP request"
error_code = GSSEAP_RADIUS_PROT_FAILURE,          "Generic = RADIUS failure"

-- = Luke
= --Apple-Mail=_6C9F6DA0-6E6F-42F9-ACA3-EC388AD8CD75-- From nico@cryptonector.com Wed Oct 5 16:00:44 2011 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 D44CC11E8111 for ; Wed, 5 Oct 2011 16:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEbkHLQEletN for ; Wed, 5 Oct 2011 16:00:44 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5615511E80B7 for ; Wed, 5 Oct 2011 16:00:44 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id A6B607E4058 for ; Wed, 5 Oct 2011 16:03:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Ybv4qTS61NrFQW0giYvHCYW4Zmj7joe6T2ssCCpyy8Mt 0srcA96eZvUbyCcdacTCFWkY2I8AipYozL+V52xa5+/qvnDX2muXVdmS4ugjO/Ht aDed5f0MUh4AmffCaQEcHfYnGWMaVOjygtQy/WmdSQd16F97mtTC3EmzO73b7bI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=0cTDx+lxCCmX1PrtWDq1YApIzsQ=; b=nPsXqyyEMap j9Vy9S3yhGAxHY9OezM1zzB5TOTSUBAaGrLMe+8qxlRegxDeGesvhrd5bxLIzjTr 4UoR+BZJQZNe5JDMNsYLhGu3WOu3tCxwxgHkgvcJW/BTfZUWy5cqjWCaOusFdChJ QuPbluClFnj869xzJbGTKKctXuo91v4g= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 6F2097E4072 for ; Wed, 5 Oct 2011 16:03:32 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2239934vcb.31 for ; Wed, 05 Oct 2011 16:03:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.153.3 with SMTP id i3mr10201vcw.74.1317855811848; Wed, 05 Oct 2011 16:03:31 -0700 (PDT) Received: by 10.220.27.68 with HTTP; Wed, 5 Oct 2011 16:03:31 -0700 (PDT) In-Reply-To: References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> <04cf01cc8394$10d05930$32710b90$@augustcellars.com> Date: Wed, 5 Oct 2011 18:03:31 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 23:00:44 -0000 On Wed, Oct 5, 2011 at 5:49 PM, Luke Howard wrote: > So, I propose that we replace the existing GSS channel binding and extens= ion wrap/MIC tokens (respectively) with RFC 3961 checksums using the CRK wi= th the following key usage numbers: > > KEY_USAGE_CHANNEL_BINDINGS_MIC =C2=A0 =C2=A0 =C2=A0TBD > KEY_USAGE_ACCEPTOR_TOKEN_MIC =C2=A0 =C2=A0 =C2=A0 =C2=A0 TBD > KEY_USAGE_INITIATOR_TOKEN_MIC =C2=A0 =C2=A0 =C2=A0 TBD > > A nice property of this is that we can efficiently deal with large GSS ch= annel bindings (because we are sending a checksum rather than a wrap token;= recall, we previously sent a wrap token so that the acceptor could ignore = channel bindings without disturbing its sequence state). > > Comments? Mostly only that I approve. Note that if you really did want to use an RFC4121 per-msg token library and still not get forced into sequencing you have two options available: a) there are no sequencing problems, since RFC4121 can handle out-of-sequence tokens; b) you could create separate "contexts" for internal each use of RFC4121, with different keys in each case, all derived from the EAP keys. Now, RFC4121 is going to require RFC3961/2 anyways, so using RFC3961/2 directly in this part of GSS-EAP is hardly a burden -- unless you have an API to the first but not the second... Nico -- From nico@cryptonector.com Wed Oct 5 16:02:22 2011 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 1D2C121F8CD8 for ; Wed, 5 Oct 2011 16:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZZ4rfPgyM3f for ; Wed, 5 Oct 2011 16:02:21 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id B47FC21F8CD2 for ; Wed, 5 Oct 2011 16:02:21 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id D037610058 for ; Wed, 5 Oct 2011 16:05:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=oPoUGN8U/MJs7czPgq5hhH7OvgT3L9OoRRCVD0y/NZev h0mcTIJWf+fRUgf5y4vqS33t1weiosRb8025egP7hfYzg49XeQoQiXGxCpmQxYYq diaG7YIOdhDfNzDPOmcxPz7dJRW+nIvuprnN+3MxgbSqSos+RXuN/oJXrYmeryU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=e/yKqdnWwhCNlm2/rwjo7EAteoM=; b=VLttxa+70ow 6vjYipRBDDW3mSeF98SkGgl9ITL1c0CzgWO/BWOXIRrME7OqF+BU6ncIvS2gi9Ga W1V9eeQurHQY8lsO0pv9grjTWL2oIgzr7/uDSt+3kK3gaYC4ID1Wom4VG/Hc+Kh/ HCwSQ4uvv8TYVS0/OLG+Lz66F4LLBqQE= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 9DEBD1001C for ; Wed, 5 Oct 2011 16:05:30 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2241135vcb.31 for ; Wed, 05 Oct 2011 16:05:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.93.139 with SMTP id cu11mr41884vdb.77.1317855929975; Wed, 05 Oct 2011 16:05:29 -0700 (PDT) Received: by 10.220.27.68 with HTTP; Wed, 5 Oct 2011 16:05:29 -0700 (PDT) In-Reply-To: <5767853B-B8F1-48D3-965D-CB6D1A0203B4@padl.com> References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <5767853B-B8F1-48D3-965D-CB6D1A0203B4@padl.com> Date: Wed, 5 Oct 2011 18:05:29 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 23:02:22 -0000 On Wed, Oct 5, 2011 at 6:00 PM, Luke Howard wrote: > If EAP has no message suitable for constructing a GSS error token, > well, either GSS-EAP could specify one, or you could leave it > unspecified and c'est la vie. =C2=A0But spell this out :) > > Well, we have errors at the GSS EAP layer anyway, so there is a GSS EAP > error token. The draft just needs to be filled in with the minor status > codes, which will be something like this. Minor status codes don't really have to be defined, IMO, though it certainly doesn't hurt to do so -- particularly if there's something an application can do to recover from a specific error. Nico -- From lukeh@padl.com Wed Oct 5 16:05:52 2011 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 7359D11E8082 for ; Wed, 5 Oct 2011 16:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.214 X-Spam-Level: X-Spam-Status: No, score=-3.214 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ipGzCqnYykl for ; Wed, 5 Oct 2011 16:05:51 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id BB50F21F8CF0 for ; Wed, 5 Oct 2011 16:05:51 -0700 (PDT) Received: by us.padl.com with ESMTP id p95N8tAi015667; Wed, 5 Oct 2011 19:08:58 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Thu, 6 Oct 2011 10:08:55 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> <04cf01cc8394$10d05930$32710b90$@augustcellars.com> To: Nico Williams X-Mailer: Apple Mail (2.1244.3) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 23:05:52 -0000 > a) there are no sequencing problems, since RFC4121 can handle > out-of-sequence tokens; Hmm. I'm not convinced that this wouldn't have created other problems, I = need to think about it some more. > b) you could create separate "contexts" for internal each use of > RFC4121, with different keys in each case, all derived from the EAP > keys. Yes, this would have worked, although using usage numbers and 3961 is a = little easier from an implementation perspective (you only have one = derived key to manage). > Now, RFC4121 is going to require RFC3961/2 anyways, so using RFC3961/2 > directly in this part of GSS-EAP is hardly a burden -- unless you have > an API to the first but not the second... Well, there is an API for RFC4121. But there's no clear way to = manufacture a context purely in order to use its cryptographic services. = (e.g. you could import a fake context, but you'd have to understand its = contents, which are implementation dependent.) So I think it's 6 of one, = half a dozen the other. -- Luke= From nico@cryptonector.com Wed Oct 5 16:10:12 2011 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 4736A21F8CB0 for ; Wed, 5 Oct 2011 16:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aikrt7s79Yfh for ; Wed, 5 Oct 2011 16:10:10 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id AABB921F8C99 for ; Wed, 5 Oct 2011 16:10:10 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 57F2A1F007C for ; Wed, 5 Oct 2011 16:13:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=jMhhqMK2GHhv04qhqsZ8FRrn5Wc9wQ0fp6rr23f8aU49 u9xs3Y2U5ucSXpG4rbrMRHF3K4Cj1NP12AfdE9HxqfkKJXF4HRMZdI7hLQHLH/5B cFaB3sS6bmzeiCkn8Lvz0X5lFbvONrrf1C3jQaCZMFEhER7mVIrfMHqIMcrtkvo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=MFUCYEkKLQUUxbH+sRmRga/k5zA=; b=Vjm3IFY5dsw HHHKqDC+Cop3XDBUdI2Bo8nzwtWhrFmWcnxPD0cj14+EXd7lDHs/LFg7wHlTyM4c 6FKTrHHlgw66SOCg2GV3zUMmrwFdR3zojA+4QBwjOI8JTxyVGIZK365o3Yj9v7ih w7qrYXRJDrc6P+OifdskP/jcpkW4GefU= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 20E381F0078 for ; Wed, 5 Oct 2011 16:13:19 -0700 (PDT) Received: by vws5 with SMTP id 5so2247450vws.31 for ; Wed, 05 Oct 2011 16:13:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.172.207 with SMTP id be15mr38561vdc.144.1317856398525; Wed, 05 Oct 2011 16:13:18 -0700 (PDT) Received: by 10.220.27.68 with HTTP; Wed, 5 Oct 2011 16:13:18 -0700 (PDT) In-Reply-To: References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> <04cf01cc8394$10d05930$32710b90$@augustcellars.com> Date: Wed, 5 Oct 2011 18:13:18 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 05 Oct 2011 23:10:12 -0000 X-List-Received-Date: Wed, 05 Oct 2011 23:10:12 -0000 On Wed, Oct 5, 2011 at 6:08 PM, Luke Howard wrote: >> a) there are no sequencing problems, since RFC4121 can handle >> out-of-sequence tokens; > > Hmm. I'm not convinced that this wouldn't have created other problems, I = need to think about it some more. Well, if you can guarantee that all per-msg tokens will have been processed by the time you're ready to handle the app's tokens... Ah, now I understand Sam's comment about PROT_READY. >> b) you could create separate "contexts" for internal each use of >> RFC4121, with different keys in each case, all derived from the EAP >> keys. > > Yes, this would have worked, although using usage numbers and 3961 is a l= ittle easier from an implementation perspective (you only have one derived = key to manage). Yes, which is why I agree with the proposal :) >> Now, RFC4121 is going to require RFC3961/2 anyways, so using RFC3961/2 >> directly in this part of GSS-EAP is hardly a burden -- unless you have >> an API to the first but not the second... > > > Well, there is an API for RFC4121. But there's no clear way to manufactur= e a context purely in order to use its cryptographic services. (e.g. you co= uld import a fake context, but you'd have to understand its contents, which= are implementation dependent.) So I think it's 6 of one, half a dozen the = other. We ought to define a subset of RFC4121 exported sec contexts for the purpose of using it as a per-msg token library! :) Nico -- From lukeh@padl.com Wed Oct 5 17:08:56 2011 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 3C19921F8D6D for ; Wed, 5 Oct 2011 17:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE+kCvtut3eS for ; Wed, 5 Oct 2011 17:08:55 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id AD16D21F8D67 for ; Wed, 5 Oct 2011 17:08:55 -0700 (PDT) Received: by us.padl.com with ESMTP id p960BsUU011846; Wed, 5 Oct 2011 20:11:57 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Thu, 6 Oct 2011 11:11:54 +1100 Content-Transfer-Encoding: 7bit Message-Id: <2640F336-BAF5-4BD3-AF71-06F8A9D40AB2@padl.com> References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <5767853B-B8F1-48D3-965D-CB6D1A0203B4@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1244.3) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 06 Oct 2011 00:08:56 -0000 On 06/10/2011, at 10:05 AM, Nico Williams wrote: > On Wed, Oct 5, 2011 at 6:00 PM, Luke Howard wrote: >> If EAP has no message suitable for constructing a GSS error token, >> well, either GSS-EAP could specify one, or you could leave it >> unspecified and c'est la vie. But spell this out :) >> >> Well, we have errors at the GSS EAP layer anyway, so there is a GSS EAP >> error token. The draft just needs to be filled in with the minor status >> codes, which will be something like this. > > Minor status codes don't really have to be defined, IMO, though it > certainly doesn't hurt to do so -- particularly if there's something > an application can do to recover from a specific error. If they are on the wire... From nico@cryptonector.com Wed Oct 5 17:30:25 2011 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 7A91611E80CE for ; Wed, 5 Oct 2011 17:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmuZuGWgv6pO for ; Wed, 5 Oct 2011 17:30:25 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB0A11E80AD for ; Wed, 5 Oct 2011 17:30:25 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 2982E508071 for ; Wed, 5 Oct 2011 17:33:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=k3PQ9MhbjLh5B1j27tNvn nMXk0SsBdVcS8vzxZ0YCQh3lZXTuEe8+Npm56LJcp4oncVRgpdFVr3Guj9olK+3m QdANR1syVjb3tIZnS9YIpETgetN2PWqIb2O34FpAGEyq74ZtpgyZPGLTBeL0yonF bbs9mXLIf0vuTqBagGgec4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=g9bXKH1Y79hUL9Mtv4ro eFE/3+0=; b=oPHO8jD4GkbyM1oUMD5C5oKcZbYcOpvyuhuPMiTG/zx+LB01dIBr JhCWnHbW9XUvFwPVTcTpPWKZPz6QRt15OlipZqilkQ6Pq7YPEc5BD89N70UNiUmS WWtwRdji0OwxklOEuvPxdqVThRhUEUaw1zlAYcmtoDOlGOx4RZh9s40= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 00A1A508049 for ; Wed, 5 Oct 2011 17:33:33 -0700 (PDT) Received: by vws5 with SMTP id 5so2289572vws.31 for ; Wed, 05 Oct 2011 17:33:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.93.139 with SMTP id cu11mr107589vdb.77.1317861213251; Wed, 05 Oct 2011 17:33:33 -0700 (PDT) Received: by 10.220.27.68 with HTTP; Wed, 5 Oct 2011 17:33:33 -0700 (PDT) In-Reply-To: <2640F336-BAF5-4BD3-AF71-06F8A9D40AB2@padl.com> References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <5767853B-B8F1-48D3-965D-CB6D1A0203B4@padl.com> <2640F336-BAF5-4BD3-AF71-06F8A9D40AB2@padl.com> Date: Wed, 5 Oct 2011 19:33:33 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 06 Oct 2011 00:30:25 -0000 On Wed, Oct 5, 2011 at 7:11 PM, Luke Howard wrote: > If they are on the wire... Oh, heh, sure. Excuse my silliness. From lukeh@padl.com Thu Oct 6 07:18:41 2011 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 0761121F8D48 for ; Thu, 6 Oct 2011 07:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq35kFSfVIui for ; Thu, 6 Oct 2011 07:18:40 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 85A5A21F8D44 for ; Thu, 6 Oct 2011 07:18:40 -0700 (PDT) Received: by us.padl.com with ESMTP id p96ELTPo024024; Thu, 6 Oct 2011 10:21:32 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <04cf01cc8394$10d05930$32710b90$@augustcellars.com> Date: Fri, 7 Oct 2011 01:21:29 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <365530F6-E7A5-41E9-B72D-C9955BC24C0C@padl.com> References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> <04cf01cc8394$10d05930$32710b90$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 06 Oct 2011 14:18:41 -0000 If we are going to make this change, maybe we should change the = derivation salt for the CRK to "rfc3961-gss-eap". Or is this too = pedantic.=20 -- Luke= From hartmans@painless-security.com Thu Oct 6 09:24:08 2011 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 E441021F8DAF for ; Thu, 6 Oct 2011 09:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V3VKecT-K1l for ; Thu, 6 Oct 2011 09:24:06 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6903221F8DA9 for ; Thu, 6 Oct 2011 09:24:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0A25420CEB; Thu, 6 Oct 2011 12:28:36 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6C2F54235; Thu, 6 Oct 2011 12:27:04 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> Date: Thu, 06 Oct 2011 12:27:04 -0400 In-Reply-To: (Nico Williams's message of "Wed, 5 Oct 2011 17:57:38 -0500") 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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 06 Oct 2011 16:24:08 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Wed, Oct 5, 2011 at 10:08 AM, Sam Hartman Nico> wrote: >>>>>>> "Jim" == Jim Schaad writes: >>    Jim> 1.  In section 1.2, under what >> circumstances would an acceptor    Jim> fail to >> respond to an initiator short of a transport failure?   >> Jim> Can this ever happen in a success case?  If it cannot >> then I    Jim> would suggest that /acceptor may >> respond/ be changed to    Jim> /acceptor responds/ >> >> I've made the change. Technically some protocols declare failure >> at a level higher than GSS and abandon the authentication at the >> GSS layer. In this case, the acceptor never responds at the gss >> layer ever though gss has not failed. However, I don't think >> this complexity is worth going into so I've adopted your proposed >> change. Nico> It would be more accurate to say that the GSS-API mechanism Nico> can fail without a context token (a token which could only Nico> communicate the error, and supplementary information) to send Nico> to the other side, and that even when there is such an "error Nico> token" the application is not required to send it. Generally Nico> only the acceptor would produce an error token. While this is a true statement, it's independent of what I was getting at. My statement still stands. Some protocols decide to abandon a gss authentication progress for their own reasons. It's also true that gss mechanisms fail. Luke has already pointed out we have an error token. It's described in the draft; the registry of values to go in it not yet. From nico@cryptonector.com Thu Oct 6 09:50:55 2011 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 87E9511E8081 for ; Thu, 6 Oct 2011 09:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuPCxNE868em for ; Thu, 6 Oct 2011 09:50:55 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB8921F8D07 for ; Thu, 6 Oct 2011 09:50:55 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 407E988064 for ; Thu, 6 Oct 2011 09:54:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=g328wvTraYUXXQpK4KhOYv2EEXiKxQasDvuMuUSU0Kt9 O2JCGctTAmHdyn6LnkFb6KPhC8OQE+Aa3ewKemsZ+9OBGfxzJZbmbPo129R8vrgX baZtucYBnwySbFJ78vgiq8IzfuyBSgJKaapadx4k5XGME74Qng3Kno29x+IZmkk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=EVaNR2m2zdNlo6oI8rL0nL6qeNQ=; b=tMGb1iUvArg 3ttMT30OPJ5DEYqrmmK7v/EU7vMdPSK4miq76IsAuDEBNTArNfB2TWP3mFNidVXP 4Bk+puPkuKAULw7PontuH16VvEJYks8XlNzJmcDwFVDJSZDeWhYv96WzvZ6eAsd6 ff83GX9kdpcukBkUw3OKw/IjRCYUKZV8= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 25FBA88063 for ; Thu, 6 Oct 2011 09:54:06 -0700 (PDT) Received: by pzk37 with SMTP id 37so7511806pzk.9 for ; Thu, 06 Oct 2011 09:54:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.231 with SMTP id l7mr6906480pbj.41.1317920045819; Thu, 06 Oct 2011 09:54:05 -0700 (PDT) Received: by 10.68.59.169 with HTTP; Thu, 6 Oct 2011 09:54:05 -0700 (PDT) In-Reply-To: References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> Date: Thu, 6 Oct 2011 11:54:05 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 06 Oct 2011 16:50:55 -0000 On Thu, Oct 6, 2011 at 11:27 AM, Sam Hartman wrote: > =C2=A0 =C2=A0Nico> It would be more accurate to say that the GSS-API mech= anism > =C2=A0 =C2=A0Nico> can fail without a context token [...] > > While this is a true statement, it's independent of what I was getting > at. =C2=A0My statement still stands. Some protocols decide to abandon a g= ss > authentication progress for their own reasons. > It's also true that gss mechanisms fail. Agreed. I must have misunderstood you then. Apologies for the noise. Nico -- From lukeh@padl.com Thu Oct 6 14:29:54 2011 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 092E321F8D7C for ; Thu, 6 Oct 2011 14:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMCmrIlgWwVj for ; Thu, 6 Oct 2011 14:29:53 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 484F121F8D7B for ; Thu, 6 Oct 2011 14:29:53 -0700 (PDT) Received: by us.padl.com with ESMTP id p96LWtPN016038; Thu, 6 Oct 2011 17:32:58 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Fri, 7 Oct 2011 08:32:55 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <97619CE9-C30D-4D7B-83A2-19D2EF92DC65@padl.com> References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <5767853B-B8F1-48D3-965D-CB6D1A0203B4@padl.com> <2640F336-BAF5-4BD3-AF71-06F8A9D40AB2@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1244.3) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 06 Oct 2011 21:29:54 -0000 OK, I have another question relating to possibly using RFC 3961 = checksums. Currently the GSS channel binding token from the client is marked = critical, i.e. the acceptor expects it to be there (regardless of = whether it has channel bindings or not). This is because the acceptor's = behaviour is GSS_Unwrap() and compare, to keep its sequence number in = sync with the initiator. If we switch to a MIC, can we just omit the channel binding token in the = case the client has no channel bindings? The exchange that contains the = channel binding token is itself protected by a MIC, so an attacker = cannot remove it. The acceptor would need to raise an error if no = binding token was provided and the caller of GSS_Accept_sec_context() = indicated bindings. -- Luke On 06/10/2011, at 11:33 AM, Nico Williams wrote: > On Wed, Oct 5, 2011 at 7:11 PM, Luke Howard wrote: >> If they are on the wire... >=20 > Oh, heh, sure. Excuse my silliness. -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com From lukeh@padl.com Thu Oct 6 14:38:44 2011 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 0B5261F0C46 for ; Thu, 6 Oct 2011 14:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.07 X-Spam-Level: X-Spam-Status: No, score=-3.07 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMGRukO9rct6 for ; Thu, 6 Oct 2011 14:38:43 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 11E0B1F0C3B for ; Thu, 6 Oct 2011 14:38:43 -0700 (PDT) Received: by us.padl.com with ESMTP id p96LflPI007615; Thu, 6 Oct 2011 17:41:49 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Luke Howard In-Reply-To: <97619CE9-C30D-4D7B-83A2-19D2EF92DC65@padl.com> Date: Fri, 7 Oct 2011 08:41:46 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <3CCFB35E-9732-402A-A089-B6E3AD986B04@padl.com> References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <5767853B-B8F1-48D3-965D-CB6D1A0203B4@padl.com> <2640F336-BAF5-4BD3-AF71-06F8A9D40AB2@padl.com> <97619CE9-C30D-4D7B-83A2-19D2EF92DC65@padl.com> To: abfab@ietf.org X-Mailer: Apple Mail (2.1244.3) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 06 Oct 2011 21:38:44 -0000 > If we switch to a MIC, can we just omit the channel binding token in = the case the client has no channel bindings? The exchange that contains = the channel binding token is itself protected by a MIC, so an attacker = cannot remove it. The acceptor would need to raise an error if no = binding token was provided and the caller of GSS_Accept_sec_context() = indicated bindings. ... although this itself could be configurable with a context option to = allow missing bindings. -- Luke= From lukeh@padl.com Thu Oct 6 15:20:57 2011 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 0B13A1F0C83 for ; Thu, 6 Oct 2011 15:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru+aAKJB1q-O for ; Thu, 6 Oct 2011 15:20:56 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id BCDDB1F0C3B for ; Thu, 6 Oct 2011 15:20:54 -0700 (PDT) Received: by us.padl.com with ESMTP id p96MMvEt027979; Thu, 6 Oct 2011 18:24:02 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Luke Howard In-Reply-To: <04cf01cc8394$10d05930$32710b90$@augustcellars.com> Date: Fri, 7 Oct 2011 09:24:01 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> <04cf01cc8394$10d05930$32710b90$@augustcellars.com> To: abfab@ietf.org X-Mailer: Apple Mail (2.1244.3) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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, 06 Oct 2011 22:20:57 -0000 5.6.1 says the flags subtoken contains a bit "indicating that the = acceptor successfully performed mutual authentication". Is it not the = initiator that is indicating this? -- Luke= From ietf@augustcellars.com Sat Oct 8 18:06:09 2011 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 35E1A21F8B8A for ; Sat, 8 Oct 2011 18:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4ZxuGJ8NnNL for ; Sat, 8 Oct 2011 18:06:08 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id CC57421F8AE9 for ; Sat, 8 Oct 2011 18:06:05 -0700 (PDT) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (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 4E1A12C9F7; Sat, 8 Oct 2011 18:06:05 -0700 (PDT) From: "Jim Schaad" To: "Sam Hartman" Date: Sat, 8 Oct 2011 18:44:48 -0700 Message-ID: <00c001cc8625$07fc29e0$17f47da0$@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: AcyGJO3GtXUPCr1CSKKRJ7cEB5PAHg== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Trying to build the first GSS-API token ---- draft-ietf-abfab-gss-eap-02 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, 09 Oct 2011 01:06:09 -0000 Sam, I am trying to construct the first token to be returned from the call to GSS_Init_sec_context and I am having a couple of problems. 1. I don't know the value of the OID as it is not in the document (minor I can always fudge this value) 2. Next item in the field is a token ID (note that this is capitalized as iD in the current draft which is probably a typo). This should contain either the value of <06 01> according to section 5 of this document. However it would be <00 01> if it was using the tokens defined in RFC 4121. It is not clear to me if you are re-using the same values from section 4.1 in that document or defining new values in which case this needs to be reflected in section 8.1 of this document. 3. Next item in the field is an inner token type - this is a 32-bit number -- oh wait, I just figured this out. It would be clearer if you used the following terms: First subtoken type First subtoken length First subtoken body Second subtoken type. I would be happy if you were consistent on the use of either inner token or subtoken but mixing them got me confused. Jim From lukeh@padl.com Sat Oct 8 18:12:26 2011 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 C245C21F8B6E for ; Sat, 8 Oct 2011 18:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.819 X-Spam-Level: * X-Spam-Status: No, score=1.819 tagged_above=-999 required=5 tests=[MIME_QP_LONG_LINE=1.819] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0Zr6wiOKU5o for ; Sat, 8 Oct 2011 18:12:26 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 251BE21F8B47 for ; Sat, 8 Oct 2011 18:12:26 -0700 (PDT) Received: by us.padl.com with ESMTP id p991Bup2011961; Sat, 8 Oct 2011 21:12:00 -0400 References: <00c001cc8625$07fc29e0$17f47da0$@augustcellars.com> In-Reply-To: <00c001cc8625$07fc29e0$17f47da0$@augustcellars.com> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5F7F6CF7-C9D2-4598-BC1E-B08F9C8A8661@padl.com> X-Mailer: iPhone Mail (8L1) From: Luke Howard Date: Sun, 9 Oct 2011 12:11:51 +1100 To: Jim Schaad X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,BAYES_00,MIME_QP_LONG_LINE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.6 Cc: "abfab@ietf.org" Subject: Re: [abfab] Trying to build the first GSS-API token ---- draft-ietf-abfab-gss-eap-02 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, 09 Oct 2011 01:12:26 -0000 Jim, RFC 4121 tokens are for message protection services only. (at least fast rea= uth notwithstanding) OID awaits assignment, we use one in PADL's arc now. Luke Sent from my iPhone On 09/10/2011, at 12:44, "Jim Schaad" wrote: > Sam, >=20 > I am trying to construct the first token to be returned from the call to > GSS_Init_sec_context and I am having a couple of problems. >=20 > 1. I don't know the value of the OID as it is not in the document (minor I= > can always fudge this value) >=20 > 2. Next item in the field is a token ID (note that this is capitalized as= > iD in the current draft which is probably a typo). This should contain > either the value of <06 01> according to section 5 of this document. > However it would be <00 01> if it was using the tokens defined in RFC 4121= . > It is not clear to me if you are re-using the same values from section 4.1= > in that document or defining new values in which case this needs to be > reflected in section 8.1 of this document. >=20 > 3. Next item in the field is an inner token type - this is a 32-bit number= > -- oh wait, I just figured this out. It would be clearer if you used the= > following terms: > First subtoken type > First subtoken length > First subtoken body > Second subtoken type. >=20 > I would be happy if you were consistent on the use of either inner token o= r > subtoken but mixing them got me confused. >=20 > Jim >=20 >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Sun Oct 9 08:06:11 2011 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 A44BF21F8B13 for ; Sun, 9 Oct 2011 08:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeoYvXkEKlhC for ; Sun, 9 Oct 2011 08:06:11 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4149D21F8B10 for ; Sun, 9 Oct 2011 08:06:10 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E807420313; Sun, 9 Oct 2011 11:07:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E809A4235; Sun, 9 Oct 2011 11:05:58 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <00c001cc8625$07fc29e0$17f47da0$@augustcellars.com> Date: Sun, 09 Oct 2011 11:05:58 -0400 In-Reply-To: <00c001cc8625$07fc29e0$17f47da0$@augustcellars.com> (Jim Schaad's message of "Sat, 8 Oct 2011 18:44:48 -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] Trying to build the first GSS-API token ---- draft-ietf-abfab-gss-eap-02 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, 09 Oct 2011 15:06:11 -0000 I will attempt to standardize on subtoken. I definitely agree we need more clarity around the RFC 4121 token type registry. We use a different token type for our context tokens from Kerberos because they have nothing in common. From ietf@augustcellars.com Sun Oct 9 14:18:25 2011 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 660B421F8AED for ; Sun, 9 Oct 2011 14:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzGo0QzRyhYr for ; Sun, 9 Oct 2011 14:18:25 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id F005221F8A67 for ; Sun, 9 Oct 2011 14:18:24 -0700 (PDT) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (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 B66322CA27; Sun, 9 Oct 2011 14:18:24 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <00c001cc8625$07fc29e0$17f47da0$@augustcellars.com> In-Reply-To: Date: Sun, 9 Oct 2011 14:57:09 -0700 Message-ID: <00f901cc86ce$64c440f0$2e4cc2d0$@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: AQIO4+8tdLp90vuirAO0ZjhgBQ/tjQIPgOvYlN9YKCA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Trying to build the first GSS-API token ---- draft-ietf-abfab-gss-eap-02 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, 09 Oct 2011 21:18:25 -0000 I am confused in a way. I would have thought that all of the token types are defined on a per mechanism method, thus re-using the same value would have no theoretical problems. I recognize that they could present an issue if you use a single code base for implementing multiple mechanisms and use a single switch statement to deal with the token types. I guess my question would be why would we want to look at the 4121 token type registry for anything given that it should be mechanism specific? Jim > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Sunday, October 09, 2011 8:06 AM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: Trying to build the first GSS-API token ---- draft-ietf-abfab-gss- > eap-02 > > I will attempt to standardize on subtoken. > I definitely agree we need more clarity around the RFC 4121 token type > registry. > We use a different token type for our context tokens from Kerberos because > they have nothing in common. From hartmans@painless-security.com Sun Oct 9 15:02:03 2011 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 31ECC21F8B46 for ; Sun, 9 Oct 2011 15:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZvsgaNh-WQ4 for ; Sun, 9 Oct 2011 15:02:02 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id BFDCC21F8B45 for ; Sun, 9 Oct 2011 15:02:02 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (m975736d0.tmodns.net [208.54.87.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 06BEE20383; Sun, 9 Oct 2011 18:03:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5CF814235; Sun, 9 Oct 2011 18:01:56 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <00c001cc8625$07fc29e0$17f47da0$@augustcellars.com> <00f901cc86ce$64c440f0$2e4cc2d0$@augustcellars.com> Date: Sun, 09 Oct 2011 18:01:56 -0400 In-Reply-To: <00f901cc86ce$64c440f0$2e4cc2d0$@augustcellars.com> (Jim Schaad's message of "Sun, 9 Oct 2011 14:57:09 -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] Trying to build the first GSS-API token ---- draft-ietf-abfab-gss-eap-02 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, 09 Oct 2011 22:02:03 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> I guess my question would be why would we want to look at the Jim> 4121 token type registry for anything given that it should be Jim> mechanism specific? Well, the context level tokens are probably per-mechanism at least for the most part. However, per-message tokens are going to be common across all the 4121-like mechanisms (EAP, Kerberos, SCRAM, SAML ECP). If there is some option added--say a DH exchange for PFS--there's a fair chance it will apply to multiple mechanisms. If it does, it would be nice to reuse code points. If we're doing things like Kerberos fastreauth for EAP, then it becomes even more possible to have overlaps. So, my rationale is that there's no harm in using different token IDs for the different context tokens and there's at least some chance of potential value in doing so. If you would rather do something else to avoid confusion, etc, we can do that. From klaas@cisco.com Fri Oct 14 02:10:28 2011 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 0DCB221F8B1C for ; Fri, 14 Oct 2011 02:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kD+rIFX+i8s8 for ; Fri, 14 Oct 2011 02:10:27 -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 73E1C21F8B16 for ; Fri, 14 Oct 2011 02:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=219; q=dns/txt; s=iport; t=1318583427; x=1319793027; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=d74PsHLxvLNTcKDRT1UW/uih+XBtPQ7Tj/uTM7kjs6w=; b=P2cFVfyMW/gRPyYxJidHrq1vY/snWzNVATnT7sblTQKgKu/AcTMI9nPb IrBMfBhGS/g2ZEQpBeDQlYqxMRuK/kPs70fDxIq2aVY21YKtsM9RLyzMA zjI/Mj0/xNR9ap/8ZcB7zsDSS88BUgBEj3NNxLzr+pbXq104R45TawNsv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwHAGn7l06tJV2Z/2dsb2JhbABDmXiOYoEFgVQBAQQSASdPOBlXO6BiAZ4zhFGCO2EEk3eRVw X-IronPort-AV: E=Sophos;i="4.69,345,1315180800"; d="scan'208";a="28412385" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 14 Oct 2011 09:10:27 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9E9AQfT009918 for ; Fri, 14 Oct 2011 09:10:26 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Oct 2011 11:10:25 +0200 References: <20111013184801.31875.14610.idtracker@ietfa.amsl.com> To: abfab@ietf.org Message-Id: <276B5048-B4E1-4329-87C7-942FD7C884CE@cisco.com> Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [abfab] heads up: abfab at IETF 82 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, 14 Oct 2011 09:10:28 -0000 Hi all, As a heads-up, abfab is in the draft agenda scheduled for Friday = 11.20-12-20 (we had requested 1,5 hours, so this may still change), but = please take this into account for your travel plans. Klaas From leifj@mnt.se Mon Oct 17 17:47:13 2011 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 69A1B11E80AE for ; Mon, 17 Oct 2011 17:47: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOjyZmvXI-zc for ; Mon, 17 Oct 2011 17:47:12 -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 9084111E8095 for ; Mon, 17 Oct 2011 17:47:12 -0700 (PDT) Received: from [10.66.224.31] (h-64-236-139-254.aoltw.net [64.236.139.254]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9I0l6mg012445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Oct 2011 02:47:11 +0200 (CEST) Message-ID: <4E9CCC8A.2010203@mnt.se> Date: Tue, 18 Oct 2011 02:47:06 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: abfab@ietf.org References: <20111013184801.31875.14610.idtracker@ietfa.amsl.com> <276B5048-B4E1-4329-87C7-942FD7C884CE@cisco.com> In-Reply-To: <276B5048-B4E1-4329-87C7-942FD7C884CE@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] heads up: abfab at IETF 82 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, 18 Oct 2011 00:47:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/14/2011 11:10 AM, Klaas Wierenga wrote: > > Hi all, > > As a heads-up, abfab is in the draft agenda scheduled for Friday 11.20-12-20 (we had requested 1,5 hours, so this may still change), but please take this into account for your travel plans. Turns out we have 1+1 hour. Me and Klaas are about to craft an agenda. We're hoping to focus on issues that will allow us to move forward on our core specifications. Please send your agenda topics! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6czIoACgkQ8Jx8FtbMZndxBQCeJX46yYsT0aV3R2GY5IpiA+yN YjYAn1KEnEIoLJc9hLT3nj1RcI6H1C9j =2MaG -----END PGP SIGNATURE----- From hartmans@painless-security.com Tue Oct 18 06:56:34 2011 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 63C4521F8AEA; Tue, 18 Oct 2011 06:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.71 X-Spam-Level: X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp23lGRj80tM; Tue, 18 Oct 2011 06:56:34 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id EC4C321F8AE1; Tue, 18 Oct 2011 06:56:33 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6BE7420393; Tue, 18 Oct 2011 09:57:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 158AA4235; Tue, 18 Oct 2011 09:56:22 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Tue, 18 Oct 2011 09:56:22 -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: emu@ietf.org Subject: [abfab] GSS-EAP: do we ned an identity request 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, 18 Oct 2011 13:56:34 -0000 [EMU copied for EAP input] Here in ABFAB, we're designing a new EAP lower layer for applications to use for authentication. We're using the GSS-API (RFC 2743) as our application integration point. Currently, our lower layer is kind of chatty. The peer sends a first message that roughly says "Hi, I'd like to authenticate." Then the authenticator sends an identity request EAP message. Then the peer sends an identity response. Then the authenticator (probably after an AAA interaction) respons with the first EAP method message. As best we can tell that round trip is unneeded. We could instead include an unsolicited identity response in our first message from the peer to authenticator and get a request with an EAP method message from the first message from the authenticator. We can't see any down side of this. There seems to be nothing in the identity request. We already have another approach for "network selection." If you want to know who your authenticator is in order to decide on an identity, we have a lower-layer specific mechanism for that. I'd appreciate any comments. From ABFAB participants, do we want to make this optimization? From EMU participants are we missing anything? From hartmans@painless-security.com Tue Oct 18 07:50:15 2011 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 9197F21F8B29 for ; Tue, 18 Oct 2011 07:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.058 X-Spam-Level: X-Spam-Status: No, score=-1.058 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 385oUGcOpyPb for ; Tue, 18 Oct 2011 07:50:15 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D3FFB21F8B25 for ; Tue, 18 Oct 2011 07:50:14 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 190C020239; Tue, 18 Oct 2011 10:51:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A90944235; Tue, 18 Oct 2011 10:50:03 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <00c001cc8625$07fc29e0$17f47da0$@augustcellars.com> Date: Tue, 18 Oct 2011 10:50:03 -0400 In-Reply-To: <00c001cc8625$07fc29e0$17f47da0$@augustcellars.com> (Jim Schaad's message of "Sat, 8 Oct 2011 18:44:48 -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] Trying to build the first GSS-API token ---- draft-ietf-abfab-gss-eap-02 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, 18 Oct 2011 14:50:15 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> 3. Next item in the field is an inner token type - this is a Jim> 32-bit number -- oh wait, I just figured this out. It would be Jim> clearer if you used the following terms: First subtoken type Jim> First subtoken length First subtoken body Second subtoken type. Jim> I would be happy if you were consistent on the use of either Jim> inner token or subtoken but mixing them got me confused. OK, I'm trying to be consistent with the following. An inner token is a non-ASN.1 structure carried in the any in the GSSAPI-Token production defined in RFC 2743. I.E. the context token without the application tag and OID wrapper. GSS-EAP inner tokens contain a token ID and a series of subtokens. Subtokens have types, lengths and values. I believe I've made changes to the document to be consistent with this terminology. From rafa@um.es Tue Oct 18 07:51:39 2011 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 BE1B021F8B23; Tue, 18 Oct 2011 07:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XySwN75cGN4U; Tue, 18 Oct 2011 07:51:38 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 25B2421F8B35; Tue, 18 Oct 2011 07:51:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 979985D6BC; Tue, 18 Oct 2011 16:51:36 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nlEmI5UDe3eA; Tue, 18 Oct 2011 16:51:36 +0200 (CEST) Received: from inf-205-117.inf.um.es (inf-205-117.inf.um.es [155.54.205.117]) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPA id 8BC925D6A8; Tue, 18 Oct 2011 16:51:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Tue, 18 Oct 2011 16:51:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org, emu@ietf.org Subject: Re: [abfab] GSS-EAP: do we ned an identity request 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, 18 Oct 2011 14:51:39 -0000 Hi Sam: El 18/10/2011, a las 15:56, Sam Hartman escribi=F3: > [EMU copied for EAP input] >=20 > Here in ABFAB, we're designing a new EAP lower layer for applications = to > use for authentication. We're using the GSS-API (RFC 2743) as our > application integration point. >=20 > Currently, our lower layer is kind of chatty. The peer sends a first > message that roughly says "Hi, I'd like to authenticate." Then the > authenticator sends an identity request EAP message. Then the peer = sends > an identity response. Then the authenticator (probably after an AAA > interaction) respons with the first EAP method message. >=20 > As best we can tell that round trip is unneeded. We could instead > include an unsolicited identity response in our first message from the > peer to authenticator and get a request with an EAP method message = from > the first message from the authenticator. According to RFC 3579 (section 2.1) that would be possible in certain = cases: "This is useful in cases where the identity is determined by another means (such as Called-Station-Id, Calling-Station-Id and/or Originating-Line-Info); where a single authentication method is required, which includes its own identity exchange; where identity hiding is desired, so that the identity is not requested until after a protected channel has been set up." Alternatively, what I believe you can also do is to allow the peer send = information (probably peer's identity) to the authenticator out of EAP = (within GSS token). This information allows AAA client to reach the = EAP/AAA server that handles the peer's credentials. Then the EAP/AAA = server can start directly the preferred EAP method for that peer. What I am trying to say corresponds with something similar to the first = figure of section 2.2 in RFC 4072. In RFC 3579 you can also find this text: "Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server." Between both choices, it seems that second one gives the EAP/AAA server = the opportunity to start directly with the selected EAP method from a = pool of them. First choice, always starts with a particular EAP method = (implemented in the Acceptor) that it may not be supported by the (home) = EAP/AAA server or not the preferred one by the server for that peer. Hope this helps. >=20 > We can't see any down side of this. There seems to be nothing in the > identity request. We already have another approach for "network > selection." If you want to know who your authenticator is in order to > decide on an identity, we have a lower-layer specific mechanism for > that. >=20 > I'd appreciate any comments. =46rom ABFAB participants, do we want to = make > this optimization? =46rom EMU participants are we missing anything? > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nico@cryptonector.com Tue Oct 18 08:11:06 2011 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 53FE821F84BD for ; Tue, 18 Oct 2011 08:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGl2qvD4DwVg for ; Tue, 18 Oct 2011 08:11:06 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id AA69221F84AE for ; Tue, 18 Oct 2011 08:11:05 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id B0F3142807D for ; Tue, 18 Oct 2011 08:11:00 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 4D7EC428079 for ; Tue, 18 Oct 2011 08:10:58 -0700 (PDT) Received: by vws5 with SMTP id 5so543139vws.31 for ; Tue, 18 Oct 2011 08:10:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.37.44 with SMTP id v12mr2894486vdj.53.1318950652798; Tue, 18 Oct 2011 08:10:52 -0700 (PDT) Received: by 10.220.76.76 with HTTP; Tue, 18 Oct 2011 08:10:52 -0700 (PDT) In-Reply-To: References: <00c001cc8625$07fc29e0$17f47da0$@augustcellars.com> Date: Tue, 18 Oct 2011 10:10:52 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] Trying to build the first GSS-API token ---- draft-ietf-abfab-gss-eap-02 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, 18 Oct 2011 15:11:06 -0000 On Tue, Oct 18, 2011 at 9:50 AM, Sam Hartman wrote: >>>>>> "Jim" =3D=3D Jim Schaad writes: > =C2=A0 =C2=A0Jim> 3. Next item in the field is an inner token type - this= is a > =C2=A0 =C2=A0Jim> 32-bit number -- oh wait, I just figured this out. =C2= =A0It would be > =C2=A0 =C2=A0Jim> clearer if you used the following terms: First subtoken= type > =C2=A0 =C2=A0Jim> First subtoken length First subtoken body Second subtok= en type. > > =C2=A0 =C2=A0Jim> I would be happy if you were consistent on the use of e= ither > =C2=A0 =C2=A0Jim> inner token or subtoken but mixing them got me confused= . > > OK, I'm trying to be consistent with the following. =C2=A0An inner token = is a > non-ASN.1 structure carried in the any in the GSSAPI-Token production > defined in RFC 2743. I.E. the context token without the application tag > and OID wrapper. Well, it could be ASN.1, but the point is it's not defined by RFC2743 -- it's defined by the mechanism. > GSS-EAP inner tokens contain a token ID and a series of subtokens. > Subtokens have types, lengths and values. =C2=A0I believe I've made chang= es > to the document to be consistent with this terminology. Given that the context token exchange is synchronous, there's no need for any token IDs as such. Or so I would think (sub-token IDs, sure, if there's any sub-tokens that require identification). Nico -- From hartmans@painless-security.com Tue Oct 18 08:31:36 2011 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 D110321F85F2 for ; Tue, 18 Oct 2011 08:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1hollYIJ1+K for ; Tue, 18 Oct 2011 08:31:36 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 68F7221F85F1 for ; Tue, 18 Oct 2011 08:31:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 52E1E202C9; Tue, 18 Oct 2011 11:32:44 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DC21C4235; Tue, 18 Oct 2011 11:31:18 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <00c001cc8625$07fc29e0$17f47da0$@augustcellars.com> Date: Tue, 18 Oct 2011 11:31:18 -0400 In-Reply-To: (Nico Williams's message of "Tue, 18 Oct 2011 10:10:52 -0500") 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] Trying to build the first GSS-API token ---- draft-ietf-abfab-gss-eap-02 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, 18 Oct 2011 15:31:36 -0000 >>>>> "Nico" == Nico Williams writes: Nico> Given that the context token exchange is synchronous, there's Nico> no need for any token IDs as such. Or so I would think Nico> (sub-token IDs, sure, if there's any sub-tokens that require Nico> identification). Nico> Nico -- Sure, although RFC 1964 and RFC 4121 had them. And we're talking about two bytes. From hartmans@painless-security.com Tue Oct 18 08:35:53 2011 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 798CC21F869E; Tue, 18 Oct 2011 08:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIE2UY4ywP0R; Tue, 18 Oct 2011 08:35:53 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0F85E21F8672; Tue, 18 Oct 2011 08:35:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5BA5E202C9; Tue, 18 Oct 2011 11:37:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F13704235; Tue, 18 Oct 2011 11:35:41 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> Date: Tue, 18 Oct 2011 11:35:41 -0400 In-Reply-To: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> (Rafa Marin Lopez's message of "Tue, 18 Oct 2011 16:51:31 +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, Sam Hartman , emu@ietf.org Subject: Re: [abfab] GSS-EAP: do we ned an identity request 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, 18 Oct 2011 15:35:53 -0000 I think I may have been unclear in what I was proposing. I'm proposing that the peer send its identity in the first message (*) and that the server gets to respond with type 4 or greater (a specific EAP method). I'm proposing dropping the identity request, not the identity response. (*) There's a case where we ask the acceptor what its name is. In that case I think it is desirable to let the peer wait to receive the acceptor name before sending an identity. In all these cases we support identity hiding. From nico@cryptonector.com Tue Oct 18 09:11:25 2011 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 2F7E221F8B39 for ; Tue, 18 Oct 2011 09:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL+T40rK4ar3 for ; Tue, 18 Oct 2011 09:11:24 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id A113C21F8B34 for ; Tue, 18 Oct 2011 09:11:24 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 65D8D264071 for ; Tue, 18 Oct 2011 09:11:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=V+zk5N77E+Pbzzo2FTl9oiXkuqEH3f7nFu+g/mET9+fR tWn0J4ADGc7FBKHqO6yOFuPnVZt4qmqN9KXjiHb4DYdRz3Ohje95jqT5Tu1s+vsh KxkygJjPzeNixx+d3LpmxjJf426ErDv+m8XhMGpmiWBo4fm1/PSJesl4bph3UiY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=LikbMH+7MkvWV4JoZ1bZv4cmFGk=; b=dy9wk6lK+aM 5eltotYTc3xOC9yH7LTp1Fvzy4d+dnhjm62ST1AwFovLNmzoAlEOl841JKGOwC8n 5xsMB6wxtTdMAz89gHXkcAG9lkbgrcEd1dSMizSmneQhGoQSP/sXH2wceFXrmVoS gvFDhsmPccIfRqs1OyPFgtgF2PPyG7DY= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 34C27264070 for ; Tue, 18 Oct 2011 09:11:24 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so800643vcb.31 for ; Tue, 18 Oct 2011 09:11:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.87.14 with SMTP id u14mr237297vcl.39.1318954283464; Tue, 18 Oct 2011 09:11:23 -0700 (PDT) Received: by 10.220.76.76 with HTTP; Tue, 18 Oct 2011 09:11:23 -0700 (PDT) In-Reply-To: References: <00c001cc8625$07fc29e0$17f47da0$@augustcellars.com> Date: Tue, 18 Oct 2011 11:11:23 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] Trying to build the first GSS-API token ---- draft-ietf-abfab-gss-eap-02 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, 18 Oct 2011 16:11:25 -0000 On Tue, Oct 18, 2011 at 10:31 AM, Sam Hartman wrote: > =C2=A0 =C2=A0Nico> Given that the context token exchange is synchronous, = there's > =C2=A0 =C2=A0Nico> no need for any token IDs as such. =C2=A0Or so I would= think > =C2=A0 =C2=A0Nico> (sub-token IDs, sure, if there's any sub-tokens that r= equire > =C2=A0 =C2=A0Nico> identification). > > Sure, although RFC 1964 and RFC 4121 had them. =C2=A0And we're talking ab= out > two bytes. IMO it was a mistake in RFC1964. We shouldn't repeat mistakes. As far as mistakes go, it's not a big deal, so I don't really care. From rafa@um.es Tue Oct 18 09:20:30 2011 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 02C9F21F8BB7; Tue, 18 Oct 2011 09:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT81e0wbPm4M; Tue, 18 Oct 2011 09:20:28 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9C121F8BBB; Tue, 18 Oct 2011 09:20:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 5E7704BCD4; Tue, 18 Oct 2011 18:20:24 +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 Cemlru2SxhN8; Tue, 18 Oct 2011 18:20:24 +0200 (CEST) Received: from inf-205-117.inf.um.es (inf-205-117.inf.um.es [155.54.205.117]) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPA id 2C2654B942; Tue, 18 Oct 2011 18:20:17 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Tue, 18 Oct 2011 18:20:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [abfab] GSS-EAP: do we ned an identity request 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, 18 Oct 2011 16:20:30 -0000 Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribi=F3: > I think I may have been unclear in what I was proposing. I'm = proposing > that the peer send its identity in the first message (*) and that the > server gets to respond with type 4 or greater (a specific EAP method). Sending its identity does not mean that it must be carried in the EAP = response/identity. In fact what I suggested is to carry the identity in = the first message but not contained in the EAP response/identity. > I'm proposing dropping the identity request, not the identity = response. As I said in my previous e-mail, you can do that but it does not = necessarily mean to transport the identity in an EAP response/identity. According to the text I pasted in my previous e-mail (below), the peer = can send its identity in the first message (but not contained in any EAP = response/identity). Then the NAS sends that identity to the EAP/AAA = server with an EAP-Message attribute (without EAP message) signifying = EAP-Start. The RADIUS server then sends "an EAP-Request for an = authentication method (Type 4 or greater) This is what I proposed in my previous e-mail. Is it not similar to what = you proposed? In RFC 3579 you can also find this text: "Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server." >=20 >=20 > (*) There's a case where we ask the acceptor what its name is. In that > case I think it is desirable to let the peer wait to receive the > acceptor name before sending an identity. >=20 > In all these cases we support identity hiding. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From hartmans@painless-security.com Tue Oct 18 09:29:54 2011 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 262D421F8C20 for ; Tue, 18 Oct 2011 09:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh3c59vz8bjC for ; Tue, 18 Oct 2011 09:29:53 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2060921F89B8 for ; Tue, 18 Oct 2011 09:29:51 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 34B0720383 for ; Tue, 18 Oct 2011 12:31:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B1A944235; Tue, 18 Oct 2011 12:29:39 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Tue, 18 Oct 2011 12:29:39 -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] I'd like two OIDs 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, 18 Oct 2011 16:29:54 -0000 I've already asked Rhys for one of these. I'd like to create a mechanisms arc in our registry and to get an OID for the GSS-EAP V1 mechanism family. I'd also like to ask for an arc for GSS-API name tyues and to get a OID for GSS_EAP_NT_EAP_NAME as discussed in the draft-ietf-abfab-gss-eap document. Please send the OIDs off list so we can be clear about what mechanism behavior the mechanism OID corresponds to. We have two non-backward-compatible protocol changes on the table: using RFC 3961 tokens directly and removing the EAP identity request. --Sam From hartmans@painless-security.com Tue Oct 18 09:42:23 2011 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 E914521F8BBB for ; Tue, 18 Oct 2011 09:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wasDbjEDSmoC for ; Tue, 18 Oct 2011 09:42:23 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 82B3921F8BA2 for ; Tue, 18 Oct 2011 09:42:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8E75120383 for ; Tue, 18 Oct 2011 12:43:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1ACFF4235; Tue, 18 Oct 2011 12:42:08 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Tue, 18 Oct 2011 12:42:08 -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] Trying to publish with a VSA 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, 18 Oct 2011 16:42:24 -0000 Hi. We need a couple of RADIUS attributes. Realistically I don't think we can get our attributes from the standard IETF namespace: it's basically running out of attributes. There's work in radext (draft-ietf-radext-radius-extensions) to extend the namespace. we could create a normative dependency on that work. I have two concerns: 1) It's moving kind of slowly. 2) It requires significant changes to client and server RADIUS libraries. For example the libraries I'm familiar with identify attributes either by a 32-bit identifier (16 bits of vendor and 16-bits of attribute) or as a vendor plus an attribute. It's not entirely obvious what interface changes will need to be made to support these new attributes, but it's quite clear something is required and it's not done yet. For those of us implementing today it's be really convenient to use RADIUS attributes from a VSA space. Personally I don't see the problem with this so long as the organization in question is willing to give up change control of at least those attributes to the IETF. It's possible we could get push back from the IESG. I'd like to ask the WG though about whether we are willing to try and use VSA space in a standard assuming we can get change control of the attributes in question. I think it will significantly help our time-to-market and will not have any cost other than cleanliness of standard. From leifj@sunet.se Tue Oct 18 09:53:49 2011 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 83E7C21F8B18 for ; Tue, 18 Oct 2011 09:53:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2y+Y2NdCTq3 for ; Tue, 18 Oct 2011 09:53:48 -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 9730D21F8AD2 for ; Tue, 18 Oct 2011 09:53:48 -0700 (PDT) Received: from [10.2.3.28] ([64.9.249.121]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9IGrdki008403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Oct 2011 18:53:46 +0200 (CEST) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <4F299327-31C5-4839-BC7A-34E95F3949E4@sunet.se> X-Mailer: iPad Mail (8L1) From: Leif Johansson Date: Tue, 18 Oct 2011 09:53:51 -0700 To: Sam Hartman Cc: "abfab@ietf.org" Subject: Re: [abfab] Trying to publish with a VSA 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, 18 Oct 2011 16:53:49 -0000 Can we setup a vsa allocation tied to an iana registry? Skickat fr=C3=A5n min iPad 18 okt 2011 kl. 09:42 skrev Sam Hartman : >=20 >=20 > Hi. >=20 > We need a couple of RADIUS attributes. Realistically I don't think we > can get our attributes from the standard IETF namespace: it's basically > running out of attributes. There's work in radext > (draft-ietf-radext-radius-extensions) to extend the namespace. >=20 > we could create a normative dependency on that work. I have two > concerns: >=20 > 1) It's moving kind of slowly. >=20 > 2) It requires significant changes to client and server RADIUS > libraries. For example the libraries I'm familiar with identify > attributes either by a 32-bit identifier (16 bits of vendor and 16-bits > of attribute) or as a vendor plus an attribute. It's not entirely > obvious what interface changes will need to be made to support these new > attributes, but it's quite clear something is required and it's not done > yet. >=20 > For those of us implementing today it's be really convenient to use > RADIUS attributes from a VSA space. Personally I don't see the problem > with this so long as the organization in question is willing to give up > change control of at least those attributes to the IETF. It's possible > we could get push back from the IESG. >=20 > I'd like to ask the WG though about whether we are willing to try and > use VSA space in a standard assuming we can get change control of the > attributes in question. I think it will significantly help our > time-to-market and will not have any cost other than cleanliness of > standard. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Tue Oct 18 09:55:35 2011 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 DCAEA21F8AD2; Tue, 18 Oct 2011 09:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obXNfYoSC1gh; Tue, 18 Oct 2011 09:55:35 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7A00321F8ACE; Tue, 18 Oct 2011 09:55:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8CB8820383; Tue, 18 Oct 2011 12:56:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 05EA04235; Tue, 18 Oct 2011 12:55:24 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> Date: Tue, 18 Oct 2011 12:55:23 -0400 In-Reply-To: (Rafa Marin Lopez's message of "Tue, 18 Oct 2011 18:20: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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [abfab] GSS-EAP: do we ned an identity request 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, 18 Oct 2011 16:55:36 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: >> I think I may have been unclear in what I was proposing. I'm >> proposing that the peer send its identity in the first message >> (*) and that the server gets to respond with type 4 or greater (a >> specific EAP method). Rafa> Sending its identity does not mean that it must be carried in Rafa> the EAP response/identity. In fact what I suggested is to Rafa> carry the identity in the first message but not contained in Rafa> the EAP response/identity. OK. Why not carry it in the EAP response/identity? It seems easier than developing new encoding. However it's certainly easy enough to carry it elsewhere. So, if there is a reason to do so I'm happy to invent our own subtoken for it. do you support the general concept of an optimization here? From hartmans@painless-security.com Tue Oct 18 11:04:23 2011 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 91AB421F8BBB for ; Tue, 18 Oct 2011 11:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF-mId5ONMR3 for ; Tue, 18 Oct 2011 11:04:23 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0C63821F8B92 for ; Tue, 18 Oct 2011 11:04:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DC44F20383; Tue, 18 Oct 2011 14:05:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3C5A54235; Tue, 18 Oct 2011 14:04:07 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <4F299327-31C5-4839-BC7A-34E95F3949E4@sunet.se> Date: Tue, 18 Oct 2011 14:04:07 -0400 In-Reply-To: <4F299327-31C5-4839-BC7A-34E95F3949E4@sunet.se> (Leif Johansson's message of "Tue, 18 Oct 2011 09:53:51 -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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Trying to publish with a VSA 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, 18 Oct 2011 18:04:23 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> Can we setup a vsa allocation tied to an iana registry? Leif> Skickat frÃ¥n min iPad We could. I don't really see the value in this though given that there is not significant value in having future allocations comes from the same vendor registry. we could ask IANA to maintain a convenience registry to indicate all the standardized GSS-EAP AAA attributes regardless of their origin. From leifj@sunet.se Tue Oct 18 11:08:15 2011 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 303CA21F8C00 for ; Tue, 18 Oct 2011 11:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoePJ0dn1603 for ; Tue, 18 Oct 2011 11:08:14 -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 E205821F8BFB for ; Tue, 18 Oct 2011 11:08:13 -0700 (PDT) Received: from [10.2.3.28] ([64.9.249.121]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9II87q9018548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Oct 2011 20:08:12 +0200 (CEST) References: <4F299327-31C5-4839-BC7A-34E95F3949E4@sunet.se> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (8L1) From: Leif Johansson Date: Tue, 18 Oct 2011 11:08:19 -0700 To: Sam Hartman Cc: "abfab@ietf.org" Subject: Re: [abfab] Trying to publish with a VSA 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, 18 Oct 2011 18:08:15 -0000 The value is that it wouldn't be tied to a company but to the iesg or some s= uch neutral entity. Skickat fr=C3=A5n min iPad 18 okt 2011 kl. 11:04 skrev Sam Hartman : >>>>>> "Leif" =3D=3D Leif Johansson writes: >=20 > Leif> Can we setup a vsa allocation tied to an iana registry? > Leif> Skickat fr=C3=83=C2=A5n min iPad >=20 > We could. I don't really see the value in this though given that there > is not significant value in having future allocations comes from the > same vendor registry. >=20 > we could ask IANA to maintain a convenience registry to indicate all the > standardized GSS-EAP AAA attributes regardless of their origin. From hartmans@painless-security.com Tue Oct 18 11:18:21 2011 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 5E1D221F8AC3 for ; Tue, 18 Oct 2011 11:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muGDgUhgZ0ra for ; Tue, 18 Oct 2011 11:18:21 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id ED7AA21F858C for ; Tue, 18 Oct 2011 11:18:20 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F418C20383; Tue, 18 Oct 2011 14:19:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 691494235; Tue, 18 Oct 2011 14:18:09 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <4F299327-31C5-4839-BC7A-34E95F3949E4@sunet.se> Date: Tue, 18 Oct 2011 14:18:09 -0400 In-Reply-To: (Leif Johansson's message of "Tue, 18 Oct 2011 11:08:19 -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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Trying to publish with a VSA 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, 18 Oct 2011 18:18:21 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> The value is that it wouldn't be tied to a company but to the Leif> iesg or some such neutral entity. Skickat frÃ¥n min Leif> iPad Right. I guess I don't understand what the value of that is. In my mind numbers are just numbers; the important thing is to agree on one. I see there's value in being able to allocate new numbers, in being able to define the semantics of something, to control future changes to how some field is used. I don't see the value in having a particular number drawn from someone's namespace though. From hartmans@painless-security.com Tue Oct 18 11:30:13 2011 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 3C59F21F8C33 for ; Tue, 18 Oct 2011 11:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETKxYeOG01Ti for ; Tue, 18 Oct 2011 11:30:12 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id B4B4921F8C34 for ; Tue, 18 Oct 2011 11:30:12 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id BCA64202C9; Tue, 18 Oct 2011 14:31:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3BBA44235; Tue, 18 Oct 2011 14:30:01 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> <04cf01cc8394$10d05930$32710b90$@augustcellars.com> Date: Tue, 18 Oct 2011 14:30:01 -0400 In-Reply-To: (Luke Howard's message of "Fri, 7 Oct 2011 09:24:01 +1100") 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] Review of draft-ietf-abfab-gss-eap-02 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, 18 Oct 2011 18:30:13 -0000 >>>>> "Luke" == Luke Howard writes: Luke> 5.6.1 says the flags subtoken contains a bit "indicating that Luke> the acceptor successfully performed mutual authentication". Is Luke> it not the initiator that is indicating this? -- Luke fixed, thanks. From hartmans@painless-security.com Tue Oct 18 11:31:43 2011 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 7A1FE21F8B30 for ; Tue, 18 Oct 2011 11:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oBnFFsm3UwJ for ; Tue, 18 Oct 2011 11:31:43 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1587D21F8B2F for ; Tue, 18 Oct 2011 11:31:43 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2D5ED202C9; Tue, 18 Oct 2011 14:32:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A23234235; Tue, 18 Oct 2011 14:31:31 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <5767853B-B8F1-48D3-965D-CB6D1A0203B4@padl.com> <2640F336-BAF5-4BD3-AF71-06F8A9D40AB2@padl.com> <97619CE9-C30D-4D7B-83A2-19D2EF92DC65@padl.com> <3CCFB35E-9732-402A-A089-B6E3AD986B04@padl.com> Date: Tue, 18 Oct 2011 14:31:31 -0400 In-Reply-To: <3CCFB35E-9732-402A-A089-B6E3AD986B04@padl.com> (Luke Howard's message of "Fri, 7 Oct 2011 08:41:46 +1100") 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] Review of draft-ietf-abfab-gss-eap-02 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, 18 Oct 2011 18:31:43 -0000 >>>>> "Luke" == Luke Howard writes: >> If we switch to a MIC, can we just omit the channel binding token >> in the case the client has no channel bindings? The exchange that >> contains the channel binding token is itself protected by a MIC, >> so an attacker cannot remove it. The acceptor would need to raise >> an error if no binding token was provided and the caller of >> GSS_Accept_sec_context() indicated bindings. Luke> ... although this itself could be configurable with a context Luke> option to allow missing bindings. If you want to work with HTTP, you want to ignore channel bindings if the acceptor passes in null. From hartmans@painless-security.com Tue Oct 18 11:34:32 2011 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 41A6A21F8C92 for ; Tue, 18 Oct 2011 11:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wD2btb1xutpB for ; Tue, 18 Oct 2011 11:34:31 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id B168721F8C81 for ; Tue, 18 Oct 2011 11:34:31 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id BBC7420383; Tue, 18 Oct 2011 14:35:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3FE054235; Tue, 18 Oct 2011 14:34:18 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> <04cf01cc8394$10d05930$32710b90$@augustcellars.com> <365530F6-E7A5-41E9-B72D-C9955BC24C0C@padl.com> Date: Tue, 18 Oct 2011 14:34:18 -0400 In-Reply-To: <365530F6-E7A5-41E9-B72D-C9955BC24C0C@padl.com> (Luke Howard's message of "Fri, 7 Oct 2011 01:21:29 +1100") 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: [abfab] Derivation salt for gss-eap 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, 18 Oct 2011 18:34:32 -0000 >>>>> "Luke" == Luke Howard writes: Luke> If we are going to make this change, maybe we should change Luke> the derivation salt for the CRK to "rfc3961-gss-eap". Or is Luke> this too pedantic. -- Luke I'd actually prefer to keep the derivation salt as RFC 4121 because I believe it's more correct. In terms of per-message processing which is most of what the CRK is used for, it is RFC 4121. From hartmans@painless-security.com Tue Oct 18 11:41:11 2011 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 55CB921F8B32 for ; Tue, 18 Oct 2011 11:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJLoSXof5aaW for ; Tue, 18 Oct 2011 11:41:10 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id B3D0321F8B31 for ; Tue, 18 Oct 2011 11:41:10 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C9ACA202C9 for ; Tue, 18 Oct 2011 14:42:24 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 407124235; Tue, 18 Oct 2011 14:40:59 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Tue, 18 Oct 2011 14:40:59 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [abfab] Using RFC 3961 checksums for MIC/CB 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, 18 Oct 2011 18:41:11 -0000 --=-=-= Below, Luke made a proposal for updating to using RFC 3961 checksums rather than RFC 4121 tokens. The main effect is that channel bindings data is smaller and that we avoid some potential sequencing issues if we ever want to permit people to send messages before a context is fully established. I'd like to know if we have sufficient support to make this change. If we do make this change we'll use key usage numbers allocated by Tom Yu (not yet managed by IANA) rather than the ones listed below. --sam --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Wed, 05 Oct 2011 18:50:58 -0400 X-Sieve: CMU Sieve 2.2 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by mail.suchdamage.org (Postfix) with ESMTP id 5B730203C7 for ; Wed, 5 Oct 2011 18:50:58 -0400 (EDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0000111E812F; Wed, 5 Oct 2011 15:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1317854773; bh=g3S4DKOOUCj2ZsCgtOO9yukIXjL5nCl9FBBJ3cyUgKM=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=DGM1TjAKIivDVAvPgfcgFyY0ULu09BDUexV9nHCcN1zpeVT/0G7g7zpNHj334FXJ+ f9GVVRU3sZ2Mdi8sID+kOEe7u0UZbeIl589PWui2XWBBBofsKAJMfIb4F3MtXdUq6Q JZ3givQrzPYhUP7FC6JvbdL8KI4ISRIRthyyWdeg= 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 4CD9111E8122 for ; Wed, 5 Oct 2011 15:46:11 -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.727, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSrlneOW4t-8 for ; Wed, 5 Oct 2011 15:46:10 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id BCE8611E812D for ; Wed, 5 Oct 2011 15:46:10 -0700 (PDT) Received: by us.padl.com with ESMTP id p95MnEk5003997; Wed, 5 Oct 2011 18:49:17 -0400 From: Luke Howard In-Reply-To: <04cf01cc8394$10d05930$32710b90$@augustcellars.com> Date: Thu, 6 Oct 2011 09:49:14 +1100 Message-Id: References: <042a01cc82d5$0f47cb30$2dd76190$@augustcellars.com> <393F9B21-8571-477E-A705-7290A34C11E8@cisco.com> <06E50535-280E-46F5-92F7-D358733EB791@padl.com> <04cf01cc8394$10d05930$32710b90$@augustcellars.com> To: abfab@ietf.org X-Mailer: Apple Mail (2.1244.3) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02 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: , Sender: abfab-bounces@ietf.org Errors-To: abfab-bounces@ietf.org X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Oct 5 18:50:58 2011 X-DSPAM-Confidence: 0.9975 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,4e8cdf5219271587113754 X-DSPAM-Factors: 27, To*ietf.org, 0.00010, Subject*ietf, 0.00010, List-Help*request, 0.00010, From*Luke Howard , 0.00010, List-Post*, 0.00247, References*mit.edu>, 0.00247, Mime-Version*Message, 0.00268, Mime-Version*1.0+(Apple, 0.00268, Mime-Version*(Apple+Message, 0.00268, Mime-Version*Message+framework, 0.00268, X-Mailer*Apple, 0.00271, Received*(mail.ietf.org, 0.00303, Received*mail.ietf.org+(mail.ietf.org, 0.00303, Received*+Wed, 0.00450, Received*from+mail.ietf.org, 0.00453, Received*from+mail.ietf.org, 0.00453, Received*mail.ietf.org, 0.00453, Received*mail.ietf.org, 0.00453, ietf+org, 0.00503, Received*port+10024), 0.00589, Received*(amavisd, 0.00657 MIME-Version: 1.0 So, I propose that we replace the existing GSS channel binding and extension wrap/MIC tokens (respectively) with RFC 3961 checksums using the CRK with the following key usage numbers: KEY_USAGE_CHANNEL_BINDINGS_MIC TBD KEY_USAGE_ACCEPTOR_TOKEN_MIC TBD KEY_USAGE_INITIATOR_TOKEN_MIC TBD A nice property of this is that we can efficiently deal with large GSS channel bindings (because we are sending a checksum rather than a wrap token; recall, we previously sent a wrap token so that the acceptor could ignore channel bindings without disturbing its sequence state). Comments? -- Luke _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab --=-=-=-- From aland@deployingradius.com Tue Oct 18 12:28:35 2011 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 34FEA21F8CEA for ; Tue, 18 Oct 2011 12:28: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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rr6HXurL+CdU for ; Tue, 18 Oct 2011 12:28:34 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9198621F8D29 for ; Tue, 18 Oct 2011 12:28:34 -0700 (PDT) Message-ID: <4E9DD347.5010505@deployingradius.com> Date: Tue, 18 Oct 2011 21:28:07 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Trying to publish with a VSA 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, 18 Oct 2011 19:28:35 -0000 Sam Hartman wrote: > We need a couple of RADIUS attributes. Realistically I don't think we > can get our attributes from the standard IETF namespace: it's basically > running out of attributes. There's work in radext > (draft-ietf-radext-radius-extensions) to extend the namespace. That document is in WG last call. It's waiting for me to update it. I hope to do that this week. > we could create a normative dependency on that work. I have two > concerns: > > 1) It's moving kind of slowly. It's done. :) > 2) It requires significant changes to client and server RADIUS > libraries. For example the libraries I'm familiar with identify > attributes either by a 32-bit identifier (16 bits of vendor and 16-bits > of attribute) or as a vendor plus an attribute. It's not entirely > obvious what interface changes will need to be made to support these new > attributes, but it's quite clear something is required and it's not done > yet. There are multiple implementations of the new format. It requires minimal changes to existing libraries. I know, I've done it. IIRC, adding support for the new format (int/ipaddr alone) is ~200 lines of code. If anyone needs help, I'm glad to assist. > For those of us implementing today it's be really convenient to use > RADIUS attributes from a VSA space. Personally I don't see the problem > with this so long as the organization in question is willing to give up > change control of at least those attributes to the IETF. It's possible > we could get push back from the IESG. It's not really any more work to use the new formats. If people are going to be hacking RADIUS implementations anyways to add channel bindings, adding support for the new format is a small effort. > I'd like to ask the WG though about whether we are willing to try and > use VSA space in a standard assuming we can get change control of the > attributes in question. I think it will significantly help our > time-to-market and will not have any cost other than cleanliness of > standard. I think requiring the new RADIUS format isn't much of a problem. Alan DeKok. From nico@cryptonector.com Tue Oct 18 12:42:00 2011 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 980FD21F8DC1 for ; Tue, 18 Oct 2011 12:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNxBacStRhM4 for ; Tue, 18 Oct 2011 12:42:00 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAB121F8DBD for ; Tue, 18 Oct 2011 12:42:00 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 1CAA65940B4 for ; Tue, 18 Oct 2011 12:41:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=u3a/Y05kYWqbLc4GDOIYWLxwrHQNKqr/Jc3u2puUl5i6 DbXrlPHhZQgWDn9Wuq0BO2wsfiaF7jXv8oXluW4GWKbbwWLVUO8rUSFQO9L57/jr Kfiri5fjikVqnFh/tOc4lnXhWBSXERayX3klprbeh71nVVsf2QkcJFMXZgj1Scw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=wo8fE85SZ+2OmJmwWOSrNClAXfk=; b=AtkOlUZZpTq sbCb0uanR5fPGAMLexPfz1hGRllOPghws+qvURHs6BfEnnhh49tNDm+vDcrNjjgn VdNbh9oB72nWp97Fz57ew5vTSH00X4l1qfRg3ooCcyQriLvb3Apo+JYoVYzIQor5 68j6aYac7xlfE/3F2Qj9+TuK+gX521xo= Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 0F2945940C6 for ; Tue, 18 Oct 2011 12:37:00 -0700 (PDT) Received: by yxj19 with SMTP id 19so1145401yxj.31 for ; Tue, 18 Oct 2011 12:36:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.68 with SMTP id e4mr6744706pbk.126.1318966615727; Tue, 18 Oct 2011 12:36:55 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Tue, 18 Oct 2011 12:36:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Oct 2011 14:36:55 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] Using RFC 3961 checksums for MIC/CB 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, 18 Oct 2011 19:42:00 -0000 On Tue, Oct 18, 2011 at 1:40 PM, Sam Hartman wrote: > Below, Luke made a proposal for updating to using RFC 3961 checksums > rather than RFC 4121 tokens. =C2=A0The main effect is that channel bindin= gs > data is smaller and that we avoid some potential sequencing issues if we > ever want to permit people to send messages before a context is fully > established. > > I'd like to know if we have sufficient support to make this change. I've expressed support for this change before. I'm confirming that support= . > If we do make this change we'll use key usage numbers allocated by Tom > Yu (not yet managed by IANA) rather than the ones listed below. Yes. Nico -- From hartmans@painless-security.com Tue Oct 18 12:47:34 2011 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 78EE221F8DC3 for ; Tue, 18 Oct 2011 12:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SES8mnxlZoe for ; Tue, 18 Oct 2011 12:47:34 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id ED99321F8DAC for ; Tue, 18 Oct 2011 12:47:33 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DD7DB20383 for ; Tue, 18 Oct 2011 15:48:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 463EC4235; Tue, 18 Oct 2011 15:47:16 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org References: <4E9DD347.5010505@deployingradius.com> Date: Tue, 18 Oct 2011 15:47:16 -0400 In-Reply-To: <4E9DD347.5010505@deployingradius.com> (Alan DeKok's message of "Tue, 18 Oct 2011 21:28:07 +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 Subject: Re: [abfab] Trying to publish with a VSA 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, 18 Oct 2011 19:47:34 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> There are multiple implementations of the new format. It Alan> requires minimal changes to existing libraries. I know, I've Alan> done it. Alan> IIRC, adding support for the new format (int/ipaddr alone) Alan> is ~200 lines of code. If anyone needs help, I'm glad to Alan> assist. So, when asking about implementation issues the IETF has a tradition (both from advancement and fromIPR licensing) of asking implementors to go try and something and report back on their experiences. I've just sent mail to the RADIUS library provider we use asking what would be involved in terms of time and cost to add support for this draft. I'll report back to the WG. I'm obviously not going to quote cost numbers, although I'll say something like "no big deal," or "many fine castles and planes." From my standpoint the time number is the much bigger concern. From hartmans@mit.edu Tue Oct 18 14:57:30 2011 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 9D96A21F8BAD; Tue, 18 Oct 2011 14:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B74LbyEUKK5C; Tue, 18 Oct 2011 14:57:29 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D011A21F8B9F; Tue, 18 Oct 2011 14:57:29 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7D41C20383; Tue, 18 Oct 2011 17:58:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CA8724235; Tue, 18 Oct 2011 17:57:17 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org,kitten@ietf.org Date: Tue, 18 Oct 2011 17:57:17 -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] SAML attributes and assertions for naming extensions 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, 18 Oct 2011 21:57:30 -0000 Hi. As a recollection while working on draft-hartman-gss-eap-naming which became draft-ietf-abfab-gss-eap-naming I introduced the concept of a naming extensions context. The idea is that two attributes are different depending on some broad context of their interpretation. The idea is for example that Kerberos attributes in an enterprise context probably want to be interpreted differently than SAML attributes in a federated context. Since then this concept has been worked into the core naming extensions document. (Perhaps some day we'll publish that) However, now it's time to align things between GSS-EAP and SAML ECP and other things. I think we're talking about basically the same context in both mechanisms for the SAML assertion and attributes. We're talking about what I'll call the basic federated context. Attributes are asserted by a party associated with the authentication of the subject. The attributes are integrity protected and their origin authenticated. That is in EAP, if the RADIUS integrity protection fails we won't get this far. In SAML ECP, if we don't trust metadata for the IDP or if the SAML assertion is not signed, we won't make it this far. It's probably OK in this context to include attributes asserted by a third party that are re-asserted or otherwise vouched for by the IDP. It's probably a different context if you have third-party assertions including attribute query results or somehow multiple authentication statements. The key distinguisher of the context is that the IDP and acceptor are in different trust domains but thet IDP and attributes are in the same trust domains. First, have I got the context right? Second, what URN do we want to use. The current URNurn:ietf:params:gss-eap:saml-aaa-assertion has gss-eap and aaa in it both of which are wrong. Comments welcome. From rafa@um.es Tue Oct 18 15:07:05 2011 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 D87A61F0C40; Tue, 18 Oct 2011 15:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxJcbFcyhxwp; Tue, 18 Oct 2011 15:07:05 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 35F021F0C35; Tue, 18 Oct 2011 15:07:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 04BD65D6C8; Wed, 19 Oct 2011 00:06:48 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7ebzrLgTi3iM; Wed, 19 Oct 2011 00:06:48 +0200 (CEST) Received: from [192.168.1.67] (16.Red-83-38-58.dynamicIP.rima-tde.net [83.38.58.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPSA id 49CBB5D442; Wed, 19 Oct 2011 00:06:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Wed, 19 Oct 2011 00:06:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [abfab] GSS-EAP: do we ned an identity request 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, 18 Oct 2011 22:07:06 -0000 Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribi=F3: >>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >=20 > Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribi=F3: >=20 >>> I think I may have been unclear in what I was proposing. I'm >>> proposing that the peer send its identity in the first message >>> (*) and that the server gets to respond with type 4 or greater (a >>> specific EAP method). >=20 > Rafa> Sending its identity does not mean that it must be carried in > Rafa> the EAP response/identity. In fact what I suggested is to > Rafa> carry the identity in the first message but not contained in > Rafa> the EAP response/identity. >=20 > OK. Why not carry it in the EAP response/identity? > It seems easier than developing new encoding. Basically EAP is a lock-step protocol where it is required to get a = request to obtain a response (in the peer side)). So the EAP peer state = machine implementing the EAP standard protocol will react after = receiving an EAP request. So I see two options: either you hack the EAP = peer state machine to return an EAP response/identity without receiving = any EAP request/identity (this "violates" the standard and so we need to = hack the EAP peer state machine) or directly at GSS-API level you create = a EAP response/identity and include the identity (which seems weird = taking into account that we have an EAP stack in charge of creating EAP = messages) Personally, I do not like either (considering the standard RFC 3748). = So, I would prefer to define a subtoken for this. >=20 > However it's certainly easy enough to carry it elsewhere. So, if there > is a reason to do so I'm happy to invent our own subtoken for it. Good. >=20 > do you support the general concept of an optimization here? Yes, I do. Certainly, we save two messages between initiator and = acceptor. Nevertheless, I am not sure how it is the real reduction in = time of this optimization in contrast with the fact that an EAP = authentication may need to reach a home EAP/AAA server and may be = involve several roundtrips to complete. Best regards. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From hartmans@painless-security.com Tue Oct 18 15:24:01 2011 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 8208721F8B1D; Tue, 18 Oct 2011 15:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+jbE9DY5-u5; Tue, 18 Oct 2011 15:24:01 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E24F921F8B1C; Tue, 18 Oct 2011 15:24:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8283E202C9; Tue, 18 Oct 2011 18:25:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C78F54235; Tue, 18 Oct 2011 18:23:48 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> Date: Tue, 18 Oct 2011 18:23:48 -0400 In-Reply-To: <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> (Rafa Marin Lopez's message of "Wed, 19 Oct 2011 00:06:38 +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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [abfab] GSS-EAP: do we ned an identity request 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, 18 Oct 2011 22:24:01 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribió: >>>>>>> "Rafa" == Rafa Marin Lopez writes: >> Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: >> >>>> I think I may have been unclear in what I was proposing. I'm >>>> proposing that the peer send its identity in the first message >>>> (*) and that the server gets to respond with type 4 or greater >>>> (a specific EAP method). >> Rafa> Sending its identity does not mean that it must be carried in Rafa> the EAP response/identity. In fact what I suggested is to Rafa> carry the identity in the first message but not contained in Rafa> the EAP response/identity. >> >> OK. Why not carry it in the EAP response/identity? It seems >> easier than developing new encoding. Rafa> Basically EAP is a lock-step protocol where it is required to Rafa> get a request to obtain a response (in the peer side)). So the Rafa> EAP peer state machine implementing the EAP standard protocol Rafa> will react after receiving an EAP request. So I see two Rafa> options: either you hack the EAP peer state machine to return Rafa> an EAP response/identity without receiving any EAP Rafa> request/identity (this "violates" the standard and so we need Rafa> to hack the EAP peer state machine) Or the initiator synthesizes a request and feeds it to the peer's state machine. IN our implementation, even if the IETF decides on an an alternate encoding for the identity, we'll end up synthesizing an identity request and doing something with the identity response. With a standard EAP library that is lock-step in the manner you describe, it's far easier to produce a synthetic identity request in the initiator than to hack the state machine or do anything else. Think of it this way. In GSS-EAP, the identity request is generated by a party very close to the initiator. EAP already supports the identity request being generated by a different party than the actual EAP messages. Why does it matter whether the request comes from inside the peer or from a NAS? Rafa> or directly at GSS-API Rafa> level you create a EAP response/identity and include the Rafa> identity (which seems weird taking into account that we have Rafa> an EAP stack in charge of creating EAP messages) But if you don't create an EAP response/identity on the initiator you probably do have to do it on the acceptor to trigger AAA to use EAP. Rafa> Personally, I do not like either (considering the standard RFC Rafa> 3748). So, I would prefer to define a subtoken for this. We can do that. It means faking up an identity response on the acceptor. But that is certainly not a big deal. --Sam From lukeh@padl.com Tue Oct 18 16:15:37 2011 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 48E7B21F8AF2; Tue, 18 Oct 2011 16:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=2.209, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC1MQ6hRGIKi; Tue, 18 Oct 2011 16:15:36 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id B64CA21F8AEC; Tue, 18 Oct 2011 16:15:36 -0700 (PDT) Received: by us.padl.com with ESMTP id p9INFGdu026501; Tue, 18 Oct 2011 19:15:22 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Luke Howard In-Reply-To: Date: Wed, 19 Oct 2011 10:15:13 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <60B2C6CF-BD2E-45AC-8295-EFEB4A57676B@padl.com> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1251.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [abfab] GSS-EAP: do we ned an identity request 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, 18 Oct 2011 23:15:37 -0000 > With a standard EAP library that is lock-step in the manner you > describe, it's far easier to produce a synthetic identity request in = the > initiator than to hack the state machine or do anything else. Think = of Right, I actually tried to hack the state machine as described in a very = early iteration and, with the library we used, it just didn't work. -- Luke= From ietf@augustcellars.com Tue Oct 18 16:57:45 2011 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 0B82D1F0C3D for ; Tue, 18 Oct 2011 16:57:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftU0Eu38HxlA for ; Tue, 18 Oct 2011 16:57:44 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9131F0C36 for ; Tue, 18 Oct 2011 16:57:44 -0700 (PDT) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (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 800A02CA09; Tue, 18 Oct 2011 16:57:44 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <00c001cc8625$07fc29e0$17f47da0$@augustcellars.com> In-Reply-To: Date: Tue, 18 Oct 2011 16:57:18 -0700 Message-ID: <00cb01cc8df1$ab2fe7e0$018fb7a0$@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: AQIO4+8tdLp90vuirAO0ZjhgBQ/tjQIWa7C0lO1oCnA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Trying to build the first GSS-API token ---- draft-ietf-abfab-gss-eap-02 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, 18 Oct 2011 23:57:45 -0000 That looks like it should remove my confusion. Jim > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Tuesday, October 18, 2011 7:50 AM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: Trying to build the first GSS-API token ---- draft-ietf-abfab-gss- > eap-02 > > >>>>> "Jim" == Jim Schaad writes: > Jim> 3. Next item in the field is an inner token type - this is a > Jim> 32-bit number -- oh wait, I just figured this out. It would be > Jim> clearer if you used the following terms: First subtoken type > Jim> First subtoken length First subtoken body Second subtoken type. > > Jim> I would be happy if you were consistent on the use of either > Jim> inner token or subtoken but mixing them got me confused. > > OK, I'm trying to be consistent with the following. An inner token is a > non-ASN.1 structure carried in the any in the GSSAPI-Token production > defined in RFC 2743. I.E. the context token without the application tag and > OID wrapper. > > GSS-EAP inner tokens contain a token ID and a series of subtokens. > Subtokens have types, lengths and values. I believe I've made changes to > the document to be consistent with this terminology. From cantor.2@osu.edu Tue Oct 18 17:01:41 2011 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 01DCB21F86AA; Tue, 18 Oct 2011 17:01: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65eCbbVIR4HC; Tue, 18 Oct 2011 17:01:39 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3300D21F86A5; Tue, 18 Oct 2011 17:01:39 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9J01b1u029444; Tue, 18 Oct 2011 20:01:38 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi; Tue, 18 Oct 2011 20:03:23 -0400 From: "Cantor, Scott" To: Sam Hartman , "abfab@ietf.org" , "kitten@ietf.org" Thread-Topic: [kitten] SAML attributes and assertions for naming extensions Thread-Index: AQHMjeD54+roFKd/qkuapWbszhjT8JWCyMqA Date: Wed, 19 Oct 2011 00:01:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.133 Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 00:01:41 -0000 On 10/18/11 5:57 PM, "Sam Hartman" wrote: > >As a recollection while working on draft-hartman-gss-eap-naming which >became draft-ietf-abfab-gss-eap-naming I introduced the concept of a >naming extensions context. The idea is that two attributes are different >depending on some broad context of their interpretation. The idea is for >example that Kerberos attributes in an enterprise context probably want >to be interpreted differently than SAML attributes in a federated >context. And I think the proposal is that the context appear inside the naming extension attribute name as a modifier? >It's probably a different context if you have third-party assertions >including attribute query results or somehow multiple authentication >statements. My current implementation of that doesn't distinguish that case (the attributes end up in the same bucket), but it's an easy fix. https://issues.shibboleth.net/jira/browse/SSPCPP-399 >First, have I got the context right? Much of the time the use of third party sources tends to be for "local" sources associated with the domain of the application, but I agree in principle with the need to distinguish that. I suppose in that sense the cases I've seen would match what you were referring to for Kerberos, the enterprise scenario. >Second, what URN do we want to use. The current >URNurn:ietf:params:gss-eap:saml-aaa-assertion has gss-eap and aaa in it >both of which are wrong. Is it necessary that the value be fixed? If the application-specific names of the attributes themselves aren't fixed, do the contexts have to be? -- Scott From hartmans@painless-security.com Tue Oct 18 17:18:09 2011 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 A101021F8AEE; Tue, 18 Oct 2011 17:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Eyt82EOuBuX; Tue, 18 Oct 2011 17:18:09 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 07FC421F8AEC; Tue, 18 Oct 2011 17:18:08 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A87B2202C9; Tue, 18 Oct 2011 20:19:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D1F794235; Tue, 18 Oct 2011 20:17:50 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: Date: Tue, 18 Oct 2011 20:17:50 -0400 In-Reply-To: (Scott Cantor's message of "Wed, 19 Oct 2011 00:01:39 +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: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 00:18:09 -0000 >>>>> "Cantor," == Cantor, Scott writes: Cantor,> On 10/18/11 5:57 PM, "Sam Hartman" wrote: >> >As a recollection while working on draft-hartman-gss-eap-naming which >> became draft-ietf-abfab-gss-eap-naming I introduced the concept >> of a naming extensions context. The idea is that two attributes >> are different depending on some broad context of their >> interpretation. The idea is for example that Kerberos attributes >> in an enterprise context probably want to be interpreted >> differently than SAML attributes in a federated context. Cantor,> And I think the proposal is that the context appear inside Cantor,> the naming extension attribute name as a modifier? Right. >> It's probably a different context if you have third-party >> assertions including attribute query results or somehow multiple >> authentication statements. Cantor,> My current implementation of that doesn't distinguish that Cantor,> case (the attributes end up in the same bucket), but it's Cantor,> an easy fix. Well, note that anything coming out of attribute mapping in your SP is completely separate and is unprefixed; the administrator is assumed to know their own policy. I'm not sure the most intuitive ECP implementation on top of Shibboleth SP would expose this at all. I'd encourage people to do so; see below. >> First, have I got the context right? Cantor,> Much of the time the use of third party sources tends to be Cantor,> for "local" sources associated with the domain of the Cantor,> application, but I agree in principle with the need to Cantor,> distinguish that. I suppose in that sense the cases I've Cantor,> seen would match what you were referring to for Kerberos, Cantor,> the enterprise scenario. right. >> Second, what URN do we want to use. The current >> URNurn:ietf:params:gss-eap:saml-aaa-assertion has gss-eap and aaa >> in it both of which are wrong. Cantor,> Is it necessary that the value be fixed? If the Cantor,> application-specific names of the attributes themselves Cantor,> aren't fixed, do the contexts have to be? So, I think there are two cases here. The first and probably more common is that an administrator uses some mechanism like your attribute mapping mechanism to map attributes. We don't care much about that case in the IETF. The second case is that someone is specifying a protocol--either in the IETF, or some community, where you do want the attributes to be standardized. To refer to an attribute in a protocol you need to know its context and name. I do think there are some realistic cases for this, although not many involve SAML attributes: 1) I want those RADIUS attributes. For example there is a draft for SNMP over ssh and another draft for RADIUS SNMP authorization. It seems entirely reasonable to me to want to implement that draft for gss-eap and in that case to want to access the specific RADIUS attributes that the RADIUS mapping draft says to use. 2) It seems entirely reasonable to want to ask for the raw assertion from your GSS EAP or ECP mechanism to go do something with it with your own SAML library. So, I'd prefer the context be fixed. I think we need it to be fixed for GSS-EAP. If the use cases for ECP are going to be different then we should consider that. However it would be valuable if you could plug one in case of the other. --Sam From cantor.2@osu.edu Tue Oct 18 18:10:48 2011 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 06EEE21F84CF; Tue, 18 Oct 2011 18:10:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysbCduVjgLcv; Tue, 18 Oct 2011 18:10:47 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7613E21F84CE; Tue, 18 Oct 2011 18:10:45 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9J1AeA4009415; Tue, 18 Oct 2011 21:10:43 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi; Tue, 18 Oct 2011 21:10:33 -0400 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [abfab] [kitten] SAML attributes and assertions for naming extensions Thread-Index: AQHMjfSomHCcEQIe+EKdkBGpDpzay5WC296A Date: Wed, 19 Oct 2011 01:10:29 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Cc: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 01:10:48 -0000 On 10/18/11 8:17 PM, "Sam Hartman" wrote: > >Well, note that anything coming out of attribute mapping in your SP is >completely separate and is unprefixed; the administrator is assumed >to know their own policy. That's generally true, but it's still desirable for applications sitting on top to be able to distinguish between a piece of data from one source vs. another. >So, I'd prefer the context be fixed. I think we need it to be fixed for >GSS-EAP. If the use cases for ECP are going to be different then we >should consider that. However it would be valuable if you could plug one >in case of the other. I guess the way I look at it is that as a consumer of the GSS naming extensions, I'd be physically ill shipping code that hardcoded any names, so I see it all as a config time question. But then I'm also accused of designing systems that are too complex. -- Scott From nico@cryptonector.com Tue Oct 18 19:17:32 2011 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 9DAA91F0C46; Tue, 18 Oct 2011 19:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-uNACwLDLYo; Tue, 18 Oct 2011 19:17:32 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 14D911F0C42; Tue, 18 Oct 2011 19:17:32 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id B9B8136006A; Tue, 18 Oct 2011 19:17:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=XMqX3N76G3fQgoxaxVP3j hLHtBi965QjI/E2bFPkzhGJy+swaLsdT8E8VmiD2wVWdEo5tYP0NZ3h8cbTsRpDX 1BfkpjGegEdzUyWzAhST7QDWJNIlhv2gLIv3EGms+9ZlEn9tzHWIgO2TT35Yi1R2 FxDo2OuIypgrPLM/KO8ePk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=hyBAdcPr2Hdwx+Bj5vE9 yNzix9I=; b=QDTQx2T+iW+5IZS9pY6fQ977XbdbMGeU20+wml6q3NdGMg0Is/Yd Le7gijfSVAnHo5bAAOHpyoCEgV1KPfHpBQn3R3clgP3TIzR4Cla9dFlb8fWgC5CM l3yv/s/Gy5c5weh/L2TObitiBLGu4RiBHmPeJuquqD1s35WDMhCCWks= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 9865D360065; Tue, 18 Oct 2011 19:17:31 -0700 (PDT) Received: by pzk34 with SMTP id 34so3232627pzk.9 for ; Tue, 18 Oct 2011 19:17:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.129 with SMTP id h1mr4100374pbj.92.1318990651218; Tue, 18 Oct 2011 19:17:31 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Tue, 18 Oct 2011 19:17:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Oct 2011 21:17:31 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 02:17:32 -0000 On Tue, Oct 18, 2011 at 8:10 PM, Cantor, Scott wrote: > On 10/18/11 8:17 PM, "Sam Hartman" wrote: >>So, I'd prefer the context be fixed. I think we need it to be fixed for >>GSS-EAP. If the use cases for ECP are going to be different then we >>should consider that. However it would be valuable if you could plug one >>in case of the other. > > I guess the way I look at it is that as a consumer of the GSS naming > extensions, I'd be physically ill shipping code that hardcoded any names, > so I see it all as a config time question. > > But then I'm also accused of designing systems that are too complex. We should want to not hard-code mechanism OIDs, for example, but we have little choice but to hard-code things whose semantics must be embedded in the application. For example: name types. We've added mechanism attributes as a way to avoid hard-coding mechanism OIDs: hard-code the semantics you want rather than the mechanisms you know at that time support those semantics. We could do that with mechanisms, but name-types seem to basic a unit for further decomposition. Ditto, I think, naming attributes, though perhaps not because they are so basic as because there's too much left to run-time interpretation. Fortunately, I think we'll be able to make some types of authorization operations configurable so that naming attributes need not be hard-coded but configurable (e.g., group-membership-like attributes). That said, I don't yet understand what Sam means by "context" here. Nico -- From gabilm@um.es Wed Oct 19 00:39:35 2011 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 D101C21F8AEA; Wed, 19 Oct 2011 00:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl7kVyhDhGkM; Wed, 19 Oct 2011 00:39:35 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 239EF21F8AE6; Wed, 19 Oct 2011 00:39:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id A0AB15D480; Wed, 19 Oct 2011 09:39:33 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k0GqJLNQ2arr; Wed, 19 Oct 2011 09:39:33 +0200 (CEST) Received: from eduroam_um-230-15.inf.um.es (eduroam_um-230-15.inf.um.es [155.54.230.15]) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPA id C6F215D4BC; Wed, 19 Oct 2011 09:39:25 +0200 (CEST) Message-ID: <4E9E7F04.1050103@um.es> Date: Wed, 19 Oct 2011 09:40:52 +0200 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 07:39:36 -0000 Hi El 19/10/11 02:17, Sam Hartman escribió: > > > So, I think there are two cases here. The first and probably more > common is that an administrator uses some mechanism like your attribute > mapping mechanism to map attributes. We don't care much about that case > in the IETF. > > The second case is that someone is specifying a protocol--either in the > IETF, or some community, where you do want the attributes to be > standardized. Both alternatives can be implemented and can work together. The use of standardized attributes is the most desirable scenario but you can find also something like eduroam, where institutions manage attributes like "urn:....:entitlement:student", "urn:...:rol:estudiante", "urn:...:diritto:studente", etc. regards, Gabi > > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- 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 rafa@um.es Wed Oct 19 02:28:12 2011 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 1688021F8BB7; Wed, 19 Oct 2011 02:28:12 -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=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9Zf-lAC06JZ; Wed, 19 Oct 2011 02:28:11 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA2E21F8BB1; Wed, 19 Oct 2011 02:28:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 2B04C5D499; Wed, 19 Oct 2011 11:28:09 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0FLn4vSzSkbg; Wed, 19 Oct 2011 11:28:08 +0200 (CEST) Received: from inf-205-117.inf.um.es (inf-205-117.inf.um.es [155.54.205.117]) (Authenticated sender: rafa) by xenon13.um.es (Postfix) with ESMTPA id 193AD5D477; Wed, 19 Oct 2011 11:28:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Wed, 19 Oct 2011 11:28:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <97A479D2-C633-42E4-9CAE-2868B94B7AF8@um.es> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [abfab] GSS-EAP: do we ned an identity request 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, 19 Oct 2011 09:28:12 -0000 Hi Sam: El 19/10/2011, a las 00:23, Sam Hartman escribi=F3: >>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >=20 > Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribi=F3: >=20 >>>>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >>>=20 > Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribi=F3: >>>=20 >>>>> I think I may have been unclear in what I was proposing. I'm >>>>> proposing that the peer send its identity in the first message >>>>> (*) and that the server gets to respond with type 4 or greater >>>>> (a specific EAP method). >>>=20 > Rafa> Sending its identity does not mean that it must be carried in > Rafa> the EAP response/identity. In fact what I suggested is to > Rafa> carry the identity in the first message but not contained in > Rafa> the EAP response/identity. >>>=20 >>> OK. Why not carry it in the EAP response/identity? It seems >>> easier than developing new encoding. >=20 > Rafa> Basically EAP is a lock-step protocol where it is required to > Rafa> get a request to obtain a response (in the peer side)). So = the > Rafa> EAP peer state machine implementing the EAP standard protocol > Rafa> will react after receiving an EAP request. So I see two > Rafa> options: either you hack the EAP peer state machine to return > Rafa> an EAP response/identity without receiving any EAP > Rafa> request/identity (this "violates" the standard and so we need > Rafa> to hack the EAP peer state machine)=20 >=20 > Or the initiator synthesizes a request and feeds it to the peer's = state > machine. Yes, this is another option, though I don't like either. The reason is = simple. AFAIK, the standard EAP does not say anything about a EAP = lower-layer synthesizing a request (which sounds like another type of = hack). EAP requests are sent by the authenticator. This is what the = standard says. >=20 > IN our implementation, even if the IETF decides on an an alternate > encoding for the identity, we'll end up synthesizing an identity = request > and doing something with the identity response. >=20 > With a standard EAP library that is lock-step in the manner you > describe, it's far easier to produce a synthetic identity request in = the > initiator than to hack the state machine or do anything else. =20 As I said synthesizing an EAP request is another type of hack, because = the EAP protocol does not work like that. We have a RFC 3748 and RFC = 5247 where the EAP protocol is defined. I believe it would be good if we = follow the standards. > Think of > it this way. In GSS-EAP, the identity request is generated by a party > very close to the initiator. EAP already supports the identity = request > being generated by a different party than the actual EAP messages. Why > does it matter whether the request comes from inside the peer or from = a > NAS? Regarding this, you need to think about the mode independence property = of EAP where: "As far as the EAP peer is concerned, its conversation with the EAP = authenticator, and all=20 consequences of that conversation, are identical, regardless of the = authenticator mode of operation." In other words, under peer standpoint, all EAP requests are coming from = the EAP authenticator (the peer does not know and do not care if there = is a backend EAP server or it is integrated with the authenticator).=20 >=20 >=20 > Rafa> or directly at GSS-API > Rafa> level you create a EAP response/identity and include the > Rafa> identity (which seems weird taking into account that we have > Rafa> an EAP stack in charge of creating EAP messages) >=20 > But if you don't create an EAP response/identity on the initiator you > probably do have to do it on the acceptor to trigger AAA to use EAP. I don't think you need to do that. As I explained in the previous = e-mail, in RADIUS EAP (RFC 3579) you can find this text: "Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server. EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data)." In other words, once the acceptor knows the peer's identity can send = that EAP-start message in a RADIUS Access-Challenge. Moreover it should = include the user-name in the request. With that, the RADIUS EAP server = should start the EAP method selected for that peer. >=20 > Rafa> Personally, I do not like either (considering the standard = RFC > Rafa> 3748). So, I would prefer to define a subtoken for this. >=20 > We can do that. It means faking up an identity response on the > acceptor. But that is certainly not a big deal. As explained, you do not need to fake up any identity response on the = acceptor. Just follow what RFC 3579 says. >=20 > --Sam ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From rafa@um.es Wed Oct 19 02:45:17 2011 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 B026921F8B6E; Wed, 19 Oct 2011 02:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDOp5AMf6Zro; Wed, 19 Oct 2011 02:45:16 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 7502621F8B5B; Wed, 19 Oct 2011 02:45:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 4B92B5D4B5; Wed, 19 Oct 2011 11:45:14 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DWNZu7L7iqtV; Wed, 19 Oct 2011 11:45:13 +0200 (CEST) Received: from inf-205-117.inf.um.es (inf-205-117.inf.um.es [155.54.205.117]) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPA id 797E45D6DF; Wed, 19 Oct 2011 11:45:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: <97A479D2-C633-42E4-9CAE-2868B94B7AF8@um.es> Date: Wed, 19 Oct 2011 11:45:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8986EAAD-83DA-4385-A8D4-AE9BFC51217A@um.es> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> <97A479D2-C633-42E4-9CAE-2868B94B7AF8@um.es> To: Rafa Marin Lopez X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [abfab] GSS-EAP: do we ned an identity request 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, 19 Oct 2011 09:45:17 -0000 Please replace RADIUS Access-Challenge by RADIUS Access-Request in the = sentence of my previous e-mail "In other words, once the acceptor knows the peer's identity can send = that EAP-start message in a RADIUS Access-Challenge..." Best regards. El 19/10/2011, a las 11:28, Rafa Marin Lopez escribi=F3: > Hi Sam: >=20 > El 19/10/2011, a las 00:23, Sam Hartman escribi=F3: >=20 >>>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >>=20 >> Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribi=F3: >>=20 >>>>>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >>>>=20 >> Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribi=F3: >>>>=20 >>>>>> I think I may have been unclear in what I was proposing. I'm >>>>>> proposing that the peer send its identity in the first message >>>>>> (*) and that the server gets to respond with type 4 or greater >>>>>> (a specific EAP method). >>>>=20 >> Rafa> Sending its identity does not mean that it must be carried in >> Rafa> the EAP response/identity. In fact what I suggested is to >> Rafa> carry the identity in the first message but not contained in >> Rafa> the EAP response/identity. >>>>=20 >>>> OK. Why not carry it in the EAP response/identity? It seems >>>> easier than developing new encoding. >>=20 >> Rafa> Basically EAP is a lock-step protocol where it is required to >> Rafa> get a request to obtain a response (in the peer side)). So = the >> Rafa> EAP peer state machine implementing the EAP standard protocol >> Rafa> will react after receiving an EAP request. So I see two >> Rafa> options: either you hack the EAP peer state machine to return >> Rafa> an EAP response/identity without receiving any EAP >> Rafa> request/identity (this "violates" the standard and so we need >> Rafa> to hack the EAP peer state machine)=20 >>=20 >> Or the initiator synthesizes a request and feeds it to the peer's = state >> machine. >=20 > Yes, this is another option, though I don't like either. The reason is = simple. AFAIK, the standard EAP does not say anything about a EAP = lower-layer synthesizing a request (which sounds like another type of = hack). EAP requests are sent by the authenticator. This is what the = standard says. >=20 >>=20 >> IN our implementation, even if the IETF decides on an an alternate >> encoding for the identity, we'll end up synthesizing an identity = request >> and doing something with the identity response. >>=20 >> With a standard EAP library that is lock-step in the manner you >> describe, it's far easier to produce a synthetic identity request in = the >> initiator than to hack the state machine or do anything else. =20 >=20 > As I said synthesizing an EAP request is another type of hack, because = the EAP protocol does not work like that. We have a RFC 3748 and RFC = 5247 where the EAP protocol is defined. I believe it would be good if we = follow the standards. >=20 >> Think of >> it this way. In GSS-EAP, the identity request is generated by a party >> very close to the initiator. EAP already supports the identity = request >> being generated by a different party than the actual EAP messages. = Why >> does it matter whether the request comes from inside the peer or from = a >> NAS? >=20 >=20 > Regarding this, you need to think about the mode independence property = of EAP where: >=20 > "As far as the EAP peer is concerned, its conversation with the EAP = authenticator, and all=20 > consequences of that conversation, are identical, regardless of the = authenticator mode of operation." >=20 > In other words, under peer standpoint, all EAP requests are coming = from the EAP authenticator (the peer does not know and do not care if = there is a backend EAP server or it is integrated with the = authenticator).=20 >=20 >=20 >>=20 >>=20 >> Rafa> or directly at GSS-API >> Rafa> level you create a EAP response/identity and include the >> Rafa> identity (which seems weird taking into account that we have >> Rafa> an EAP stack in charge of creating EAP messages) >>=20 >> But if you don't create an EAP response/identity on the initiator you >> probably do have to do it on the acceptor to trigger AAA to use EAP. >=20 > I don't think you need to do that. As I explained in the previous = e-mail, in RADIUS EAP (RFC 3579) you can find this text: >=20 > "Rather than sending an initial EAP-Request packet to the > authenticating peer, on detecting the presence of the peer, the NAS > MAY send an Access-Request packet to the RADIUS server containing an > EAP-Message attribute signifying EAP-Start. The RADIUS server will > typically respond with an Access-Challenge containing EAP-Message > attribute(s) encapsulating an EAP-Request/Identity (Type 1). > However, an EAP-Request for an authentication method (Type 4 or > greater) can also be sent by the server. >=20 > EAP-Start is indicated by sending an EAP-Message attribute with a > length of 2 (no data)." >=20 >=20 > In other words, once the acceptor knows the peer's identity can send = that EAP-start message in a RADIUS Access-Challenge. Moreover it should = include the user-name in the request. With that, the RADIUS EAP server = should start the EAP method selected for that peer. >=20 >=20 >>=20 >> Rafa> Personally, I do not like either (considering the standard = RFC >> Rafa> 3748). So, I would prefer to define a subtoken for this. >>=20 >> We can do that. It means faking up an identity response on the >> acceptor. But that is certainly not a big deal. >=20 > As explained, you do not need to fake up any identity response on the = acceptor. Just follow what RFC 3579 says. >=20 >>=20 >> --Sam >=20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- >=20 >=20 >=20 >=20 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From lukeh@padl.com Wed Oct 19 04:45:45 2011 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 EB4B421F8797; Wed, 19 Oct 2011 04:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=1.105, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwJIMY6d91ru; Wed, 19 Oct 2011 04:45:45 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7C621F84DF; Wed, 19 Oct 2011 04:45:45 -0700 (PDT) Received: by us.padl.com with ESMTP id p9JBjZKK019893; Wed, 19 Oct 2011 07:45:38 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Luke Howard In-Reply-To: <8986EAAD-83DA-4385-A8D4-AE9BFC51217A@um.es> Date: Wed, 19 Oct 2011 22:45:35 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <83857EE9-2988-4FE3-A8E9-19D37D3FAEAF@padl.com> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> <97A479D2-C633-42E4-9CAE-2868B94B7AF8@um.es> <8986EAAD-83DA-4385-A8D4-AE9BFC51217A@um.es> To: Rafa Marin Lopez X-Mailer: Apple Mail (2.1251.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [abfab] GSS-EAP: do we ned an identity request 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, 19 Oct 2011 11:45:46 -0000 Also, this is probably neither here nor there, but NegoEx provides for = server-initiated context establishment (i.e. the first token is emitted = by the acceptor). I seem to have lost the reference to this, although = NegoEx is otherwise specified in draft-zhu-negoex-04. -- Luke= From rafa@um.es Wed Oct 19 05:34:14 2011 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 D4A2621F8BA0; Wed, 19 Oct 2011 05:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFKB3ky-l0cQ; Wed, 19 Oct 2011 05:34:14 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id B3DF921F8B9F; Wed, 19 Oct 2011 05:34:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 41A3C537B8; Wed, 19 Oct 2011 14:34:12 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qo6G-RvDlIu8; Wed, 19 Oct 2011 14:34:11 +0200 (CEST) Received: from inf-205-117.inf.um.es (inf-205-117.inf.um.es [155.54.205.117]) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPA id C2AC05364A; Wed, 19 Oct 2011 14:34:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: <8986EAAD-83DA-4385-A8D4-AE9BFC51217A@um.es> Date: Wed, 19 Oct 2011 14:34:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <713AFE38-AAD7-4463-A1B2-BF667CE6A096@um.es> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> <97A479D2-C633-42E4-9CAE-2868B94B7AF8@um.es> <8986EAAD-83DA-4385-A8D4-AE9BFC51217A@um.es> To: Rafa Marin Lopez X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [abfab] GSS-EAP: do we ned an identity request 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, 19 Oct 2011 12:34:15 -0000 Hi again: I have been thinking again about the situation created with sending an = EAP response/id without the authenticator sending EAP request/id and I = realized that it may be even worse in the authenticator side. Basically, = the authenticator will see an EAP response message which does not answer = to any EAP request sent.=20 Best regards. El 19/10/2011, a las 11:45, Rafa Marin Lopez escribi=F3: > Please replace RADIUS Access-Challenge by RADIUS Access-Request in the = sentence of my previous e-mail >=20 > "In other words, once the acceptor knows the peer's identity can send = that EAP-start message in a RADIUS Access-Challenge..." >=20 > Best regards. >=20 > El 19/10/2011, a las 11:28, Rafa Marin Lopez escribi=F3: >=20 >> Hi Sam: >>=20 >> El 19/10/2011, a las 00:23, Sam Hartman escribi=F3: >>=20 >>>>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >>>=20 >>> Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribi=F3: >>>=20 >>>>>>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >>>>>=20 >>> Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribi=F3: >>>>>=20 >>>>>>> I think I may have been unclear in what I was proposing. I'm >>>>>>> proposing that the peer send its identity in the first message >>>>>>> (*) and that the server gets to respond with type 4 or greater >>>>>>> (a specific EAP method). >>>>>=20 >>> Rafa> Sending its identity does not mean that it must be carried in >>> Rafa> the EAP response/identity. In fact what I suggested is to >>> Rafa> carry the identity in the first message but not contained in >>> Rafa> the EAP response/identity. >>>>>=20 >>>>> OK. Why not carry it in the EAP response/identity? It seems >>>>> easier than developing new encoding. >>>=20 >>> Rafa> Basically EAP is a lock-step protocol where it is required to >>> Rafa> get a request to obtain a response (in the peer side)). So = the >>> Rafa> EAP peer state machine implementing the EAP standard protocol >>> Rafa> will react after receiving an EAP request. So I see two >>> Rafa> options: either you hack the EAP peer state machine to return >>> Rafa> an EAP response/identity without receiving any EAP >>> Rafa> request/identity (this "violates" the standard and so we need >>> Rafa> to hack the EAP peer state machine)=20 >>>=20 >>> Or the initiator synthesizes a request and feeds it to the peer's = state >>> machine. >>=20 >> Yes, this is another option, though I don't like either. The reason = is simple. AFAIK, the standard EAP does not say anything about a EAP = lower-layer synthesizing a request (which sounds like another type of = hack). EAP requests are sent by the authenticator. This is what the = standard says. >>=20 >>>=20 >>> IN our implementation, even if the IETF decides on an an alternate >>> encoding for the identity, we'll end up synthesizing an identity = request >>> and doing something with the identity response. >>>=20 >>> With a standard EAP library that is lock-step in the manner you >>> describe, it's far easier to produce a synthetic identity request in = the >>> initiator than to hack the state machine or do anything else. =20 >>=20 >> As I said synthesizing an EAP request is another type of hack, = because the EAP protocol does not work like that. We have a RFC 3748 and = RFC 5247 where the EAP protocol is defined. I believe it would be good = if we follow the standards. >>=20 >>> Think of >>> it this way. In GSS-EAP, the identity request is generated by a = party >>> very close to the initiator. EAP already supports the identity = request >>> being generated by a different party than the actual EAP messages. = Why >>> does it matter whether the request comes from inside the peer or = from a >>> NAS? >>=20 >>=20 >> Regarding this, you need to think about the mode independence = property of EAP where: >>=20 >> "As far as the EAP peer is concerned, its conversation with the EAP = authenticator, and all=20 >> consequences of that conversation, are identical, regardless of the = authenticator mode of operation." >>=20 >> In other words, under peer standpoint, all EAP requests are coming = from the EAP authenticator (the peer does not know and do not care if = there is a backend EAP server or it is integrated with the = authenticator).=20 >>=20 >>=20 >>>=20 >>>=20 >>> Rafa> or directly at GSS-API >>> Rafa> level you create a EAP response/identity and include the >>> Rafa> identity (which seems weird taking into account that we have >>> Rafa> an EAP stack in charge of creating EAP messages) >>>=20 >>> But if you don't create an EAP response/identity on the initiator = you >>> probably do have to do it on the acceptor to trigger AAA to use EAP. >>=20 >> I don't think you need to do that. As I explained in the previous = e-mail, in RADIUS EAP (RFC 3579) you can find this text: >>=20 >> "Rather than sending an initial EAP-Request packet to the >> authenticating peer, on detecting the presence of the peer, the NAS >> MAY send an Access-Request packet to the RADIUS server containing an >> EAP-Message attribute signifying EAP-Start. The RADIUS server will >> typically respond with an Access-Challenge containing EAP-Message >> attribute(s) encapsulating an EAP-Request/Identity (Type 1). >> However, an EAP-Request for an authentication method (Type 4 or >> greater) can also be sent by the server. >>=20 >> EAP-Start is indicated by sending an EAP-Message attribute with a >> length of 2 (no data)." >>=20 >>=20 >> In other words, once the acceptor knows the peer's identity can send = that EAP-start message in a RADIUS Access-Challenge. Moreover it should = include the user-name in the request. With that, the RADIUS EAP server = should start the EAP method selected for that peer. >>=20 >>=20 >>>=20 >>> Rafa> Personally, I do not like either (considering the standard = RFC >>> Rafa> 3748). So, I would prefer to define a subtoken for this. >>>=20 >>> We can do that. It means faking up an identity response on the >>> acceptor. But that is certainly not a big deal. >>=20 >> As explained, you do not need to fake up any identity response on the = acceptor. Just follow what RFC 3579 says. >>=20 >>>=20 >>> --Sam >>=20 >> ------------------------------------------------------- >> Rafael Marin Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >=20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- >=20 >=20 >=20 >=20 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From hartmans@painless-security.com Wed Oct 19 05:34:23 2011 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 E421A21F8BDB; Wed, 19 Oct 2011 05:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0U7tka45DSN; Wed, 19 Oct 2011 05:34:23 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 80C9E21F8BAE; Wed, 19 Oct 2011 05:34:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 510A6203C7; Wed, 19 Oct 2011 08:35:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 094224235; Wed, 19 Oct 2011 08:34:08 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: Date: Wed, 19 Oct 2011 08:34:08 -0400 In-Reply-To: (Scott Cantor's message of "Wed, 19 Oct 2011 01:10:29 +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: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 12:34:24 -0000 >>>>> "Cantor," == Cantor, Scott writes: Cantor,> On 10/18/11 8:17 PM, "Sam Hartman" wrote: >> >Well, note that anything coming out of attribute mapping in your SP is >> completely separate and is unprefixed; the administrator is >> assumed to know their own policy. Cantor,> That's generally true, but it's still desirable for Cantor,> applications sitting on top to be able to distinguish Cantor,> between a piece of data from one source vs. another. >> So, I'd prefer the context be fixed. I think we need it to be >> fixed for GSS-EAP. If the use cases for ECP are going to be >> different then we should consider that. However it would be >> valuable if you could plug one in case of the other. Cantor,> I guess the way I look at it is that as a consumer of the Cantor,> GSS naming extensions, I'd be physically ill shipping code Cantor,> that hardcoded any names, so I see it all as a config time Cantor,> question. Right and with my IETF hat on I'd be physicall ill shipping a spec that didn't nail that down. If you leave it to configuration you don't get interop. We need to support both models. So, any hints on a URN you'd like? From cantor.2@osu.edu Wed Oct 19 07:44:57 2011 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 77AFC21F8C0A; Wed, 19 Oct 2011 07:44:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qloMQb9s6Ox7; Wed, 19 Oct 2011 07:44:57 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by ietfa.amsl.com (Postfix) with ESMTP id D814521F8AB8; Wed, 19 Oct 2011 07:44:56 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9JEhSQk005978; Wed, 19 Oct 2011 10:43:35 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi; Wed, 19 Oct 2011 10:45:13 -0400 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [abfab] [kitten] SAML attributes and assertions for naming extensions Thread-Index: AQHMjfSomHCcEQIe+EKdkBGpDpzay5WC296AgAECEQD//+ENAA== Date: Wed, 19 Oct 2011 14:43:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <4675a461-dc98-48af-86e6-f5826769174a> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Cc: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 14:44:57 -0000 On 10/19/11 8:34 AM, "Sam Hartman" wrote: > >So, any hints on a URN you'd like? I actually prefer urn:oid: because arguments over names are endless and non-terminating. As a second choice, maybe urn:ietf:kitten:something? -- Scott From nico@cryptonector.com Wed Oct 19 08:07:16 2011 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 7F20821F8C1D; Wed, 19 Oct 2011 08:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swNr7lcsr1nQ; Wed, 19 Oct 2011 08:07:16 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0932A21F8C19; Wed, 19 Oct 2011 08:07:16 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id C59B436006E; Wed, 19 Oct 2011 08:07:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=gqlwR6Ag86jA2PpO7ljV7 wabHQ8yow8kCl5OeHqGFHKp42Bwv3ZCO/h9RoZH8riOYeiYSZJANiNAtNwALqgAE LbhmsSFSNW9w6JVnWotvwhWj2S8bWuaBS4h3C9pKvPv9mWiWsbkKGsmpNliTJ06K cw7DmR/DqCyq03qm7trhZc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=8hBDqkBQsu7G0Fpn+8rD QD19mY0=; b=Y7Xzc3fiKKMPEpFUX3Jb18Wwl+kJRsfdmB7gVYDDsj/z4agx7oH8 pUKRnPcccmvKKJ4qSr5Cvf0kqnbkHXx8UtFkd+l+LzdmqI60yyGXfgk+GIw+Ethm LCBgjmRpNm5pWNtXJzOdDrOCttKmlv/u6x+8cEZ6cf5K7zuRADSjskM= Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 88DB236006D; Wed, 19 Oct 2011 08:07:15 -0700 (PDT) Received: by qyk34 with SMTP id 34so3059010qyk.10 for ; Wed, 19 Oct 2011 08:07:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.68 with SMTP id e4mr12871558pbk.126.1319036834573; Wed, 19 Oct 2011 08:07:14 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 08:07:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Oct 2011 10:07:14 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 15:07:16 -0000 On Wed, Oct 19, 2011 at 9:43 AM, Cantor, Scott wrote: > On 10/19/11 8:34 AM, "Sam Hartman" wrote: >> >>So, any hints on a URN you'd like? > > I actually prefer urn:oid: because arguments over names are endless and > non-terminating. We have names because OIDs were too inconvenient... :) > As a second choice, maybe urn:ietf:kitten:something? I don't think we want WG names in there. Something like urn:ietf:security:nattr:...? Nico -- From hartmans@painless-security.com Wed Oct 19 08:21:49 2011 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 F17F621F8C85 for ; Wed, 19 Oct 2011 08:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zg8CaLCchU4 for ; Wed, 19 Oct 2011 08:21:48 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1700A21F8C7C for ; Wed, 19 Oct 2011 08:21:48 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 49DA220274; Wed, 19 Oct 2011 11:22:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7D9DB4235; Wed, 19 Oct 2011 11:21:30 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> <97A479D2-C633-42E4-9CAE-2868B94B7AF8@um.es> <8986EAAD-83DA-4385-A8D4-AE9BFC51217A@um.es> <713AFE38-AAD7-4463-A1B2-BF667CE6A096@um.es> Date: Wed, 19 Oct 2011 11:21:30 -0400 In-Reply-To: <713AFE38-AAD7-4463-A1B2-BF667CE6A096@um.es> (Rafa Marin Lopez's message of "Wed, 19 Oct 2011 14:34:05 +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] GSS-EAP: do we need an identity request 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, 19 Oct 2011 15:21:49 -0000 Rafa> Hi again: I have been thinking again about the situation Rafa> created with sending an EAP response/id without the Rafa> authenticator sending EAP request/id and I realized that it Rafa> may be even worse in the authenticator side. Basically, the Rafa> authenticator will see an EAP response message which does not Rafa> answer to any EAP request sent. OK. point taken. I've been steadily leaning towards subtoken, but I think the above argument is convincing enough to push me firmly into the subtoken camp. Thanks for walking through this with me! So, I formally propose that we require initiators to send an identity subtoken either in their first token or in the response to the acceptor name. Can I get comments on this? From leifj@sunet.se Wed Oct 19 08:29:14 2011 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 B34BA21F8C84 for ; Wed, 19 Oct 2011 08:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HF-4EC4fzsr5 for ; Wed, 19 Oct 2011 08:29:14 -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 A291221F8C69 for ; Wed, 19 Oct 2011 08:29:13 -0700 (PDT) Received: from [10.2.2.63] ([64.9.249.121]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9JFT5Ol007678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Oct 2011 17:29:10 +0200 (CEST) Message-ID: <4E9EECC1.9060409@sunet.se> Date: Wed, 19 Oct 2011 17:29:05 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 15:29:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/19/2011 04:43 PM, Cantor, Scott wrote: > On 10/19/11 8:34 AM, "Sam Hartman" wrote: >> >> So, any hints on a URN you'd like? > > I actually prefer urn:oid: because arguments over names are endless and > non-terminating. plus people tend not to fight over oids -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6e7MAACgkQ8Jx8FtbMZndxRQCdFMu/gjPFFno7gcMmVZmKJzJk GEkAnRZn9OGgjPAdUFVYGlocxUvPYcus =xMSA -----END PGP SIGNATURE----- From cantor.2@osu.edu Wed Oct 19 08:50:30 2011 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 84DDD21F8C12; Wed, 19 Oct 2011 08:50:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+o3jcSaw2r9; Wed, 19 Oct 2011 08:50:30 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by ietfa.amsl.com (Postfix) with ESMTP id 045C521F8C0E; Wed, 19 Oct 2011 08:50:29 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9JFo3On018128; Wed, 19 Oct 2011 11:50:28 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi; Wed, 19 Oct 2011 11:52:16 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] [abfab] SAML attributes and assertions for naming extensions Thread-Index: AQHMjnEdTjhGgIlevE6ErJzeN9UpAZWD0L2A Date: Wed, 19 Oct 2011 15:50:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <060d7c61-15cb-46ba-b5dd-404d113c9c53> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Cc: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 15:50:30 -0000 On 10/19/11 11:07 AM, "Nico Williams" wrote: >On Wed, Oct 19, 2011 at 9:43 AM, Cantor, Scott wrote: >> >> I actually prefer urn:oid: because arguments over names are endless and >> non-terminating. > >We have names because OIDs were too inconvenient... :) I know, and there's a high degree of overlap between the people who complain about them and the people who bitch endlessly at whatever name you pick. I care little for either set. >> As a second choice, maybe urn:ietf:kitten:something? > >I don't think we want WG names in there. Something like >urn:ietf:security:nattr:...? Given that it's explicitly meant as a GSS-API naming extension, maybe just use gssapi in the name. -- Scott From rafa@um.es Wed Oct 19 08:54:14 2011 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 6A0F221F8C33 for ; Wed, 19 Oct 2011 08:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XRfQc7Ryl82 for ; Wed, 19 Oct 2011 08:54:13 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 8C35321F8C31 for ; Wed, 19 Oct 2011 08:54:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 8F9805D6FB; Wed, 19 Oct 2011 17:54:12 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id c4xEj7zZ9tYO; Wed, 19 Oct 2011 17:54:12 +0200 (CEST) Received: from inf-205-117.inf.um.es (inf-205-117.inf.um.es [155.54.205.117]) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPA id C3B0C5D6F7; Wed, 19 Oct 2011 17:54:08 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Wed, 19 Oct 2011 17:54:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <57E22432-FC34-47A6-B359-D359F9C2FB75@um.es> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> <97A479D2-C633-42E4-9CAE-2868B94B7AF8@um.es> <8986EAAD-83DA-4385-A8D4-AE9BFC51217A@um.es> <713AFE38-AAD7-4463-A1B2-BF667CE6A096@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] GSS-EAP: do we need an identity request 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, 19 Oct 2011 15:54:14 -0000 Hi Sam: El 19/10/2011, a las 17:21, Sam Hartman escribi=F3: >=20 > Rafa> Hi again: I have been thinking again about the situation > Rafa> created with sending an EAP response/id without the > Rafa> authenticator sending EAP request/id and I realized that it > Rafa> may be even worse in the authenticator side. Basically, the > Rafa> authenticator will see an EAP response message which does not > Rafa> answer to any EAP request sent. >=20 > OK. point taken. > I've been steadily leaning towards subtoken, but I think the above > argument is convincing enough to push me firmly into the subtoken = camp. Definitely, designing a subtoken seems the most standard way of defining = this optimization. Nevertheless, we may need to think about something I = just realized. It may happen that when the acceptor sends the EAP-Start = in the RADIUS Access-Request that the RADIUS EAP/AAA server decides to = start the EAP request/identity instead the first EAP request of the = chosen EAP method. The reason is the text about that RFC 3579 I pasted = in my previous e-mail where it is said: "The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server." It means that RADIUS EAP/AAA server implementation is not obligated = (there is no MUST in the text) to start an EAP method instead of sending = an EAP request/identity. This means that RADIUS EAP/AAA should be = correctly configured to allow this optimization. Otherwise, the RADIUS = EAP/AAA server will send the EAP request/identity that has to travel all = the way to the authenticator.=20 Although the solution does not violate any standard, in certain cases it = may not help to achieve the optimization if the home EAP/AAA is not = configured to select directly the EAP method for that peer. Even I would = say that it is more problematic than sending the EAP request/identity = from the authenticator (The EAP request/identity sent from the home = EAP/AAA will add more latency and the same number of messages than the = current not optimized case). So the question would be : can we be sure that all home EAP/AAA servers = will act to allow the optimization? >=20 > Thanks for walking through this with me! Thank you. These conversations are always interesting and I am willing = to participate as far as I can. >=20 > So, I formally propose that we require initiators to send an identity > subtoken either in their first token or in the response to the = acceptor > name. >=20 > Can I get comments on this? ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nico@cryptonector.com Wed Oct 19 08:59:38 2011 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 6E24A21F8C87; Wed, 19 Oct 2011 08:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ2nPd5WHYKy; Wed, 19 Oct 2011 08:59:37 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0F421F8C96; Wed, 19 Oct 2011 08:59:37 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 5CCA3100C2; Wed, 19 Oct 2011 08:59:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=twL7YHUfvypVCWNG+tF3Cu3syrzQevmSXzjg7Xn7BoQm J85mASJcsgNs/6n1azWkxqH6uSaK4rDL6zbSTwFOfgxRv0VR3/CvNURE/MAST7aQ L3iGrwAvKJQgpUGPXOpi5KANjhBIwpdFC9AyNC5KqDjmU5ohniuSXYkRKtphLAo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=wKKf7qdHuW6iBiDIo5pfJjDnAaU=; b=seGlcnzmw6C quSwPieEfqiv27utXmnBJKhy8606odCmrFAta2cd2HvH8DS3g6zQr5dASQL1UyLd yJrtm2cO44/DChGlLNNYkjdIuABXeem7u0dgHXp03DEAQcRjiiivGylrsiMk47aW 9mrOBAiTmKc/f5xwwYkmHR6hi+klS+Vs= Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 9D2EC100BA; Wed, 19 Oct 2011 08:56:14 -0700 (PDT) Received: by ywa8 with SMTP id 8so2205034ywa.31 for ; Wed, 19 Oct 2011 08:56:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.68 with SMTP id e4mr13115690pbk.126.1319039770802; Wed, 19 Oct 2011 08:56:10 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 08:56:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Oct 2011 10:56:10 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 15:59:38 -0000 On Wed, Oct 19, 2011 at 10:50 AM, Cantor, Scott wrote: > On 10/19/11 11:07 AM, "Nico Williams" wrote: >>On Wed, Oct 19, 2011 at 9:43 AM, Cantor, Scott wrote: >>> >>> I actually prefer urn:oid: because arguments over names are endless and >>> non-terminating. >> >>We have names because OIDs were too inconvenient... =C2=A0:) > > I know, and there's a high degree of overlap between the people who > complain about them and the people who bitch endlessly at whatever name > you pick. I care little for either set. I am neutral on this. I'd be just as happy to throw out all the OIDs and replace them with strings in a new version of the API. But you're right about one thing: OIDs represent a psychological barrier to addition of new constants, which might then encourage people to use the entities that exist rather than invent new ones with semantics equal or similar to existing ones. >>> As a second choice, maybe urn:ietf:kitten:something? >> >>I don't think we want WG names in there. =C2=A0Something like >>urn:ietf:security:nattr:...? > > Given that it's explicitly meant as a GSS-API naming extension, maybe jus= t > use gssapi in the name. Can such attributes be useful outside the GSS context? But, sure, urn:ietf:security:gss:nattr:... From hartmans@painless-security.com Wed Oct 19 09:05:32 2011 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 7A1A521F8C8D; Wed, 19 Oct 2011 09:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOsbux6hi0Yl; Wed, 19 Oct 2011 09:05:32 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2057621F8C89; Wed, 19 Oct 2011 09:05:32 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2E6B320274; Wed, 19 Oct 2011 12:06:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 659FE4239; Wed, 19 Oct 2011 12:05:17 -0400 (EDT) From: Sam Hartman To: Nico Williams References: Date: Wed, 19 Oct 2011 12:05:17 -0400 In-Reply-To: (Nico Williams's message of "Wed, 19 Oct 2011 10:56:10 -0500") 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: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 16:05:32 -0000 OK. I'll attempt to propose something. 1) We're not going to use an OID for a lot of reasons including we don't have an OID arc to use for this and we already had that discussion as Nico points out. 2) the URNs proposed so far are not consistent with the IETF's namespace. From hartmans@painless-security.com Wed Oct 19 09:19:08 2011 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 0F1DB21F8CDD for ; Wed, 19 Oct 2011 09:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps3g-W4F0pUI for ; Wed, 19 Oct 2011 09:19:07 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBBC21F8CDA for ; Wed, 19 Oct 2011 09:19:07 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A6ADA20188; Wed, 19 Oct 2011 12:20:20 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D4D784239; Wed, 19 Oct 2011 12:18:53 -0400 (EDT) From: Sam Hartman To: Nico Williams References: Date: Wed, 19 Oct 2011 12:18:53 -0400 In-Reply-To: (Sam Hartman's message of "Wed, 19 Oct 2011 12:05:17 -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: abfab@ietf.org Subject: Re: [abfab] [kitten] SAML attributes and assertions for naming extensions 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, 19 Oct 2011 16:19:08 -0000 >>>>> "Sam" == Sam Hartman writes: Sam> OK. I'll attempt to propose something. Sam> 1) We're not going to use an OID for a lot of reasons including Sam> we don't have an OID arc to use for this and we already had Sam> that discussion as Nico points out. Well, ABFAB could use an OID for names that are clearly gss-eap related. I don't think we should, but we at least have an arc and we aren't kitten that has decided it wants URIs not OIDs. From leifj@mnt.se Wed Oct 19 10:14:21 2011 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 AC4E221F8B5B for ; Wed, 19 Oct 2011 10:14:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsgAcSZU28V3 for ; Wed, 19 Oct 2011 10:14:20 -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 6201421F8B57 for ; Wed, 19 Oct 2011 10:14:20 -0700 (PDT) Received: from [10.2.2.63] ([64.9.249.121]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9JHEDuN028386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Oct 2011 19:14:18 +0200 (CEST) Message-ID: <4E9F0565.8010902@mnt.se> Date: Wed, 19 Oct 2011 19:14:13 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: abfab@ietf.org References: <4E9DD347.5010505@deployingradius.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Trying to publish with a VSA 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, 19 Oct 2011 17:14:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/18/2011 09:47 PM, Sam Hartman wrote: >>>>>> "Alan" == Alan DeKok writes: > > Alan> There are multiple implementations of the new format. It > Alan> requires minimal changes to existing libraries. I know, I've > Alan> done it. > > Alan> IIRC, adding support for the new format (int/ipaddr alone) > Alan> is ~200 lines of code. If anyone needs help, I'm glad to > Alan> assist. > > So, when asking about implementation issues the IETF has a tradition > (both from advancement and fromIPR licensing) of asking implementors to > go try and something and report back on their experiences. > > I've just sent mail to the RADIUS library provider we use asking what > would be involved in terms of time and cost to add support for this > draft. I'll report back to the WG. I'm obviously not going to quote > cost numbers, although I'll say something like "no big deal," or "many > fine castles and planes." From my standpoint the time number is the > much bigger concern. OK so it sounds like we may not have to deal with VSA space. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6fBWQACgkQ8Jx8FtbMZndP9wCdG68ptENl7XmvltVViA/PxENA ci4An1TkRKbo/RDhHZUuCMow9xApOLnW =gpjN -----END PGP SIGNATURE----- From aland@deployingradius.com Wed Oct 19 10:24:49 2011 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 CC69611E80CE for ; Wed, 19 Oct 2011 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.956 X-Spam-Level: X-Spam-Status: No, score=-101.956 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFRxd4NiaOil for ; Wed, 19 Oct 2011 10:24:49 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 489ED11E80C9 for ; Wed, 19 Oct 2011 10:24:49 -0700 (PDT) Message-ID: <4E9F07C4.2030905@deployingradius.com> Date: Wed, 19 Oct 2011 19:24:20 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leif Johansson References: <4E9DD347.5010505@deployingradius.com> <4E9F0565.8010902@mnt.se> In-Reply-To: <4E9F0565.8010902@mnt.se> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Trying to publish with a VSA 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, 19 Oct 2011 17:24:49 -0000 Leif Johansson wrote: > OK so it sounds like we may not have to deal with VSA space. That would be best, if possible. Otherwise, if time pressures are tight, using VSA space is well within the RADIUS tradition. Alan DeKok. From klaas@cisco.com Wed Oct 19 11:10:00 2011 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 5693F21F8C1B for ; Wed, 19 Oct 2011 11:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0WWnie9kXZ1 for ; Wed, 19 Oct 2011 11:09:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C51F621F8C56 for ; Wed, 19 Oct 2011 11:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=528; q=dns/txt; s=iport; t=1319047799; x=1320257399; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=VvJCz7yxzc4Nua1i0YJEKGZ5XMgBnegGA9+Jtt/py/k=; b=asscW4xfTK5lUDk8U9fY5flBxJB5BEyHurpzYV2v6YCt+mZzW9lzdItx IkIJFxG7bzFAcpe2dCoq0pVateSwrfF7bmZuh0mm7fzgp9+B+IAcGHn4A QbPxqZpq1Y72iT5A6ms+AosGnkUmHeq9w3agMZG2SOhJnfBH4C65noTtV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPcRn06tJV2d/2dsb2JhbABEqHmBBYFuAQEBAwEBAQEPAVsLBQsLGC4nMAYTIodeCJdBAZ5NBIc6YQSTfpFZ X-IronPort-AV: E=Sophos;i="4.69,373,1315180800"; d="scan'208";a="29582036" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 19 Oct 2011 18:09:41 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9JI9dZh019076; Wed, 19 Oct 2011 18:09:40 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Klaas Wierenga In-Reply-To: <4E9F07C4.2030905@deployingradius.com> Date: Wed, 19 Oct 2011 20:09:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E9DD347.5010505@deployingradius.com> <4E9F0565.8010902@mnt.se> <4E9F07C4.2030905@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1251.1) Cc: abfab@ietf.org Subject: Re: [abfab] Trying to publish with a VSA 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, 19 Oct 2011 18:10:00 -0000 On Oct 19, 2011, at 7:24 PM, Alan DeKok wrote: > Leif Johansson wrote: >> OK so it sounds like we may not have to deal with VSA space. >=20 > That would be best, if possible. >=20 > Otherwise, if time pressures are tight, using VSA space is well = within > the RADIUS tradition. but having the VSA attributes controlled by the IETF not so much=85. >=20 > Alan DeKok. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From internet-drafts@ietf.org Wed Oct 19 13:56:14 2011 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 B425811E8096; Wed, 19 Oct 2011 13:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7dUo9EM4Aav; Wed, 19 Oct 2011 13:56:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5219811E80A3; Wed, 19 Oct 2011 13:56:14 -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: 3.61 Message-ID: <20111019205614.16239.68499.idtracker@ietfa.amsl.com> Date: Wed, 19 Oct 2011 13:56:14 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-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, 19 Oct 2011 20:56:14 -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 Ac= cess Beyond web Working Group of the IETF. Title : A GSS-API Mechanism for the Extensible Authentication Pr= otocol Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-03.txt Pages : 35 Date : 2011-10-19 This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the EAP mechanism. Through the GS2 family of mechanisms, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-03.txt From hartmans@painless-security.com Wed Oct 19 14:00:12 2011 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 E80A311E80C0 for ; Wed, 19 Oct 2011 14:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41k9Dhz8IIq2 for ; Wed, 19 Oct 2011 14:00:12 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB8F11E80B8 for ; Wed, 19 Oct 2011 14:00:12 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2378320239 for ; Wed, 19 Oct 2011 17:01:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EC39A4239; Wed, 19 Oct 2011 16:59:35 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Wed, 19 Oct 2011 16:59:35 -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] New version of gss-eap 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, 19 Oct 2011 21:00:13 -0000 I think this version addresses: * Jim's comments * Alexey's comment that the ABNF is wrong It populates the following registries * RFC 4121 token ID * GSS-EAP subtoken It's not the final version for IETF 82 though. Outstanding: * RFC 3961 getMIC instead of RFC 4121 MIC tokens * RADIUS VSAs * Error codes From hartmans@painless-security.com Wed Oct 19 14:13:23 2011 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 7A91921F8A67 for ; Wed, 19 Oct 2011 14:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiT6uqIfrqqA for ; Wed, 19 Oct 2011 14:13:22 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A854721F8A58 for ; Wed, 19 Oct 2011 14:13:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 752FC20274 for ; Wed, 19 Oct 2011 17:14:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8000B4239; Wed, 19 Oct 2011 17:13:07 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Wed, 19 Oct 2011 17:13:07 -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] Haunted by I18n 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, 19 Oct 2011 21:13:23 -0000 So, I noticed that we don't specify the character set of the GSS-EAP name. Well, that's sort of easy. We can say UTF-8. Which of course raises the question of "what then." That, shall we say, is kind of a mess. Most of that mess is not our problem. However, the part that definitely is is the comparison of the acceptor name attribute provided via AAA with the attribute provided by EAP channel bindings. We want some sort of normalization insensitive comparison that has nice happy properties. In practice, of course what we'll get is octet comparison on the RADIUS server. Advice from people who have sailed this swap before? From nico@cryptonector.com Wed Oct 19 15:04:11 2011 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 D5A8311E80BA for ; Wed, 19 Oct 2011 15:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58kL--Ghc9Ls for ; Wed, 19 Oct 2011 15:04:11 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 1E92611E80B8 for ; Wed, 19 Oct 2011 15:04:11 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id CA7FC1F0081 for ; Wed, 19 Oct 2011 15:04:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=M2hrEkeWQkXvjXpcNEXhd KCnWeOw1/yhqenO+3r+0fdEr1OeK+7wbRANB8+vYVO+hK4jRoDavICIBt9fr8t1l yUw5Bd0I2UtTa0T+aljNu7Z4f46aWQUef2tFPTjVux5XPlMH98dDVdkkAB09nhYW 1VvEhCgcrWzBSghf3tLfgo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=7FbFdf78TCzBgJ39syGf XLAvc5c=; b=odGUSd1fmx7MJvdBI61Cq5ULql2quiPuR7m8rngXXr6LucviaXGR zJgFe2PVXyxKONdUAoFHjLggkpQuqUb1tSiiqic4ZjHv/faDxhUzrIeVMnDFsRBr AUabktflH0JDhe0VzwhlhyLIhwgR12Ly0O0mzn2YlIElmg79seHPC9E= Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id A76DD1F0078 for ; Wed, 19 Oct 2011 15:04:10 -0700 (PDT) Received: by yxj19 with SMTP id 19so2605562yxj.31 for ; Wed, 19 Oct 2011 15:04:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.102 with SMTP id h6mr15280770pbq.7.1319061849857; Wed, 19 Oct 2011 15:04:09 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 15:04:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Oct 2011 17:04:09 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] Haunted by I18n 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, 19 Oct 2011 22:04:12 -0000 On Wed, Oct 19, 2011 at 4:13 PM, Sam Hartman wrote: > Advice from people who have sailed this swap before? What's the issue? Open source Unicode libraries with various styles of licenses exist that should suffice for your purposes. Do you need normalization or normalization insensitivity only, or do you also need to apply various mappings? Open source Unicode C implementations include: - ICU - the u8_textprep stuff in OpenSolaris (CDDL) - Heimdal has a normalization library I bet there's more. Nico -- From hartmans@painless-security.com Wed Oct 19 17:24:28 2011 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 B836711E80B8 for ; Wed, 19 Oct 2011 17:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1PXWafmA2Qo for ; Wed, 19 Oct 2011 17:24:28 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5E85511E80AF for ; Wed, 19 Oct 2011 17:24:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0922E20274; Wed, 19 Oct 2011 20:25:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E50C44239; Wed, 19 Oct 2011 20:24:13 -0400 (EDT) From: Sam Hartman To: Nico Williams References: Date: Wed, 19 Oct 2011 20:24:13 -0400 In-Reply-To: (Nico Williams's message of "Wed, 19 Oct 2011 17:04:09 -0500") 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] Haunted by I18n 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, 20 Oct 2011 00:24:28 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Wed, Oct 19, 2011 at 4:13 PM, Sam Hartman Nico> wrote: >> Advice from people who have sailed this swap before? Nico> What's the issue? What behavior do we specify? I'm not interested in code--I'm interested in spec text that will work today and will evolve well. From nico@cryptonector.com Wed Oct 19 17:50:40 2011 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 4FEA711E80BA for ; Wed, 19 Oct 2011 17:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXmb+ZT0A8zL for ; Wed, 19 Oct 2011 17:50:39 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 93AA711E80AF for ; Wed, 19 Oct 2011 17:50:39 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 33FA01DE064 for ; Wed, 19 Oct 2011 17:50:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=DZv3nUgRmTRucUlkM+5bumIOuXfG8pSYDv+CYUWifwwk b/cOfybE2aSyDYvND5EMBInYisLVauJTcX1obX8tNUHeujBQFXrv/R9Ma9wLFncW 6PryZp8ZYcI3ssnFXbDn1xi8gcbrbf+IZ7+OfLsTdee7IU69bB6oY2BB39TXJ/w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Z11lA1l22yslLQ24K0c2HOyIQwo=; b=g23f6JDKRsX 8aUdoy50Zor9EtXR7MaXvnCjsVsTv4UMXiOdwc0OVVhZIFZiNU564AS5ne3B7Lkk eVnA0cWKobs5Ue4KKry6N5EhSCgtHum80ZqyARivNgGm1zQ4EodrhE+vvirDtUty ACAZDIq3RlYUMX0E5tdHIlaAMWte0Sqs= Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 0CEBA1DE063 for ; Wed, 19 Oct 2011 17:50:38 -0700 (PDT) Received: by gyh20 with SMTP id 20so2741307gyh.31 for ; Wed, 19 Oct 2011 17:50:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.13.135 with SMTP id h7mr16009129pbc.75.1319071838238; Wed, 19 Oct 2011 17:50:38 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 17:50:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Oct 2011 19:50:38 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] Haunted by I18n 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, 20 Oct 2011 00:50:40 -0000 On Wed, Oct 19, 2011 at 7:24 PM, Sam Hartman wrote: >>>>>> "Nico" =3D=3D Nico Williams writes: > > =C2=A0 =C2=A0Nico> On Wed, Oct 19, 2011 at 4:13 PM, Sam Hartman > =C2=A0 =C2=A0Nico> wrote: > =C2=A0 =C2=A0>> Advice from people who have sailed this swap before? > > =C2=A0 =C2=A0Nico> What's the issue? > > What behavior do we specify? Whenever possible aim to do norm-insensitive comparisons, allowing nodes to just-send-UTF-8. > I'm not interested in code--I'm interested in spec text that will work > today and will evolve well. Well, you stated that RADIUS servers can't be expected to do more than byte-wise comparison. Why is that? And if that really is true then you'll need to send normalized strings. From hartmans@painless-security.com Wed Oct 19 18:59:18 2011 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 BE35C11E80C4 for ; Wed, 19 Oct 2011 18:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAtzpVQ3KLOf for ; Wed, 19 Oct 2011 18:59:18 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5934011E80BF for ; Wed, 19 Oct 2011 18:59:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 74E2020239; Wed, 19 Oct 2011 22:00:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4CDBA4239; Wed, 19 Oct 2011 21:59:00 -0400 (EDT) From: Sam Hartman To: Nico Williams References: Date: Wed, 19 Oct 2011 21:59:00 -0400 In-Reply-To: (Nico Williams's message of "Wed, 19 Oct 2011 19:50:38 -0500") 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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] Haunted by I18n 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, 20 Oct 2011 01:59:18 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Wed, Oct 19, 2011 at 7:24 PM, Sam Hartman Nico> wrote: >>>>>>> "Nico" == Nico Williams writes: >> >>    Nico> On Wed, Oct 19, 2011 at 4:13 PM, Sam >> Hartman >>    Nico> wrote: >>    >> Advice from people who have sailed this swap >> before? >> >>    Nico> What's the issue? >> >> What behavior do we specify? Nico> Whenever possible aim to do norm-insensitive comparisons, Nico> allowing nodes to just-send-UTF-8. Sure. But the current IESG seems to believe that you want at least a SHOULD for what comparison algorithm. We want something that maximizes interop with: * The comparison specified in NAI document * saslprep * whatever Kerberos eventually does * IDNA 2008 for hostnames >> I'm not interested in code--I'm interested in spec text that will >> work today and will evolve well. Nico> Well, you stated that RADIUS servers can't be expected to do Nico> more than byte-wise comparison. Sorry. I was being flip. I suspect we're all lazy and the first implementations will not do more than is required to work most of the time. I suspect as people run into real problems we'll write better code. Note that I'm not writing aRADIUS server. --Sam From nico@cryptonector.com Wed Oct 19 19:34:06 2011 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 A2D2911E80CF for ; Wed, 19 Oct 2011 19:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcvmrL3zkQxy for ; Wed, 19 Oct 2011 19:34:05 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id DDDCC11E80BF for ; Wed, 19 Oct 2011 19:34:05 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 8AB5B584057 for ; Wed, 19 Oct 2011 19:34:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=HbAtohVE74B/V3RXKTQoB i3URJr6T3LmqI+Os3o0/lpYIAkKDxBU7MDu8ein5Lf9dhrVs/qmhBPz+WWTDtpHS EjwYgC9/dTVFgUhVMBVu2klnAlC40JrANkF9KImW3A1ZkJc8UABgR/b7ho6vtoN1 OSTMAdWKfeFp/Eld1JSniY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=rQBYjnWueDkqpprdd5E2 e/aaZ3k=; b=mZl1CZvSikzWnd7Y5G8ZUhkC4W4+SyhL8N1VgiNQgMSkwdoXmzqh 0mZIl4KMgftrp+aYe3YCsfYt6HwBG+usOvUTVmbh5CDJAu0BJKEbBONJE3c8cy75 G4GhNJOd4wS7lRzdQv6+5jHVtRTGKm0FAfaNhCBhFIAY5dj/wvPItKw= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 7A9FC584056 for ; Wed, 19 Oct 2011 19:34:05 -0700 (PDT) Received: by pzk34 with SMTP id 34so6130577pzk.9 for ; Wed, 19 Oct 2011 19:34:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.20.135 with SMTP id n7mr7255926pbe.41.1319078045046; Wed, 19 Oct 2011 19:34:05 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 19:34:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Oct 2011 21:34:05 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] Haunted by I18n 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, 20 Oct 2011 02:34:06 -0000 This is for the acceptor name, yeah? For hostbased services you could say use IDNA A-labels... Yeah, I know. That's ugly. But note that if something's a domainname slot then the comparison semantics are already set. Nico -- From aland@deployingradius.com Wed Oct 19 23:07:14 2011 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 C1EF911E8086 for ; Wed, 19 Oct 2011 23:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.117 X-Spam-Level: X-Spam-Status: No, score=-102.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkTwVeqAFZpb for ; Wed, 19 Oct 2011 23:07:14 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 3F23D11E807F for ; Wed, 19 Oct 2011 23:07:14 -0700 (PDT) Message-ID: <4E9FBA7A.9010200@deployingradius.com> Date: Thu, 20 Oct 2011 08:06:50 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Haunted by I18n 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, 20 Oct 2011 06:07:14 -0000 Nico Williams wrote: > On Wed, Oct 19, 2011 at 7:24 PM, Sam Hartman > Well, you stated that RADIUS servers can't be expected to do more than > byte-wise comparison. Why is that? It's what hey do today. It's the easiest thing to do. Normalization may require information (locale, etc.) which is not available in the protocol. > And if that really is true then > you'll need to send normalized strings. Pretty much. My take is that normalization is out of scope for both the RADIUS server and for the EAP peer. They both rely on some user-facing UI to obtain the user credentials. That UI should perform normalization, as it has information no one else has. Requiring the EAP peer to normalize the data is for me just like asking an intermediate RADIUS proxy to normalize the data. It just doesn't make sense. Alan DeKok. From leifj@mnt.se Thu Oct 20 09:18:41 2011 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 D310321F8C70 for ; Thu, 20 Oct 2011 09:18:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6vwKTbuo4Gp for ; Thu, 20 Oct 2011 09:18:41 -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 CECD821F8C69 for ; Thu, 20 Oct 2011 09:18:40 -0700 (PDT) Received: from [10.100.29.133] ([141.202.11.155]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9KGINEt007994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2011 18:18:30 +0200 (CEST) Message-ID: <4EA049CD.7090607@mnt.se> Date: Thu, 20 Oct 2011 18:18:21 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Klaas Wierenga References: <4E9DD347.5010505@deployingradius.com> <4E9F0565.8010902@mnt.se> <4E9F07C4.2030905@deployingradius.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] Trying to publish with a VSA 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, 20 Oct 2011 16:18:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/19/2011 08:09 PM, Klaas Wierenga wrote: > > On Oct 19, 2011, at 7:24 PM, Alan DeKok wrote: > >> Leif Johansson wrote: >>> OK so it sounds like we may not have to deal with VSA space. >> >> That would be best, if possible. >> >> Otherwise, if time pressures are tight, using VSA space is well within >> the RADIUS tradition. > > but having the VSA attributes controlled by the IETF not so much…. Right. I understood it to be a sneaky thing to do. My vote is to try to stay with extended space. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6gSccACgkQ8Jx8FtbMZneyYQCgs7PR6HREXiAijFccms03BV5f l/IAn3QDBrIDXYP6wo55u1LUTlVpUUks =b/Lq -----END PGP SIGNATURE----- From nico@cryptonector.com Thu Oct 20 10:14:45 2011 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 C879C21F8BE9 for ; Thu, 20 Oct 2011 10:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9R+G0YI7Ajj for ; Thu, 20 Oct 2011 10:14:45 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 36D6121F8B84 for ; Thu, 20 Oct 2011 10:14:45 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id CBA6FBC047 for ; Thu, 20 Oct 2011 10:14:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Wi2SXdfVvkZsF2RlizV4D+jcvqPdp5X7kslztz0nY7ea xHmFEiKP4KL255aq9u9G6FP2gGxwGkferL8nhgcso8DGRK8202vwTDQq4eg/CrIu vah/I/CqsVfCJOxXibAT+FPRgiw71w0IU/nqS7ftLNL1mNV7czCLRytBwDDEGzk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=kSAgc1AbP1aw4VwZjn/WFkOvqY8=; b=PpVHe9pVHT9 xwFs1RzpuReUG2e5fhSYl4yqX+P+tEls3ltWwzft+Abwu27Eq7NHqKsGbz3Rwgqh i+Na4H2gbDccXbhh9t10wQSls13xXTgACJTWiqm+aXa9Y5VTylLhXGJ1cWvfLsiZ b4bgtv1KsYc/bmO3wjpt56+O5wLUybDY= Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id AE7E1BC042 for ; Thu, 20 Oct 2011 10:14:44 -0700 (PDT) Received: by yxj19 with SMTP id 19so3633270yxj.31 for ; Thu, 20 Oct 2011 10:14:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.31.131 with SMTP id a3mr21441714pbi.24.1319130883529; Thu, 20 Oct 2011 10:14:43 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Thu, 20 Oct 2011 10:14:43 -0700 (PDT) In-Reply-To: <4E9FBA7A.9010200@deployingradius.com> References: <4E9FBA7A.9010200@deployingradius.com> Date: Thu, 20 Oct 2011 12:14:43 -0500 Message-ID: From: Nico Williams To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] Haunted by I18n 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, 20 Oct 2011 17:14:45 -0000 On Thu, Oct 20, 2011 at 1:06 AM, Alan DeKok wro= te: > Nico Williams wrote: >> On Wed, Oct 19, 2011 at 7:24 PM, Sam Hartman >> Well, you stated that RADIUS servers can't be expected to do more than >> byte-wise comparison. =C2=A0Why is that? > > =C2=A0It's what hey do today. =C2=A0It's the easiest thing to do. =C2=A0N= ormalization > may require information (locale, etc.) which is not available in the > protocol. Normalization does not require locale information. Case-folding does (because of things like the Turkish i), but the information loss in locale-less case-insensitive comparisons is probably much less problematic than in case-folding for storage strings, say. But we're not talking about case-folding :) >> =C2=A0And if that really is true then >> you'll need to send normalized strings. > > =C2=A0Pretty much. =C2=A0My take is that normalization is out of scope fo= r both > the RADIUS server and for the EAP peer. =C2=A0They both rely on some > user-facing UI to obtain the user credentials. =C2=A0That UI should perfo= rm > normalization, as it has information no one else has. See above. The only information needed for normalization is the input string's codeset and encoding (can we assume UTF-8?) and the desired normalization form (unless we're talking about normalization-insensitive comparison, in which case NF is of little interest). If the relevant strings in RADIUS have historically not had codeset and encoding defined then it will likely be best to say that the peer makes right. For the acceptor name I think it's best to say that the peer makes right. As for GSS_C_NT_HOSTBASED_SERVICE we really need to decide some day whether we want A-labels, U-labels or what. If we say the app must pass A-labels to gss_import_name() then that will apply to all mechs, but if we don't then each mech could convert to A-labels if it wanted to. Perhaps it's time to tackle this at KITTEN? > =C2=A0Requiring the EAP peer to normalize the data is for me just like > asking an intermediate RADIUS proxy to normalize the data. =C2=A0It just > doesn't make sense. OK, thanks. Nico -- From hartmans@painless-security.com Thu Oct 20 10:21:28 2011 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 0D60021F8C12 for ; Thu, 20 Oct 2011 10:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gVfOWCOYu1v for ; Thu, 20 Oct 2011 10:21:27 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0B121F8C11 for ; Thu, 20 Oct 2011 10:21:27 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7A838202FB; Thu, 20 Oct 2011 13:22:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A02664239; Thu, 20 Oct 2011 13:21:07 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <4E9FBA7A.9010200@deployingradius.com> Date: Thu, 20 Oct 2011 13:21:07 -0400 In-Reply-To: (Nico Williams's message of "Thu, 20 Oct 2011 12:14:43 -0500") 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] Haunted by I18n 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, 20 Oct 2011 17:21:28 -0000 >>>>> "Nico" == Nico Williams writes: Nico> For the acceptor name I think it's best to say that the peer Nico> makes right. I don't. Both the initiator and acceptor send this to the EAP server. I think the EAP server is in a much better position to do comparison here than either the peer or acceptor. It's also totally new code. From nico@cryptonector.com Thu Oct 20 11:15:55 2011 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 DC9A321F8AF1 for ; Thu, 20 Oct 2011 11:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpeNd5qL9SCv for ; Thu, 20 Oct 2011 11:15:55 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6483821F8AE6 for ; Thu, 20 Oct 2011 11:15:55 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id F36B976805C for ; Thu, 20 Oct 2011 11:15:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=j+tU+acXUT8FSOVhQbgmnpnX1B48hKz0YkesqTWwCCMB Zq6ZJPJflOuxMgsyp2trWRpjp5cH/oPNNPS0GTPyJbfoum8cxS+bqhxS6kAQzavE CXvuTMC0hnAz+84jDwrtafsYbkKyckK5BOw17PEW5ZrQwxe5bupdZZL436CzfU0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=PFNPAIYiu/LhaF2l02gOSdOKS7Q=; b=pUrD2JU/V5p bsWnhwdSXIOJUc6olkEvk2wb1THNEC2yXrl8xEwYaXkYksD8qNIimNtiufkXERpQ e6l6iiWHGjyccYojYUNZWIV8MqOA6xtPmer7x/acvhtT4qtKophwqt3Uoktg4mhv mCaLkAQ8jDwSb+FwBig5dX6uT1/HAI8I= Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id C809C768058 for ; Thu, 20 Oct 2011 11:15:54 -0700 (PDT) Received: by qadc10 with SMTP id c10so757128qad.31 for ; Thu, 20 Oct 2011 11:15:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.20.135 with SMTP id n7mr12274864pbe.41.1319134554094; Thu, 20 Oct 2011 11:15:54 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Thu, 20 Oct 2011 11:15:54 -0700 (PDT) In-Reply-To: References: <4E9FBA7A.9010200@deployingradius.com> Date: Thu, 20 Oct 2011 13:15:54 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] Haunted by I18n 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, 20 Oct 2011 18:15:56 -0000 On Thu, Oct 20, 2011 at 12:21 PM, Sam Hartman wrote: >>>>>> "Nico" =3D=3D Nico Williams writes: > > =C2=A0 =C2=A0Nico> For the acceptor name I think it's best to say that th= e peer > =C2=A0 =C2=A0Nico> makes right. > > I don't. > Both the initiator and acceptor send this to the EAP server. > I think the EAP server is in a much better position to do comparison > here than either the peer or acceptor. > It's also totally new code. Failure to match leads to fail-safe though, no? But if it's all new code, sure, I'd rather you do norm-insensitive comparison in the EAP server. Nico -- From hartmans@mit.edu Fri Oct 21 10:33:27 2011 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 414D011E80AD for ; Fri, 21 Oct 2011 10:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFBSbLtfAaRX for ; Fri, 21 Oct 2011 10:33:26 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C9F8C1F0C8C for ; Fri, 21 Oct 2011 10:33:26 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 318D8204AB for ; Fri, 21 Oct 2011 13:34:24 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6497D4239; Fri, 21 Oct 2011 13:32:55 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Fri, 21 Oct 2011 13:29:51 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) X-AuditID: 12074425-b7f116d0000008fe-5c-4ea1ac21e904 Authentication-Results: symauth.service.identifier X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRWlGSWpSXmKPExsXiKnlERldxzUI/g6cXtCya7q1id2D0aDpz lDmAMYrLJiU1J7MstUjfLoEr4/FH9YJtHBUH5q5gb2B8ztbFyMkhIWAi8WhDEyOIzShgJLH7 3CtWiLiYxIV768FqhATuMEqcaynoYuQCss8zSazZ+YgVIlEn8WnGdmYQmw2oeeqzv2CDRAQE Jf69nQgWFxawkDiw9ShYnEVAVWLbkbNgcV4g+2TnbqA4B4eogL1E61ouiLCgxMmZT1hAbGYB LYkb/14yTWDkm4UkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdC73czBK91JTSTYzA MBJid1HdwTjhkNIhRgEORiUe3sQFC/2EWBPLiitzDzFKcjApifIuWQ4U4kvKT6nMSCzOiC8q zUktPsQowcGsJMIbsBgox5uSWFmVWpQPk5LmYFES5329w8FPSCA9sSQ1OzW1ILUIJsvEwX6I UYaDQ0mC12Y1ULdgUWp6akVaZk4JshpOEMEFsoYHaI0nSCFvcUFibnFmOkTRKUZFKXFef5CE AEgiozQPbgAs9i8xykoJ8zIyMDAI8QBdAPQ4qvwrRnGgp4V5nUGm8GTmlcBNfwW0mAlosaYk 2OKSRISUVAPjzNQ0Ttvs4445+49sjTgosNlNycfFPtJW7emD9bYbVcIlNdZ+erJrxRr7NVba E3fyRoU13Hkq8od/3sZN6c9vFNkuO/e0TEH1wDy2tVpua7U0+HPdFH9UKC1oarh19XTEHKHK 74c39mpoPTDclXTsh0b8zc6XWW5vmxo4+XRalr5Xtl66mjdSiaU4I9FQi7moOBEA1Zs/gPgC AAA= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] EAP Naming: removing text about attribute query 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, 21 Oct 2011 17:33:27 -0000 So, the current GSS EAP naming attributes document says that if the mechanism performs an attribute query, the results of that attribute query are made available using the same gss-api attribute names as if they were present in the assertion. This was kind of a hack to support something that our implementation does and stems from a past misunderstanding on my part about how Shibboleth SP works. My assumption was that Shibboleth stuck all the SAML attributes in the same bucket. What actually happens is that Shibboleth has a complex configuration and you can map attributes from SAML assertions into the local attribute name space. Alternatively you can ask Shibboleth to go perform a SAML attribute query. I don't think the IETF specs need to talk about attribute query. If attribute query happens it will be something the acceptor does to itself. It will require configuration and as part of configuring it to happen you can configure what attributes get mapped to. however since I'm removing something I want to confirm with the WG. --Sam From nico@cryptonector.com Fri Oct 21 10:45:41 2011 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 AF34B21F8514 for ; Fri, 21 Oct 2011 10:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW0M0g3XhL+v for ; Fri, 21 Oct 2011 10:45:41 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 38B8221F8A97 for ; Fri, 21 Oct 2011 10:45:41 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 909822F4085 for ; Fri, 21 Oct 2011 10:45:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=yK9t54mpRDrN0IX3a9DKr BrzpxYtsfOPI1HbHEi9Wfhmj4wyKzghQV4WjsHJLuwRsAulbOJGezqKHJHMbuQKP nICSzAcWfVWIFZ44RSjQE7uRVCSczY62kNOpwSZjvTwFBya/TCz85dBRBNENA6sI nesbr52tucxIg53mN7RaOA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=tt89gQrENCkNTchomw5p bmqL0bU=; b=EFZPv8C+dPJh/IGazXndQS1/FxcjOq1wRXQmSfiXrfysY3yr6R+p nHnSNEVxvgM2hdStol/3W8lKGW17M7osAJfNuUl0tnwkGRGt922gzHcPZ+sSGrC1 IylCOzHoioJEBhohy7uD4WjL5/9msNwmXPydCWz5902XLiHuGFdlv0w= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 991FA2F4087 for ; Fri, 21 Oct 2011 10:45:21 -0700 (PDT) Received: by pzk34 with SMTP id 34so10510145pzk.9 for ; Fri, 21 Oct 2011 10:45:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.24.200 with SMTP id w8mr29644056pbf.109.1319219120520; Fri, 21 Oct 2011 10:45:20 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Fri, 21 Oct 2011 10:45:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Oct 2011 12:45:20 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] EAP Naming: removing text about attribute query 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, 21 Oct 2011 17:45:41 -0000 I agree. From cantor.2@osu.edu Fri Oct 21 11:19:45 2011 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 AB02921F8A7B for ; Fri, 21 Oct 2011 11:19:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTuNuD7akDhG for ; Fri, 21 Oct 2011 11:19:45 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0834C21F8A6C for ; Fri, 21 Oct 2011 11:19:38 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9LIJWBd009288; Fri, 21 Oct 2011 14:19:37 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi; Fri, 21 Oct 2011 14:19:22 -0400 From: "Cantor, Scott" To: Sam Hartman , "abfab@ietf.org" Thread-Topic: [abfab] EAP Naming: removing text about attribute query Thread-Index: AQHMkBe9OTIcFyOAH0mk/0Rx13yQRZWHG7iA Date: Fri, 21 Oct 2011 18:19:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.133 Subject: Re: [abfab] EAP Naming: removing text about attribute query 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, 21 Oct 2011 18:19:45 -0000 On 10/21/11 1:29 PM, "Sam Hartman" wrote: > >I don't think the IETF specs need to talk about attribute query. If >attribute query happens it will be something the acceptor does to >itself. It will require configuration and as part of configuring it to >happen you can configure what attributes get mapped to. I agree. -- Scott From internet-drafts@ietf.org Fri Oct 21 13:19:11 2011 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 493001F0C56; Fri, 21 Oct 2011 13:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dk3q1pH3xcMw; Fri, 21 Oct 2011 13:19:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0031F0C35; Fri, 21 Oct 2011 13:19:10 -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: 3.61 Message-ID: <20111021201910.29289.65490.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2011 13:19:10 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-naming-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: Fri, 21 Oct 2011 20:19:11 -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 Ac= cess 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-01.txt Pages : 12 Date : 2011-10-21 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-naming-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-naming-01.txt From leifj@sunet.se Fri Oct 21 13:32:07 2011 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 9B62C1F0C36 for ; Fri, 21 Oct 2011 13:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p68OWe7QRx5E for ; Fri, 21 Oct 2011 13:32:07 -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 01C801F0C35 for ; Fri, 21 Oct 2011 13:32:06 -0700 (PDT) Received: from [10.100.29.141] ([141.202.11.155]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9LKVwmG011772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 21 Oct 2011 22:32:05 +0200 (CEST) From: Leif Johansson Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (8L1) Message-Id: <3EC5EED8-B415-475F-884B-E04A74EAADDB@sunet.se> Date: Fri, 21 Oct 2011 13:32:15 -0700 To: abfab@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 8L1) Subject: [abfab] RevIewers plz! 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, 21 Oct 2011 20:32:07 -0000 Folks, the chairs would like to humbly but firmly ask everyone to review th= e new versions of the core specs Sam published. Review is a requisite for ma= king progress in this WG!= From smith@Cardiff.ac.uk Fri Oct 21 13:32:22 2011 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 1F6991F0C4B for ; Fri, 21 Oct 2011 13:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+RZgHFk1BRz for ; Fri, 21 Oct 2011 13:32:21 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id E5A261F0C35 for ; Fri, 21 Oct 2011 13:32:20 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1RHLlL-0000U3-Rt for abfab@ietf.org; Fri, 21 Oct 2011 21:32:19 +0100 Received: from [109.154.183.33] (helo=penfold.home) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RHLlL-0000Ou-Of for abfab@ietf.org; Fri, 21 Oct 2011 21:32:19 +0100 From: Rhys Smith Content-Type: multipart/alternative; boundary="Apple-Mail=_CC655869-3E8D-4B95-A040-67CE0B748820" Date: Fri, 21 Oct 2011 21:32:17 +0100 References: <20111021202529.31294.73373.idtracker@ietfa.amsl.com> To: abfab@ietf.org Message-Id: <9A4ADD8E-05A6-49B6-9C8C-026389068926@cardiff.ac.uk> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: [abfab] Fwd: New Version Notification for draft-smith-abfab-oidregistry-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: Fri, 21 Oct 2011 20:32:22 -0000 --Apple-Mail=_CC655869-3E8D-4B95-A040-67CE0B748820 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii -01 of the OID registry has been uploaded - = http://tools.ietf.org/html/draft-smith-abfab-oidregistry-01 Main changes: * Added two sub arcs, one for mechanisms, one for GSS-API name types. * Assigned one OID in each sub arc after requests (from Sam). Note that I've called the GSS-API name types sub arc simply "nametypes". = Happy to change the name to make it more explicitly gss-api-nametypes if = there's a strong opinion that that would be desirable... R. -- Dr Rhys Smith: Identity, Access, and Middleware Specialist Cardiff University & JANET(UK) email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-smith-abfab-oidregistry-01.txt > Date: 21 October 2011 21:25:29 GMT+01:00 > To: smith@cardiff.ac.uk > Cc: smith@cardiff.ac.uk >=20 > A new version of I-D, draft-smith-abfab-oidregistry-01.txt has been = successfully submitted by Rhys Smith and posted to the IETF repository. >=20 > Filename: draft-smith-abfab-oidregistry > Revision: 01 > Title: Application Bridging for Federated Access = Beyond web (ABFAB) OID Registry > Creation date: 2011-10-21 > WG ID: Individual Submission > Number of pages: 6 >=20 > Abstract: > The IETF ABFAB working group has been assigned an OID arc by IANA. > The goal of this document is to catalogue usage within the arc and > the procedures for IANA to use to control the arc after the ABFAB > working group has handed the arc over. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail=_CC655869-3E8D-4B95-A040-67CE0B748820 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii -01 = of the OID registry has been uploaded - http:= //tools.ietf.org/html/draft-smith-abfab-oidregistry-01

<= div>Main changes:
* Added two sub arcs, one for mechanisms, = one for GSS-API name types.
* Assigned one OID in each sub arc = after requests (from Sam).

Note that I've = called the GSS-API name types sub arc simply "nametypes". Happy to = change the name to make it more explicitly gss-api-nametypes if there's = a strong opinion that that would be = desirable...

R.
--
Dr Rhys = Smith: Identity, Access, and Middleware Specialist
Cardiff University = & JANET(UK)

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C

Begin forwarded message:

Subject: New Version Notification for = draft-smith-abfab-oidregistry-01.txt
Date: 21 October 2011 = 21:25:29 GMT+01:00
To: smith@cardiff.ac.uk
Cc: smith@cardiff.ac.uk

A new version of I-D, draft-smith-abfab-oidregistry-01.txt = has been successfully submitted by Rhys Smith and posted to the IETF = repository.

Filename: = draft-smith-abfab-oidregistry
Revision: 01
Title: = Application Bridging for Federated Access Beyond web (ABFAB) OID = Registry
Creation date: 2011-10-21
WG ID: = Individual Submission
Number of pages: 6

Abstract:
=   The IETF ABFAB working group has been assigned an OID arc by = IANA.
  The goal of this document is to catalogue usage = within the arc and
  the procedures for IANA to use to = control the arc after the ABFAB
  working group has handed = the arc over.




The IETF = Secretariat

= --Apple-Mail=_CC655869-3E8D-4B95-A040-67CE0B748820-- From hartmans@painless-security.com Fri Oct 21 13:44:12 2011 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 397B421F8AF8 for ; Fri, 21 Oct 2011 13:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NTy3oE4c2Ww for ; Fri, 21 Oct 2011 13:44:11 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C334921F8AF7 for ; Fri, 21 Oct 2011 13:44:11 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7B228204AB for ; Fri, 21 Oct 2011 16:45:21 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7CCE14239; Fri, 21 Oct 2011 16:43:52 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Cc: References: <20111021201910.29289.65490.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2011 16:43:52 -0400 In-Reply-To: <20111021201910.29289.65490.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Fri, 21 Oct 2011 13:19:10 -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 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-gss-eap-naming-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: Fri, 21 Oct 2011 20:44:12 -0000 Hi. I've publish a new version of the eap naming I-D. Good things: * I think it addresses most of Jim's comments that should be addressed in eap-naming. A lot of his comments need fixes in aaa-saml instead. * I think it is suseful by saml-ec as well as gss-eap. * I think it is consistent with naming extensions again. * This version is not expired. Bad things: * I don't like the proes. I think it more or less says many of the right things, but the text is tortured. Please please suggest better wording! * The actual constant URNs still need to be done. * Jim, IANA text please? From smith@Cardiff.ac.uk Sat Oct 22 16:33:46 2011 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 F06A321F8677 for ; Sat, 22 Oct 2011 16:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTnGx3cI3MzG for ; Sat, 22 Oct 2011 16:33:45 -0700 (PDT) Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2A621F8663 for ; Sat, 22 Oct 2011 16:33:43 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1RHl4H-0006zs-UM; Sun, 23 Oct 2011 00:33:33 +0100 Received: from [131.251.122.197] (helo=vpn-197.insrv.cf.ac.uk) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RHl4H-0002v4-JA; Sun, 23 Oct 2011 00:33:33 +0100 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_EEFFD99C-B707-43F2-841E-9E990A548354" From: Rhys Smith In-Reply-To: Date: Sat, 22 Oct 2011 15:51:49 -0400 Message-Id: <218238C4-8067-469A-8D16-81466B755C1A@cardiff.ac.uk> References: To: wei.yinxing@zte.com.cn X-Mailer: Apple Mail (2.1251.1) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" 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, 22 Oct 2011 23:33:47 -0000 --Apple-Mail=_EEFFD99C-B707-43F2-841E-9E990A548354 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Yinxing, (cc:ed to abfab list for discussion). I'm just looking at making the next version of the use case document for = ABFAB, and so I've been looking at the use case you suggested (below, if = you don't have a copy of the original message sent to the abfab list). Basically, I've reviewed the suggestion and I'm not quite sure what the = use case actually is? First, it seems as though most all of the content in the text you've = submitted simply describes why federated authentication in general is a = good thing - user registration at the user's "home" identity provider, = better user experience, etc. In your case, the mobile network operator = is the IdP, but they would be a home organisation to some users and = consequently an IdP, just like any other organisation performing the = same task. I'm not arguing that you're not right about federated = authentication being a good thing - but that's not the purpose of this = document. Second, the one thing that seems like it could be different at first = glance in your use case is that you have a layered architecture where = users are using mobile devices, attaching to the network using standard = means, and then performing federated authentication from their devices. = However, I don't see how this is different at all - applications that = users on their mobile devices are using contact the home IdP (in this = case it so happens their home IdP is run by the network provider) and = authenticate the user based upon that. That's standard federated = authentication, just from a mobile device instead of, say, a desktop or = laptop. I think there's a good argument in there that mobile telecoms providers = might make a good class of IdP, but unfortunately that's not applicable = to this document, I don't think. The key thing is that I don't see any new particular applications or use = cases for federated authentication in your text, just a so I'm = struggling to see how, or if, it fits into the use case document. Yinxing - If you think I'm misunderstanding your use case, please do get = back in touch and we can try to figure out what it is and how it fits = into the document. Everyone else - If anyone disagrees with this (if I'm missing something = obvious here), then please let me know where I'm going wrong... R. -- Dr Rhys Smith: Identity, Access, and Middleware Specialist Cardiff University & JANET(UK) email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C On 2 Aug 2011, at 20:53, wei.yinxing@zte.com.cn wrote: >=20 > Dear Rhys Smith,=20 >=20 > According to the action in IETF#81, I summarized the use case in=20 > draft-wei-abfab-fcla-00 as an input to draft-ietf-abfab-usecases-01.=20= > Please review it.=20 >=20 > Thanks!=20 >=20 > Yinxing Wei=20 >=20 > = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=20= > 4.x. Federated Cross-Layer Access=20 >=20 > Telecom operators have a communication network infrastructures to=20= > provider users with a wealthy of access methods. Telecom operators=20= > have a huge number of registered users, and they can provide = trusted=20 > identity and higher security. Therefore they have a natural = advantage=20 > to act as an Identity Provider (IdP) to serve for service = providers.=20 > On the contrary most service providers on the Internet have limited=20= > amount of users and can not assure the security of user identity, = but=20 > they can provide abundant kinds of service. Furthermore, user is=20 > reluctant to register too many accounts because it is inconvenient = to=20 > remember dozens of passwords.=20 >=20 > Telecom network supports Web or non-Web application. In some cases=20= > user prefers to choose non-Web application, e.g. Messaging = service,=20 > VoIP, EMail service, etc. Based on the result of network stratum=20 > authentication and authorization, User equipment (UE) can access=20 > applications without doing another authentication and authorization=20= > procedure. In this way, the system can implement federated = cross-layer=20 > access. Firstly mutual authentication is performed between UE and=20= > Network, secondly UE accesses Application based on the result of=20 > network stratum's authentication. In this case, a federation is = formed=20 > between Network and Application. The brief steps are as follows:=20 >=20 > 1. When UE attaches the Network, mutual authentication is = performed=20 > master session key is created between them.=20 > 2. UE visits non-Web Application, e.g Messaging service, VoIP=20 > service, or Email service.=20 > 3. Application has no information about the UE. The Application=20= > contacts Network to validate the authentication result in the=20= > network stratum. Application can find Network according to the=20= > configuration or dynamical discovery protocol.=20 > 4. Network responds to Application with authentication result.=20 > 5. UE is authorized to access the Application.=20 >=20 > For federated cross-layer access, Network can assure the = Application=20 > of the authenticity of user's identity, share some of use profile=20= > with Application. These can bring some benefits to stakeholders:=20= >=20 > o For telecom operators, they can provide identity service, = trusted=20 > security service, mobile payment service and sharing some user=20= > profiles according user's preferences. Telecom operators is not=20= > just providing pipeline for communication, but also become a = part of=20 > service value chain as an Identity Provider.=20 > o For service providers, they can focus on core business and = reuse=20 > capabilities provided by telecom operators without worrying = about=20 > sources of users.=20 > o For end users, they can enjoy seamless service experiences and=20= > improve security and privacy.=20 >=20 > = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~ > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. --Apple-Mail=_EEFFD99C-B707-43F2-841E-9E990A548354 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Yinxing, (cc:ed to abfab list for discussion).

I'm = just looking at making the next version of the use case document for = ABFAB, and so I've been looking at the use case you suggested (below, if = you don't have a copy of the original message sent to the abfab = list).

Basically, I've reviewed the suggestion = and I'm not quite sure what the use case actually = is?

First, it seems as though most all of the = content in the text you've submitted simply describes why federated = authentication in general is a good thing - user registration at the = user's "home" identity provider, better user experience, etc. In = your case, the mobile network operator is the IdP, but they would be a = home organisation to some users and consequently an IdP, just like any = other organisation performing the same task. I'm not arguing that you're = not right about federated authentication being a good thing - but that's = not the purpose of this document.

Second, the = one thing that seems like it could be different at first glance in your = use case is that you have a layered architecture where users are using = mobile devices, attaching to the network using standard means, and then = performing federated authentication from their devices. However, I don't = see how this is different at all - applications that users on their = mobile devices are using contact the home IdP (in this case it so = happens their home IdP is run by the network provider) and authenticate = the user based upon that. That's standard federated authentication, just = from a mobile device instead of, say, a desktop or = laptop.

I think there's a good argument in = there that mobile telecoms providers might make a good class of IdP, but = unfortunately that's not applicable to this document, I don't = think.

The key thing is that I don't see any = new particular applications or use cases for federated authentication in = your text, just a so I'm struggling to see how, or if, it fits into the = use case document.

Yinxing - If you think I'm = misunderstanding your use case, please do get back in touch and we can = try to figure out what it is and how it fits into the = document.

Everyone else - If anyone disagrees = with this (if I'm missing something obvious here), then please let me = know where I'm going = wrong...

R.
--
Dr Rhys = Smith: Identity, Access, and Middleware Specialist
Cardiff University = & JANET(UK)

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C

On 2 Aug 2011, at 20:53, wei.yinxing@zte.com.cn = wrote:


Dear Rhys Smith,

According to the action in = IETF#81, I summarized the use case in
draft-wei-abfab-fcla-00 as an = input to draft-ietf-abfab-usecases-01.
Please review it.

Thanks!

Yinxing Wei

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~
4.x. Federated Cross-Layer Access

   Telecom operators have a communication = network infrastructures to
   provider users with a wealthy of = access methods. Telecom operators
   have a huge number of registered = users, and they can provide trusted
   identity and higher security. = Therefore they have a natural advantage
   to act as an Identity Provider (IdP) = to serve for service providers.
   On the contrary most service providers = on the Internet have limited
   amount of users and can not assure the = security of user identity, but
   they can provide abundant kinds of = service. Furthermore, user is
   reluctant to register too many = accounts because it is inconvenient to
   remember dozens of passwords.

   Telecom network supports Web or = non-Web application.  In some cases
   user prefers to choose non-Web = application, e.g.  Messaging service,
   VoIP, EMail service, etc. Based on the = result of network stratum
   authentication and authorization, User = equipment (UE) can access
   applications without doing another = authentication and authorization
   procedure. In this way, the system can = implement federated cross-layer
   access. Firstly mutual authentication = is performed between UE and
   Network, secondly UE accesses = Application based on the result of
   network stratum's authentication. In = this case, a federation is formed
   between Network and Application. The = brief steps are as follows:

   1.  When UE attaches the Network, = mutual authentication is performed
       master session key is = created between them.
   2.  UE visits non-Web = Application, e.g Messaging service, VoIP
       service, or Email = service.
   3.  Application has no = information about the UE.  The Application
       contacts Network to = validate the authentication result in the
       network stratum. =  Application can find Network according to the
       configuration or = dynamical discovery protocol.
   4.  Network responds to = Application with authentication result.
   5.  UE is authorized to access = the Application.

   For federated cross-layer access, = Network can assure the Application
   of the authenticity of user's = identity, share some of use profile
   with Application.  These can = bring some benefits to stakeholders:

   o  For telecom operators, they = can provide identity service, trusted
      security service, mobile = payment service and sharing some user
      profiles according user's = preferences. Telecom operators is not
      just providing pipeline for = communication, but also become a part of
      service value chain as an = Identity Provider.
   o  For service providers, =  they can focus on core business and reuse
      capabilities provided by = telecom operators without worrying about
      sources of users.
   o  For end users, they can enjoy = seamless service experiences and
      improve security and = privacy.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~
----------------------------------=
----------------------
=
ZTE Information Security Notice: The information&=
nbsp;contained in this mail is solely proper=
ty of the sender's organization. This mail&n=
bsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy a=
nd are not permitted to disclose the co=
ntents of this communication to others.
=
This email and any files transmitted with&nb=
sp;it are confidential and intended solely f=
or the use of the individual or entity&=
nbsp;to whom they are addressed. If you =
;have received this email in error please&nb=
sp;notify the originator of the message. Any=
 views expressed in this message are th=
ose of the individual sender.
=
This message has been scanned for viruses&nb=
sp;and Spam by ZTE Anti-Spam system.

= --Apple-Mail=_EEFFD99C-B707-43F2-841E-9E990A548354-- From wei.yinxing@zte.com.cn Sun Oct 23 19:51:05 2011 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 3468B21F84BD for ; Sun, 23 Oct 2011 19:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.621 X-Spam-Level: X-Spam-Status: No, score=-94.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnWo1pLai83r for ; Sun, 23 Oct 2011 19:51:03 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 11E4121F84C2 for ; Sun, 23 Oct 2011 19:51:02 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 46621967931198; Mon, 24 Oct 2011 10:43:38 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 99509.4809747284; Mon, 24 Oct 2011 10:50:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p9O2okOl087499; Mon, 24 Oct 2011 10:50:46 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: <218238C4-8067-469A-8D16-81466B755C1A@cardiff.ac.uk> To: Rhys Smith MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Mon, 24 Oct 2011 10:50:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-24 10:50:47, Serialize complete at 2011-10-24 10:50:47 Content-Type: multipart/alternative; boundary="=_alternative 000FA2D248257933_=" X-MAIL: mse01.zte.com.cn p9O2okOl087499 Cc: kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" 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, 24 Oct 2011 02:51:05 -0000 This is a multipart message in MIME format. --=_alternative 000FA2D248257933_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIFJoeXMgDQoNCiAgVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBDbGFyaWZpY2F0aW9ucyBh cmUgaW5saW5lLg0KDQogIEhvcGVmdWxseSwgd2UgY2FuIHJlYWNoIGNvbnNlbnN1cyBvbiB0aGlz IHVzZSBjYXNlLg0KDQoNCg0KDQpSaHlzIFNtaXRoIDxzbWl0aEBjYXJkaWZmLmFjLnVrPiANCrei vP7IyzogIHNtaXRoQENhcmRpZmYuYWMudWsNCjIwMTEvMTAvMjMgMDM6NTENCg0KytW8/sjLDQp3 ZWkueWlueGluZ0B6dGUuY29tLmNuDQqzrcvNDQpoYXJ0bWFucy1pZXRmQG1pdC5lZHUsIGt3aWVy ZW5nQGNpc2NvLmNvbSwgbGVpZmpAc3VuZXQuc2UsIGFiZmFiQGlldGYub3JnDQrW98ziDQpSZTog UGxlYXNlIHJldmlldyB0aGUgdXNlIGNhc2UgIjQueCBGZWRlcmF0ZWQgQ3Jvc3MtTGF5ZXIgQWNj ZXNzIg0KDQoNCg0KDQpIaSBZaW54aW5nLCAoY2M6ZWQgdG8gYWJmYWIgbGlzdCBmb3IgZGlzY3Vz c2lvbikuDQoNCkknbSBqdXN0IGxvb2tpbmcgYXQgbWFraW5nIHRoZSBuZXh0IHZlcnNpb24gb2Yg dGhlIHVzZSBjYXNlIGRvY3VtZW50IGZvciANCkFCRkFCLCBhbmQgc28gSSd2ZSBiZWVuIGxvb2tp bmcgYXQgdGhlIHVzZSBjYXNlIHlvdSBzdWdnZXN0ZWQgKGJlbG93LCBpZiANCnlvdSBkb24ndCBo YXZlIGEgY29weSBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZSBzZW50IHRvIHRoZSBhYmZhYiBsaXN0 KS4NCg0KQmFzaWNhbGx5LCBJJ3ZlIHJldmlld2VkIHRoZSBzdWdnZXN0aW9uIGFuZCBJJ20gbm90 IHF1aXRlIHN1cmUgd2hhdCB0aGUgDQp1c2UgY2FzZSBhY3R1YWxseSBpcz8NCg0KRmlyc3QsIGl0 IHNlZW1zIGFzIHRob3VnaCBtb3N0IGFsbCBvZiB0aGUgY29udGVudCBpbiB0aGUgdGV4dCB5b3Un dmUgDQpzdWJtaXR0ZWQgc2ltcGx5IGRlc2NyaWJlcyB3aHkgZmVkZXJhdGVkIGF1dGhlbnRpY2F0 aW9uIGluIGdlbmVyYWwgaXMgYSANCmdvb2QgdGhpbmcgLSB1c2VyIHJlZ2lzdHJhdGlvbiBhdCB0 aGUgdXNlcidzICJob21lIiBpZGVudGl0eSBwcm92aWRlciwgDQpiZXR0ZXIgdXNlciBleHBlcmll bmNlLCBldGMuIEluIHlvdXIgY2FzZSwgdGhlIG1vYmlsZSBuZXR3b3JrIG9wZXJhdG9yIGlzIA0K dGhlIElkUCwgYnV0IHRoZXkgd291bGQgYmUgYSBob21lIG9yZ2FuaXNhdGlvbiB0byBzb21lIHVz ZXJzIGFuZCANCmNvbnNlcXVlbnRseSBhbiBJZFAsIGp1c3QgbGlrZSBhbnkgb3RoZXIgb3JnYW5p c2F0aW9uIHBlcmZvcm1pbmcgdGhlIHNhbWUgDQp0YXNrLiBJJ20gbm90IGFyZ3VpbmcgdGhhdCB5 b3UncmUgbm90IHJpZ2h0IGFib3V0IGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbiANCmJlaW5nIGEg Z29vZCB0aGluZyAtIGJ1dCB0aGF0J3Mgbm90IHRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQu DQoNCllpbnhpbmcjMT4gDQoNCkZvciB0aGUgdGV4dCAiYnV0IHRoZXkgd291bGQgYmUgYSBob21l IG9yZ2FuaXNhdGlvbiB0byBzb21lIHVzZXJzIGFuZCANCmNvbnNlcXVlbnRseSBhbiBJZFAsIGp1 c3QgbGlrZSBhbnkgb3RoZXIgb3JnYW5pc2F0aW9uIHBlcmZvcm1pbmcgdGhlIHNhbWUgDQp0YXNr LiIuIEkgY291bGQgbm90IHVuZGVyc3RhbmQgaXQgd2VsbC4gSG93IGRvZXMgaXQgcmVsYXRlIHRv IHRoZSB1c2UgDQpjYXNlPw0KDQpGb3IgdGhlIHRleHQgImJ1dCB0aGF0J3Mgbm90IHRoZSBwdXJw b3NlIG9mIHRoaXMgZG9jdW1lbnQiLCB0aGUgDQpjbGFyaWZpY2F0aW9uIGlzIGFzIGZvbGxvd3M6 DQooMSksIEZlZGVyYXRlZCBpZGVudGl0eSBpcyBpbiB0aGUgc2NvcGUgb2YgYWJmYWIgd2csYW5k IHRoZSBjYXNlIGFsc28gDQpzdXBwb3J0cyBub24td2ViIGFwcGxpY2F0aW9uLg0KKDIpLCBpbiB0 aGUgc2VjdGlvbiAzLiBDb250ZXh0IG9mIFVzZSBDYXNlcyBpbiB0aGlzIGRvY3VtZW50IA0KKGRy YWZ0LWlldGYtdXNlY2FzZXMtMDEpLCBpdCBzYXlzOiANCkluIHRoZSBpbnRlcmVzdCBvZiBwcm9t b3RpbmcgdGhlIGRldmVsb3BtZW50IG9mIHRlY2hub2xvZ3kgb2YgYnJvYWQNCmFwcGxpY2FiaWxp dHksIHRoZSBwcmVzZW50IGF1dGhvcnMgd2VsY29tZSB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50 cw0KZnJvbSBvdGhlciBzZWN0b3JzIGFuZCBjb21tdW5pdGllcy4NCg0KVGhpcyBpcyBteSBjb25z aWRlcmF0aW9uIGZvciB0aGUgdXNlIGNhc2Ugb2YgICJGZWRlcmF0ZWQgQ3Jvc3MtTGF5ZXIgDQpB Y2Nlc3MiLg0KDQpTZWNvbmQsIHRoZSBvbmUgdGhpbmcgdGhhdCBzZWVtcyBsaWtlIGl0IGNvdWxk IGJlIGRpZmZlcmVudCBhdCBmaXJzdCANCmdsYW5jZSBpbiB5b3VyIHVzZSBjYXNlIGlzIHRoYXQg eW91IGhhdmUgYSBsYXllcmVkIGFyY2hpdGVjdHVyZSB3aGVyZSANCnVzZXJzIGFyZSB1c2luZyBt b2JpbGUgZGV2aWNlcywgYXR0YWNoaW5nIHRvIHRoZSBuZXR3b3JrIHVzaW5nIHN0YW5kYXJkIA0K bWVhbnMsIGFuZCB0aGVuIHBlcmZvcm1pbmcgZmVkZXJhdGVkIGF1dGhlbnRpY2F0aW9uIGZyb20g dGhlaXIgZGV2aWNlcy4gDQpIb3dldmVyLCBJIGRvbid0IHNlZSBob3cgdGhpcyBpcyBkaWZmZXJl bnQgYXQgYWxsIC0gYXBwbGljYXRpb25zIHRoYXQgDQp1c2VycyBvbiB0aGVpciBtb2JpbGUgZGV2 aWNlcyBhcmUgdXNpbmcgY29udGFjdCB0aGUgaG9tZSBJZFAgKGluIHRoaXMgY2FzZSANCml0IHNv IGhhcHBlbnMgdGhlaXIgaG9tZSBJZFAgaXMgcnVuIGJ5IHRoZSBuZXR3b3JrIHByb3ZpZGVyKSBh bmQgDQphdXRoZW50aWNhdGUgdGhlIHVzZXIgYmFzZWQgdXBvbiB0aGF0LiBUaGF0J3Mgc3RhbmRh cmQgZmVkZXJhdGVkIA0KYXV0aGVudGljYXRpb24sIGp1c3QgZnJvbSBhIG1vYmlsZSBkZXZpY2Ug aW5zdGVhZCBvZiwgc2F5LCBhIGRlc2t0b3Agb3IgDQpsYXB0b3AuDQoNCllpbnhpbmcjMj5UaGUg cG9pbnQgaXMgdGhhdCB0aGUgbW9iaWxlIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgaGFzIGFscmVh ZHkgDQpoYWQgc2VjdXJpdHkgY2FwYWJpbGl0aWVzIChlLmcuIGF1dGhlbnRpY2F0aW9uLCBpbnRl Z3JpdHkgYW5kIA0KY29uZmlkZW50aWFsaXR5ICkgd2hpY2ggaXMgbWFuZGF0b3J5IGZvciB1c2Vy IGVxdWlwbWVudCBhdHRhY2tlZCB0byANCm5ldHdvcmsuDQpBcHBsaWNhdGlvbiBjYW4gbWFrZSB1 c2Ugb2YgdGhpcyBjYXBhYmlsaXR5IHdpdGhvdXQgZHVwbGljYXRpbmcgdGhlIA0Kc2ltaWxhciB0 YXNrIGRvbmUgaW4gbmV0d29yayBsYXllci4gQXMgdG8gZGVza3RvcCBvciBsYXB0b3AsIHdoZW4g dGhleSANCmNvbm5lY3QgdG8gdGhlIG5ldHdvcmssIHRoZSBhdXRoZW50aWNhdGlvbiBpcyBwZXJm b3JtZWQgaW4gb3RoZXIgd2F5IA0KcHJvdmlkZWQgYnkgbmV0d29yayBvcGVyYXRvcnMuDQoNCkkg dGhpbmsgdGhlcmUncyBhIGdvb2QgYXJndW1lbnQgaW4gdGhlcmUgdGhhdCBtb2JpbGUgdGVsZWNv bXMgcHJvdmlkZXJzIA0KbWlnaHQgbWFrZSBhIGdvb2QgY2xhc3Mgb2YgSWRQLCBidXQgdW5mb3J0 dW5hdGVseSB0aGF0J3Mgbm90IGFwcGxpY2FibGUgdG8gDQp0aGlzIGRvY3VtZW50LCBJIGRvbid0 IHRoaW5rLg0KDQpZaW54aW5nIzM+cmVmZXIgdG8gdGhlIHJlcGx5IGluIFlpbnhpbmcjMT4NCg0K VGhlIGtleSB0aGluZyBpcyB0aGF0IEkgZG9uJ3Qgc2VlIGFueSBuZXcgcGFydGljdWxhciBhcHBs aWNhdGlvbnMgb3IgdXNlIA0KY2FzZXMgZm9yIGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbiBpbiB5 b3VyIHRleHQsIGp1c3QgYSBzbyBJJ20gc3RydWdnbGluZyANCnRvIHNlZSBob3csIG9yIGlmLCBp dCBmaXRzIGludG8gdGhlIHVzZSBjYXNlIGRvY3VtZW50Lg0KDQpZaW54aW5nIC0gSWYgeW91IHRo aW5rIEknbSBtaXN1bmRlcnN0YW5kaW5nIHlvdXIgdXNlIGNhc2UsIHBsZWFzZSBkbyBnZXQgDQpi YWNrIGluIHRvdWNoIGFuZCB3ZSBjYW4gdHJ5IHRvIGZpZ3VyZSBvdXQgd2hhdCBpdCBpcyBhbmQg aG93IGl0IGZpdHMgaW50byANCnRoZSBkb2N1bWVudC4NCg0KRXZlcnlvbmUgZWxzZSAtIElmIGFu eW9uZSBkaXNhZ3JlZXMgd2l0aCB0aGlzIChpZiBJJ20gbWlzc2luZyBzb21ldGhpbmcgDQpvYnZp b3VzIGhlcmUpLCB0aGVuIHBsZWFzZSBsZXQgbWUga25vdyB3aGVyZSBJJ20gZ29pbmcgd3Jvbmcu Li4NCg0KUi4NCi0tDQpEciBSaHlzIFNtaXRoOiBJZGVudGl0eSwgQWNjZXNzLCBhbmQgTWlkZGxl d2FyZSBTcGVjaWFsaXN0DQpDYXJkaWZmIFVuaXZlcnNpdHkgJiBKQU5FVChVSykNCg0KZW1haWw6 IHNtaXRoQGNhcmRpZmYuYWMudWsgLyByaHlzLnNtaXRoQGphLm5ldA0KR1BHOiAweERFMkYwMjRD DQoNCk9uIDIgQXVnIDIwMTEsIGF0IDIwOjUzLCB3ZWkueWlueGluZ0B6dGUuY29tLmNuIHdyb3Rl Og0KDQoNCkRlYXIgUmh5cyBTbWl0aCwgDQoNCkFjY29yZGluZyB0byB0aGUgYWN0aW9uIGluIElF VEYjODEsIEkgc3VtbWFyaXplZCB0aGUgdXNlIGNhc2UgaW4gDQpkcmFmdC13ZWktYWJmYWItZmNs YS0wMCBhcyBhbiBpbnB1dCB0byBkcmFmdC1pZXRmLWFiZmFiLXVzZWNhc2VzLTAxLiANClBsZWFz ZSByZXZpZXcgaXQuIA0KDQpUaGFua3MhIA0KDQpZaW54aW5nIFdlaSANCg0Kfn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn4gDQo0LnguIEZlZGVyYXRlZCBDcm9zcy1MYXllciBBY2Nlc3MgDQoNCiAgIFRlbGVjb20gb3Bl cmF0b3JzIGhhdmUgYSBjb21tdW5pY2F0aW9uIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmVzIHRvIA0K ICAgcHJvdmlkZXIgdXNlcnMgd2l0aCBhIHdlYWx0aHkgb2YgYWNjZXNzIG1ldGhvZHMuIFRlbGVj b20gb3BlcmF0b3JzIA0KICAgaGF2ZSBhIGh1Z2UgbnVtYmVyIG9mIHJlZ2lzdGVyZWQgdXNlcnMs IGFuZCB0aGV5IGNhbiBwcm92aWRlIHRydXN0ZWQgDQogICBpZGVudGl0eSBhbmQgaGlnaGVyIHNl Y3VyaXR5LiBUaGVyZWZvcmUgdGhleSBoYXZlIGEgbmF0dXJhbCBhZHZhbnRhZ2UgDQogICB0byBh Y3QgYXMgYW4gSWRlbnRpdHkgUHJvdmlkZXIgKElkUCkgdG8gc2VydmUgZm9yIHNlcnZpY2UgcHJv dmlkZXJzLiANCiAgIE9uIHRoZSBjb250cmFyeSBtb3N0IHNlcnZpY2UgcHJvdmlkZXJzIG9uIHRo ZSBJbnRlcm5ldCBoYXZlIGxpbWl0ZWQgDQogICBhbW91bnQgb2YgdXNlcnMgYW5kIGNhbiBub3Qg YXNzdXJlIHRoZSBzZWN1cml0eSBvZiB1c2VyIGlkZW50aXR5LCBidXQgDQogICB0aGV5IGNhbiBw cm92aWRlIGFidW5kYW50IGtpbmRzIG9mIHNlcnZpY2UuIEZ1cnRoZXJtb3JlLCB1c2VyIGlzIA0K ICAgcmVsdWN0YW50IHRvIHJlZ2lzdGVyIHRvbyBtYW55IGFjY291bnRzIGJlY2F1c2UgaXQgaXMg aW5jb252ZW5pZW50IHRvIA0KICAgcmVtZW1iZXIgZG96ZW5zIG9mIHBhc3N3b3Jkcy4gDQoNCiAg IFRlbGVjb20gbmV0d29yayBzdXBwb3J0cyBXZWIgb3Igbm9uLVdlYiBhcHBsaWNhdGlvbi4gIElu IHNvbWUgY2FzZXMgDQogICB1c2VyIHByZWZlcnMgdG8gY2hvb3NlIG5vbi1XZWIgYXBwbGljYXRp b24sIGUuZy4gIE1lc3NhZ2luZyBzZXJ2aWNlLCANCiAgIFZvSVAsIEVNYWlsIHNlcnZpY2UsIGV0 Yy4gQmFzZWQgb24gdGhlIHJlc3VsdCBvZiBuZXR3b3JrIHN0cmF0dW0gDQogICBhdXRoZW50aWNh dGlvbiBhbmQgYXV0aG9yaXphdGlvbiwgVXNlciBlcXVpcG1lbnQgKFVFKSBjYW4gYWNjZXNzIA0K ICAgYXBwbGljYXRpb25zIHdpdGhvdXQgZG9pbmcgYW5vdGhlciBhdXRoZW50aWNhdGlvbiBhbmQg YXV0aG9yaXphdGlvbiANCiAgIHByb2NlZHVyZS4gSW4gdGhpcyB3YXksIHRoZSBzeXN0ZW0gY2Fu IGltcGxlbWVudCBmZWRlcmF0ZWQgY3Jvc3MtbGF5ZXIgDQogICBhY2Nlc3MuIEZpcnN0bHkgbXV0 dWFsIGF1dGhlbnRpY2F0aW9uIGlzIHBlcmZvcm1lZCBiZXR3ZWVuIFVFIGFuZCANCiAgIE5ldHdv cmssIHNlY29uZGx5IFVFIGFjY2Vzc2VzIEFwcGxpY2F0aW9uIGJhc2VkIG9uIHRoZSByZXN1bHQg b2YgDQogICBuZXR3b3JrIHN0cmF0dW0ncyBhdXRoZW50aWNhdGlvbi4gSW4gdGhpcyBjYXNlLCBh IGZlZGVyYXRpb24gaXMgZm9ybWVkIA0KICAgYmV0d2VlbiBOZXR3b3JrIGFuZCBBcHBsaWNhdGlv bi4gVGhlIGJyaWVmIHN0ZXBzIGFyZSBhcyBmb2xsb3dzOiANCg0KICAgMS4gIFdoZW4gVUUgYXR0 YWNoZXMgdGhlIE5ldHdvcmssIG11dHVhbCBhdXRoZW50aWNhdGlvbiBpcyBwZXJmb3JtZWQgDQog ICAgICAgbWFzdGVyIHNlc3Npb24ga2V5IGlzIGNyZWF0ZWQgYmV0d2VlbiB0aGVtLiANCiAgIDIu ICBVRSB2aXNpdHMgbm9uLVdlYiBBcHBsaWNhdGlvbiwgZS5nIE1lc3NhZ2luZyBzZXJ2aWNlLCBW b0lQIA0KICAgICAgIHNlcnZpY2UsIG9yIEVtYWlsIHNlcnZpY2UuIA0KICAgMy4gIEFwcGxpY2F0 aW9uIGhhcyBubyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgVUUuICBUaGUgQXBwbGljYXRpb24gDQog ICAgICAgY29udGFjdHMgTmV0d29yayB0byB2YWxpZGF0ZSB0aGUgYXV0aGVudGljYXRpb24gcmVz dWx0IGluIHRoZSANCiAgICAgICBuZXR3b3JrIHN0cmF0dW0uICBBcHBsaWNhdGlvbiBjYW4gZmlu ZCBOZXR3b3JrIGFjY29yZGluZyB0byB0aGUgDQogICAgICAgY29uZmlndXJhdGlvbiBvciBkeW5h bWljYWwgZGlzY292ZXJ5IHByb3RvY29sLiANCiAgIDQuICBOZXR3b3JrIHJlc3BvbmRzIHRvIEFw cGxpY2F0aW9uIHdpdGggYXV0aGVudGljYXRpb24gcmVzdWx0LiANCiAgIDUuICBVRSBpcyBhdXRo b3JpemVkIHRvIGFjY2VzcyB0aGUgQXBwbGljYXRpb24uIA0KDQogICBGb3IgZmVkZXJhdGVkIGNy b3NzLWxheWVyIGFjY2VzcywgTmV0d29yayBjYW4gYXNzdXJlIHRoZSBBcHBsaWNhdGlvbiANCiAg IG9mIHRoZSBhdXRoZW50aWNpdHkgb2YgdXNlcidzIGlkZW50aXR5LCBzaGFyZSBzb21lIG9mIHVz ZSBwcm9maWxlIA0KICAgd2l0aCBBcHBsaWNhdGlvbi4gIFRoZXNlIGNhbiBicmluZyBzb21lIGJl bmVmaXRzIHRvIHN0YWtlaG9sZGVyczogDQoNCiAgIG8gIEZvciB0ZWxlY29tIG9wZXJhdG9ycywg dGhleSBjYW4gcHJvdmlkZSBpZGVudGl0eSBzZXJ2aWNlLCB0cnVzdGVkIA0KICAgICAgc2VjdXJp dHkgc2VydmljZSwgbW9iaWxlIHBheW1lbnQgc2VydmljZSBhbmQgc2hhcmluZyBzb21lIHVzZXIg DQogICAgICBwcm9maWxlcyBhY2NvcmRpbmcgdXNlcidzIHByZWZlcmVuY2VzLiBUZWxlY29tIG9w ZXJhdG9ycyBpcyBub3QgDQogICAgICBqdXN0IHByb3ZpZGluZyBwaXBlbGluZSBmb3IgY29tbXVu aWNhdGlvbiwgYnV0IGFsc28gYmVjb21lIGEgcGFydCBvZiANCg0KICAgICAgc2VydmljZSB2YWx1 ZSBjaGFpbiBhcyBhbiBJZGVudGl0eSBQcm92aWRlci4gDQogICBvICBGb3Igc2VydmljZSBwcm92 aWRlcnMsICB0aGV5IGNhbiBmb2N1cyBvbiBjb3JlIGJ1c2luZXNzIGFuZCByZXVzZSANCiAgICAg IGNhcGFiaWxpdGllcyBwcm92aWRlZCBieSB0ZWxlY29tIG9wZXJhdG9ycyB3aXRob3V0IHdvcnJ5 aW5nIGFib3V0IA0KICAgICAgc291cmNlcyBvZiB1c2Vycy4gDQogICBvICBGb3IgZW5kIHVzZXJz LCB0aGV5IGNhbiBlbmpveSBzZWFtbGVzcyBzZXJ2aWNlIGV4cGVyaWVuY2VzIGFuZCANCiAgICAg IGltcHJvdmUgc2VjdXJpdHkgYW5kIHByaXZhY3kuIA0KDQp+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgbWFpbCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3Jn YW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCmNvbmZpZGVudGlhbC4gUmVj aXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5k IA0KYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29t bXVuaWNhdGlvbiB0byANCm90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIA0Kc29sZWx5IGZvciB0 aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJl c3NlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBu b3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3Nl ZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2aWR1YWwgc2VuZGVyLg0K VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRF IEFudGktU3BhbSANCnN5c3RlbS4NCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5 IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5p Y2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdh dGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2 aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMg YW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 000FA2D248257933_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBSaHlzIDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFRoYW5rcyBmb3Ig eW91ciBjb21tZW50cy4gQ2xhcmlmaWNhdGlvbnMNCmFyZSBpbmxpbmUuPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgSG9wZWZ1bGx5LCB3ZSBj YW4gcmVhY2ggY29uc2Vuc3VzDQpvbiB0aGlzIHVzZSBjYXNlLjwvZm9udD4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lk dGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5SaHlzIFNtaXRoICZsdDtz bWl0aEBjYXJkaWZmLmFjLnVrJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtzbWl0aEBDYXJkaWZmLmFjLnVrPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEvMTAvMjMgMDM6NTE8L2ZvbnQ+ DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7I yzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+d2VpLnlp bnhpbmdAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+aGFydG1hbnMtaWV0ZkBtaXQuZWR1 LCBrd2llcmVuZ0BjaXNjby5jb20sDQpsZWlmakBzdW5ldC5zZSwgYWJmYWJAaWV0Zi5vcmc8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPlJlOiBQbGVhc2UgcmV2aWV3IHRoZSB1c2UgY2FzZSAmcXVvdDs0LngN CkZlZGVyYXRlZCBDcm9zcy1MYXllciBBY2Nlc3MmcXVvdDs8L2ZvbnQ+PC90YWJsZT4NCjxicj4N Cjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJs ZT4NCjxicj48Zm9udCBzaXplPTM+SGkgWWlueGluZywgKGNjOmVkIHRvIGFiZmFiIGxpc3QgZm9y IGRpc2N1c3Npb24pLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+SSdtIGp1c3QgbG9v a2luZyBhdCBtYWtpbmcgdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgdXNlDQpjYXNlIGRvY3VtZW50 IGZvciBBQkZBQiwgYW5kIHNvIEkndmUgYmVlbiBsb29raW5nIGF0IHRoZSB1c2UgY2FzZSB5b3Ug c3VnZ2VzdGVkDQooYmVsb3csIGlmIHlvdSBkb24ndCBoYXZlIGEgY29weSBvZiB0aGUgb3JpZ2lu YWwgbWVzc2FnZSBzZW50IHRvIHRoZSBhYmZhYg0KbGlzdCkuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9Mz5CYXNpY2FsbHksIEkndmUgcmV2aWV3ZWQgdGhlIHN1Z2dlc3Rpb24gYW5kIEkn bSBub3QgcXVpdGUNCnN1cmUgd2hhdCB0aGUgdXNlIGNhc2UgYWN0dWFsbHkgaXM/PC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9Mz5GaXJzdCwgaXQgc2VlbXMgYXMgdGhvdWdoIG1vc3QgYWxs IG9mIHRoZSBjb250ZW50IGluIHRoZQ0KdGV4dCB5b3UndmUgc3VibWl0dGVkIHNpbXBseSBkZXNj cmliZXMgd2h5IGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbiBpbg0KZ2VuZXJhbCBpcyBhIGdvb2Qg dGhpbmcgLSB1c2VyIHJlZ2lzdHJhdGlvbiBhdCB0aGUgdXNlcidzICZxdW90O2hvbWUmcXVvdDsN CmlkZW50aXR5IHByb3ZpZGVyLCBiZXR0ZXIgdXNlciBleHBlcmllbmNlLCBldGMuIEluIHlvdXIg Y2FzZSwgdGhlIG1vYmlsZQ0KbmV0d29yayBvcGVyYXRvciBpcyB0aGUgSWRQLCBidXQgdGhleSB3 b3VsZCBiZSBhIGhvbWUgb3JnYW5pc2F0aW9uIHRvIHNvbWUNCnVzZXJzIGFuZCBjb25zZXF1ZW50 bHkgYW4gSWRQLCBqdXN0IGxpa2UgYW55IG90aGVyIG9yZ2FuaXNhdGlvbiBwZXJmb3JtaW5nDQp0 aGUgc2FtZSB0YXNrLiBJJ20gbm90IGFyZ3VpbmcgdGhhdCB5b3UncmUgbm90IHJpZ2h0IGFib3V0 IGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbg0KYmVpbmcgYSBnb29kIHRoaW5nIC0gYnV0IHRoYXQn cyBub3QgdGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zIGNvbG9yPWJsdWU+WWlueGluZyMxJmd0OyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zIGNvbG9yPWJsdWU+Rm9yIHRoZSB0ZXh0ICZxdW90O2J1dCB0aGV5IHdvdWxkIGJl IGEgaG9tZQ0Kb3JnYW5pc2F0aW9uIHRvIHNvbWUgdXNlcnMgYW5kIGNvbnNlcXVlbnRseSBhbiBJ ZFAsIGp1c3QgbGlrZSBhbnkgb3RoZXINCm9yZ2FuaXNhdGlvbiBwZXJmb3JtaW5nIHRoZSBzYW1l IHRhc2suJnF1b3Q7LiBJIGNvdWxkIG5vdCB1bmRlcnN0YW5kIGl0DQp3ZWxsLiBIb3cgZG9lcyBp dCByZWxhdGUgdG8gdGhlIHVzZSBjYXNlPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZT5Gb3IgdGhlIHRleHQgJnF1b3Q7YnV0IHRoYXQncyBub3QgdGhlIHB1cnBvc2UN Cm9mIHRoaXMgZG9jdW1lbnQmcXVvdDssIHRoZSBjbGFyaWZpY2F0aW9uIGlzIGFzIGZvbGxvd3M6 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPigxKSwgRmVkZXJhdGVkIGlkZW50 aXR5IGlzIGluIHRoZSBzY29wZSBvZg0KYWJmYWIgd2csYW5kIHRoZSBjYXNlIGFsc28gc3VwcG9y dHMgbm9uLXdlYiBhcHBsaWNhdGlvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs dWU+KDIpLCBpbiB0aGUgPGk+c2VjdGlvbiAzLiBDb250ZXh0IG9mIFVzZSBDYXNlczwvaT4NCmlu IHRoaXMgZG9jdW1lbnQgKGRyYWZ0LWlldGYtdXNlY2FzZXMtMDEpLCBpdCBzYXlzOiA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PGk+SW4gdGhlIGludGVyZXN0IG9mIHByb21v dGluZyB0aGUgZGV2ZWxvcG1lbnQNCm9mIHRlY2hub2xvZ3kgb2YgYnJvYWQ8L2k+PC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjxpPmFwcGxpY2FiaWxpdHksIHRoZSBwcmVzZW50 IGF1dGhvcnMgd2VsY29tZQ0KdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHM8L2k+PC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjxpPmZyb20gb3RoZXIgc2VjdG9ycyBhbmQgY29t bXVuaXRpZXMuPC9pPjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT5U aGlzIGlzIG15IGNvbnNpZGVyYXRpb24gZm9yIHRoZSB1c2UgY2FzZSBvZg0KJm5ic3A7JnF1b3Q7 RmVkZXJhdGVkIENyb3NzLUxheWVyIEFjY2VzcyZxdW90Oy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zPlNlY29uZCwgdGhlIG9uZSB0aGluZyB0aGF0IHNlZW1zIGxpa2UgaXQgY291bGQg YmUgZGlmZmVyZW50DQphdCBmaXJzdCBnbGFuY2UgaW4geW91ciB1c2UgY2FzZSBpcyB0aGF0IHlv dSBoYXZlIGEgbGF5ZXJlZCBhcmNoaXRlY3R1cmUNCndoZXJlIHVzZXJzIGFyZSB1c2luZyBtb2Jp bGUgZGV2aWNlcywgYXR0YWNoaW5nIHRvIHRoZSBuZXR3b3JrIHVzaW5nIHN0YW5kYXJkDQptZWFu cywgYW5kIHRoZW4gcGVyZm9ybWluZyBmZWRlcmF0ZWQgYXV0aGVudGljYXRpb24gZnJvbSB0aGVp ciBkZXZpY2VzLg0KSG93ZXZlciwgSSBkb24ndCBzZWUgaG93IHRoaXMgaXMgZGlmZmVyZW50IGF0 IGFsbCAtIGFwcGxpY2F0aW9ucyB0aGF0IHVzZXJzDQpvbiB0aGVpciBtb2JpbGUgZGV2aWNlcyBh cmUgdXNpbmcgY29udGFjdCB0aGUgaG9tZSBJZFAgKGluIHRoaXMgY2FzZSBpdA0Kc28gaGFwcGVu cyB0aGVpciBob21lIElkUCBpcyBydW4gYnkgdGhlIG5ldHdvcmsgcHJvdmlkZXIpIGFuZCBhdXRo ZW50aWNhdGUNCnRoZSB1c2VyIGJhc2VkIHVwb24gdGhhdC4gVGhhdCdzIHN0YW5kYXJkIGZlZGVy YXRlZCBhdXRoZW50aWNhdGlvbiwganVzdA0KZnJvbSBhIG1vYmlsZSBkZXZpY2UgaW5zdGVhZCBv Ziwgc2F5LCBhIGRlc2t0b3Agb3IgbGFwdG9wLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZT5ZaW54aW5nIzImZ3Q7VGhlIHBvaW50IGlzIHRoYXQgdGhlIG1vYmlsZSBu ZXR3b3JrDQppbmZyYXN0cnVjdHVyZSBoYXMgYWxyZWFkeSBoYWQgc2VjdXJpdHkgY2FwYWJpbGl0 aWVzIChlLmcuIGF1dGhlbnRpY2F0aW9uLA0KaW50ZWdyaXR5IGFuZCBjb25maWRlbnRpYWxpdHkg KSB3aGljaCBpcyBtYW5kYXRvcnkgZm9yIHVzZXIgZXF1aXBtZW50IGF0dGFja2VkDQp0byBuZXR3 b3JrLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij5BcHBsaWNhdGlvbiBjYW4gbWFrZSB1c2UNCm9mIHRoaXMgY2FwYWJpbGl0eSB3aXRob3V0IGR1 cGxpY2F0aW5nIHRoZSBzaW1pbGFyIHRhc2sgZG9uZSBpbiBuZXR3b3JrDQpsYXllci4gQXMgdG8g ZGVza3RvcCBvciBsYXB0b3AsIHdoZW4gdGhleSBjb25uZWN0IHRvIHRoZSBuZXR3b3JrLCB0aGUg YXV0aGVudGljYXRpb24NCmlzIHBlcmZvcm1lZCBpbiBvdGhlciB3YXkgcHJvdmlkZWQgYnkgbmV0 d29yayBvcGVyYXRvcnMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5JIHRoaW5rIHRo ZXJlJ3MgYSBnb29kIGFyZ3VtZW50IGluIHRoZXJlIHRoYXQgbW9iaWxlIHRlbGVjb21zDQpwcm92 aWRlcnMgbWlnaHQgbWFrZSBhIGdvb2QgY2xhc3Mgb2YgSWRQLCBidXQgdW5mb3J0dW5hdGVseSB0 aGF0J3Mgbm90DQphcHBsaWNhYmxlIHRvIHRoaXMgZG9jdW1lbnQsIEkgZG9uJ3QgdGhpbmsuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPllpbnhpbmcjMyZndDtyZWZl ciB0byB0aGUgcmVwbHkgaW4gWWlueGluZyMxJmd0OzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTM+VGhlIGtleSB0aGluZyBpcyB0aGF0IEkgZG9uJ3Qgc2VlIGFueSBuZXcgcGFydGljdWxh ciBhcHBsaWNhdGlvbnMNCm9yIHVzZSBjYXNlcyBmb3IgZmVkZXJhdGVkIGF1dGhlbnRpY2F0aW9u IGluIHlvdXIgdGV4dCwganVzdCBhIHNvIEknbSBzdHJ1Z2dsaW5nDQp0byBzZWUgaG93LCBvciBp ZiwgaXQgZml0cyBpbnRvIHRoZSB1c2UgY2FzZSBkb2N1bWVudC48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zPllpbnhpbmcgLSBJZiB5b3UgdGhpbmsgSSdtIG1pc3VuZGVyc3RhbmRpbmcg eW91ciB1c2UgY2FzZSwNCnBsZWFzZSBkbyBnZXQgYmFjayBpbiB0b3VjaCBhbmQgd2UgY2FuIHRy eSB0byBmaWd1cmUgb3V0IHdoYXQgaXQgaXMgYW5kDQpob3cgaXQgZml0cyBpbnRvIHRoZSBkb2N1 bWVudC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkV2ZXJ5b25lIGVsc2UgLSBJZiBh bnlvbmUgZGlzYWdyZWVzIHdpdGggdGhpcyAoaWYgSSdtDQptaXNzaW5nIHNvbWV0aGluZyBvYnZp b3VzIGhlcmUpLCB0aGVuIHBsZWFzZSBsZXQgbWUga25vdyB3aGVyZSBJJ20gZ29pbmcNCndyb25n Li4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5SLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTM+LS08YnI+DQpEciBSaHlzIFNtaXRoOiBJZGVudGl0eSwgQWNjZXNzLCBhbmQgTWlkZGxl d2FyZSBTcGVjaWFsaXN0PGJyPg0KQ2FyZGlmZiBVbml2ZXJzaXR5ICZhbXA7IEpBTkVUKFVLKTxi cj4NCjxicj4NCmVtYWlsOiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86c21pdGhAY2FyZGlmZi5hYy51 az48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5zbWl0aEBjYXJkaWZmLmFjLnVrPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0zPg0KLyA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cmh5cy5zbWl0aEBq YS5uZXQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+cmh5cy5zbWl0aEBqYS5uZXQ8L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KR1BHOiAweERFMkYwMjRDPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9Mz5PbiAyIEF1ZyAyMDExLCBhdCAyMDo1MywgPC9mb250PjxhIGhyZWY9 bWFpbHRvOndlaS55aW54aW5nQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+ d2VpLnlpbnhpbmdAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4NCndyb3Rl OjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K RGVhciBSaHlzIFNtaXRoLCA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQWNjb3JkaW5nIHRvIHRoZSBhY3Rpb24gaW4g SUVURiM4MSwgSSBzdW1tYXJpemVkIHRoZSB1c2UgY2FzZSBpbiA8YnI+DQpkcmFmdC13ZWktYWJm YWItZmNsYS0wMCBhcyBhbiBpbnB1dCB0byBkcmFmdC1pZXRmLWFiZmFiLXVzZWNhc2VzLTAxLiA8 YnI+DQpQbGVhc2UgcmV2aWV3IGl0LjwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KVGhhbmtzITwvZm9udD48Zm9udCBz aXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K WWlueGluZyBXZWkgPC9mb250Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+PC9mb250Pjxmb250IHNpemU9 Mz4NCjwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0KNC54LiBGZWRlcmF0ZWQgQ3Jvc3MtTGF5ZXIg QWNjZXNzPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9Mj48YnI+ DQogJm5ic3A7IFRlbGVjb20gb3BlcmF0b3JzIGhhdmUgYSBjb21tdW5pY2F0aW9uIG5ldHdvcmsg aW5mcmFzdHJ1Y3R1cmVzDQp0bzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXpl PTI+PGJyPg0KICZuYnNwOyBwcm92aWRlciB1c2VycyB3aXRoIGEgd2VhbHRoeSBvZiBhY2Nlc3Mg bWV0aG9kcy4gVGVsZWNvbSBvcGVyYXRvcnM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxm b250IHNpemU9Mj48YnI+DQogJm5ic3A7IGhhdmUgYSBodWdlIG51bWJlciBvZiByZWdpc3RlcmVk IHVzZXJzLCBhbmQgdGhleSBjYW4gcHJvdmlkZSB0cnVzdGVkPC9mb250Pjxmb250IHNpemU9Mz4N CjwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0KICZuYnNwOyBpZGVudGl0eSBhbmQgaGlnaGVyIHNl Y3VyaXR5LiBUaGVyZWZvcmUgdGhleSBoYXZlIGEgbmF0dXJhbCBhZHZhbnRhZ2U8L2ZvbnQ+PGZv bnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9Mj48YnI+DQogJm5ic3A7IHRvIGFjdCBhcyBh biBJZGVudGl0eSBQcm92aWRlciAoSWRQKSB0byBzZXJ2ZSBmb3Igc2VydmljZSBwcm92aWRlcnMu PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0KICZuYnNwOyBP biB0aGUgY29udHJhcnkgbW9zdCBzZXJ2aWNlIHByb3ZpZGVycyBvbiB0aGUgSW50ZXJuZXQgaGF2 ZSBsaW1pdGVkPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0K ICZuYnNwOyBhbW91bnQgb2YgdXNlcnMgYW5kIGNhbiBub3QgYXNzdXJlIHRoZSBzZWN1cml0eSBv ZiB1c2VyIGlkZW50aXR5LA0KYnV0PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNp emU9Mj48YnI+DQogJm5ic3A7IHRoZXkgY2FuIHByb3ZpZGUgYWJ1bmRhbnQga2luZHMgb2Ygc2Vy dmljZS4gRnVydGhlcm1vcmUsIHVzZXIgaXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxm b250IHNpemU9Mj48YnI+DQogJm5ic3A7IHJlbHVjdGFudCB0byByZWdpc3RlciB0b28gbWFueSBh Y2NvdW50cyBiZWNhdXNlIGl0IGlzIGluY29udmVuaWVudA0KdG88L2ZvbnQ+PGZvbnQgc2l6ZT0z PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxicj4NCiAmbmJzcDsgcmVtZW1iZXIgZG96ZW5zIG9mIHBh c3N3b3Jkcy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxi cj4NCiAmbmJzcDsgVGVsZWNvbSBuZXR3b3JrIHN1cHBvcnRzIFdlYiBvciBub24tV2ViIGFwcGxp Y2F0aW9uLiAmbmJzcDtJbiBzb21lDQpjYXNlczwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48 Zm9udCBzaXplPTI+PGJyPg0KICZuYnNwOyB1c2VyIHByZWZlcnMgdG8gY2hvb3NlIG5vbi1XZWIg YXBwbGljYXRpb24sIGUuZy4gJm5ic3A7TWVzc2FnaW5nDQpzZXJ2aWNlLDwvZm9udD48Zm9udCBz aXplPTM+IDwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0KICZuYnNwOyBWb0lQLCBFTWFpbCBzZXJ2 aWNlLCBldGMuIEJhc2VkIG9uIHRoZSByZXN1bHQgb2YgbmV0d29yayBzdHJhdHVtPC9mb250Pjxm b250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0KICZuYnNwOyBhdXRoZW50aWNh dGlvbiBhbmQgYXV0aG9yaXphdGlvbiwgVXNlciBlcXVpcG1lbnQgKFVFKSBjYW4gYWNjZXNzPC9m b250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0KICZuYnNwOyBhcHBs aWNhdGlvbnMgd2l0aG91dCBkb2luZyBhbm90aGVyIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3Jp emF0aW9uDQo8YnI+DQogJm5ic3A7IHByb2NlZHVyZS4gSW4gdGhpcyB3YXksIHRoZSBzeXN0ZW0g Y2FuIGltcGxlbWVudCBmZWRlcmF0ZWQgY3Jvc3MtbGF5ZXI8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0K PC9mb250Pjxmb250IHNpemU9Mj48YnI+DQogJm5ic3A7IGFjY2Vzcy4gRmlyc3RseSBtdXR1YWwg YXV0aGVudGljYXRpb24gaXMgcGVyZm9ybWVkIGJldHdlZW4gVUUgYW5kDQo8YnI+DQogJm5ic3A7 IE5ldHdvcmssIHNlY29uZGx5IFVFIGFjY2Vzc2VzIEFwcGxpY2F0aW9uIGJhc2VkIG9uIHRoZSBy ZXN1bHQgb2YNCjxicj4NCiAmbmJzcDsgbmV0d29yayBzdHJhdHVtJ3MgYXV0aGVudGljYXRpb24u IEluIHRoaXMgY2FzZSwgYSBmZWRlcmF0aW9uIGlzDQpmb3JtZWQ8L2ZvbnQ+PGZvbnQgc2l6ZT0z PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxicj4NCiAmbmJzcDsgYmV0d2VlbiBOZXR3b3JrIGFuZCBB cHBsaWNhdGlvbi4gVGhlIGJyaWVmIHN0ZXBzIGFyZSBhcyBmb2xsb3dzOjwvZm9udD48Zm9udCBz aXplPTM+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxicj4NCiAmbmJzcDsgMS4gJm5ic3A7 V2hlbiBVRSBhdHRhY2hlcyB0aGUgTmV0d29yaywgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGlzDQpw ZXJmb3JtZWQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyBtYXN0ZXIgc2Vzc2lvbiBrZXkgaXMgY3JlYXRlZCBiZXR3ZWVu IHRoZW0uPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0KICZu YnNwOyAyLiAmbmJzcDtVRSB2aXNpdHMgbm9uLVdlYiBBcHBsaWNhdGlvbiwgZS5nIE1lc3NhZ2lu ZyBzZXJ2aWNlLA0KVm9JUDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTI+ PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNlcnZpY2UsIG9yIEVtYWlsIHNlcnZpY2UuPC9m b250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9Mj48YnI+DQogJm5ic3A7IDMuICZu YnNwO0FwcGxpY2F0aW9uIGhhcyBubyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgVUUuICZuYnNwO1Ro ZQ0KQXBwbGljYXRpb248L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb250YWN0cyBOZXR3b3JrIHRvIHZhbGlkYXRlIHRo ZSBhdXRoZW50aWNhdGlvbiByZXN1bHQNCmluIHRoZTwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9u dD48Zm9udCBzaXplPTI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IG5ldHdvcmsgc3RyYXR1 bS4gJm5ic3A7QXBwbGljYXRpb24gY2FuIGZpbmQgTmV0d29yaw0KYWNjb3JkaW5nIHRvIHRoZTwv Zm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0KICZuYnNwOyAmbmJz cDsgJm5ic3A7IGNvbmZpZ3VyYXRpb24gb3IgZHluYW1pY2FsIGRpc2NvdmVyeSBwcm90b2NvbC48 L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9Mj48YnI+DQogJm5ic3A7IDQu ICZuYnNwO05ldHdvcmsgcmVzcG9uZHMgdG8gQXBwbGljYXRpb24gd2l0aCBhdXRoZW50aWNhdGlv biByZXN1bHQuPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0K ICZuYnNwOyA1LiAmbmJzcDtVRSBpcyBhdXRob3JpemVkIHRvIGFjY2VzcyB0aGUgQXBwbGljYXRp b24uPC9mb250Pjxmb250IHNpemU9Mz4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0K ICZuYnNwOyBGb3IgZmVkZXJhdGVkIGNyb3NzLWxheWVyIGFjY2VzcywgTmV0d29yayBjYW4gYXNz dXJlIHRoZSBBcHBsaWNhdGlvbjwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yPjxicj4NCiAmbmJzcDsgb2YgdGhlIGF1dGhlbnRpY2l0eSBvZiB1c2VyJ3MgaWRlbnRpdHks IHNoYXJlIHNvbWUgb2YgdXNlIHByb2ZpbGU8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxm b250IHNpemU9Mj48YnI+DQogJm5ic3A7IHdpdGggQXBwbGljYXRpb24uICZuYnNwO1RoZXNlIGNh biBicmluZyBzb21lIGJlbmVmaXRzIHRvIHN0YWtlaG9sZGVyczo8L2ZvbnQ+PGZvbnQgc2l6ZT0z Pg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9Mj48YnI+DQogJm5ic3A7IG8gJm5ic3A7Rm9yIHRl bGVjb20gb3BlcmF0b3JzLCB0aGV5IGNhbiBwcm92aWRlIGlkZW50aXR5IHNlcnZpY2UsDQp0cnVz dGVkPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9Mj48YnI+DQogJm5ic3A7 ICZuYnNwOyAmbmJzcDtzZWN1cml0eSBzZXJ2aWNlLCBtb2JpbGUgcGF5bWVudCBzZXJ2aWNlIGFu ZCBzaGFyaW5nDQpzb21lIHVzZXI8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO3Byb2ZpbGVzIGFjY29yZGluZyB1c2VyJ3Mg cHJlZmVyZW5jZXMuIFRlbGVjb20gb3BlcmF0b3JzDQppcyBub3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0z PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2p1c3QgcHJv dmlkaW5nIHBpcGVsaW5lIGZvciBjb21tdW5pY2F0aW9uLCBidXQgYWxzbw0KYmVjb21lIGEgcGFy dCBvZjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0KICZuYnNw OyAmbmJzcDsgJm5ic3A7c2VydmljZSB2YWx1ZSBjaGFpbiBhcyBhbiBJZGVudGl0eSBQcm92aWRl ci48L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9Mj48YnI+DQogJm5ic3A7 IG8gJm5ic3A7Rm9yIHNlcnZpY2UgcHJvdmlkZXJzLCAmbmJzcDt0aGV5IGNhbiBmb2N1cyBvbiBj b3JlIGJ1c2luZXNzDQphbmQgcmV1c2U8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2NhcGFiaWxpdGllcyBwcm92aWRlZCBi eSB0ZWxlY29tIG9wZXJhdG9ycyB3aXRob3V0DQp3b3JyeWluZyBhYm91dDwvZm9udD48Zm9udCBz aXplPTM+IDwvZm9udD48Zm9udCBzaXplPTI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7c291 cmNlcyBvZiB1c2Vycy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxi cj4NCiAmbmJzcDsgbyAmbmJzcDtGb3IgZW5kIHVzZXJzLCB0aGV5IGNhbiBlbmpveSBzZWFtbGVz cyBzZXJ2aWNlIGV4cGVyaWVuY2VzDQphbmQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZv bnQgc2l6ZT0yPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2ltcHJvdmUgc2VjdXJpdHkgYW5k IHByaXZhY3kuPC9mb250Pjxmb250IHNpemU9Mz4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0Kfn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz48dHQ+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbA0KaXMgc29sZWx5IHByb3BlcnR5 IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQpp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNv bnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NClRoaXMgZW1haWwg YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGlu dGVuZGVkDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdob20gdGhleSBhcmUgYWRkcmVzc2VkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mDQp0aGUgbWVzc2FnZS4g QW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRp dmlkdWFsDQpzZW5kZXIuPGJyPg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPGJyPg0KPC90dD48L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3Vy aXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVk Jm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJv cGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZu YnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlk ZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5i c3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQm bmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5i c3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9u Jm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkm bmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5i c3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtm b3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJz cDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJz cDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJz cDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90 aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2Fn ZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVl biZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZu YnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 000FA2D248257933_=-- From hannes.tschofenig@gmx.net Mon Oct 24 00:08:10 2011 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 6C9411F0C3D for ; Mon, 24 Oct 2011 00:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.5 X-Spam-Level: X-Spam-Status: No, score=-101.5 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+OeN3fYukQM for ; Mon, 24 Oct 2011 00:08:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2C01C1F0C34 for ; Mon, 24 Oct 2011 00:08:05 -0700 (PDT) Received: (qmail invoked by alias); 24 Oct 2011 07:08:04 -0000 Received: from unknown (EHLO [10.255.133.75]) [192.100.123.77] by mail.gmx.net (mp060) with SMTP; 24 Oct 2011 09:08:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18fikosw1MftjRJx3PB7YQSJV8N0KsDfOGomALAAX T3XLD3pblrf1Ka Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <218238C4-8067-469A-8D16-81466B755C1A@cardiff.ac.uk> Date: Mon, 24 Oct 2011 10:07:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <218238C4-8067-469A-8D16-81466B755C1A@cardiff.ac.uk> To: Rhys Smith X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: hartmans-ietf@mit.edu, kwiereng@cisco.com, abfab@ietf.org Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" 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, 24 Oct 2011 07:08:10 -0000 I had a look at http://tools.ietf.org/html/draft-wei-abfab-fcla-00 and = was wondering what specifically needs to be addressed in ABFAB to make = use of the existing telecommunication subscriber infrastructure. I = believe everything is supported already. EAP is used in ABFAB (within the GSS-API) and that allows any = authentication mechanisms to be used, including the AKA. That isn't a = problem.=20 If you don't want to use AKA directly within EAP but add an additional = GBA run beforehand you can do that as well. So, Yinxing could you explain what additional functionality is need?=20 Ciao Hannes On Oct 22, 2011, at 10:51 PM, Rhys Smith wrote: > Hi Yinxing, (cc:ed to abfab list for discussion). >=20 > I'm just looking at making the next version of the use case document = for ABFAB, and so I've been looking at the use case you suggested = (below, if you don't have a copy of the original message sent to the = abfab list). >=20 > Basically, I've reviewed the suggestion and I'm not quite sure what = the use case actually is? >=20 > First, it seems as though most all of the content in the text you've = submitted simply describes why federated authentication in general is a = good thing - user registration at the user's "home" identity provider, = better user experience, etc. In your case, the mobile network operator = is the IdP, but they would be a home organisation to some users and = consequently an IdP, just like any other organisation performing the = same task. I'm not arguing that you're not right about federated = authentication being a good thing - but that's not the purpose of this = document. >=20 > Second, the one thing that seems like it could be different at first = glance in your use case is that you have a layered architecture where = users are using mobile devices, attaching to the network using standard = means, and then performing federated authentication from their devices. = However, I don't see how this is different at all - applications that = users on their mobile devices are using contact the home IdP (in this = case it so happens their home IdP is run by the network provider) and = authenticate the user based upon that. That's standard federated = authentication, just from a mobile device instead of, say, a desktop or = laptop. >=20 > I think there's a good argument in there that mobile telecoms = providers might make a good class of IdP, but unfortunately that's not = applicable to this document, I don't think. >=20 > The key thing is that I don't see any new particular applications or = use cases for federated authentication in your text, just a so I'm = struggling to see how, or if, it fits into the use case document. >=20 > Yinxing - If you think I'm misunderstanding your use case, please do = get back in touch and we can try to figure out what it is and how it = fits into the document. >=20 > Everyone else - If anyone disagrees with this (if I'm missing = something obvious here), then please let me know where I'm going = wrong... >=20 > R. > -- > Dr Rhys Smith: Identity, Access, and Middleware Specialist > Cardiff University & JANET(UK) >=20 > email: smith@cardiff.ac.uk / rhys.smith@ja.net > GPG: 0xDE2F024C >=20 > On 2 Aug 2011, at 20:53, wei.yinxing@zte.com.cn wrote: >=20 >>=20 >> Dear Rhys Smith,=20 >>=20 >> According to the action in IETF#81, I summarized the use case in=20 >> draft-wei-abfab-fcla-00 as an input to draft-ietf-abfab-usecases-01.=20= >> Please review it.=20 >>=20 >> Thanks!=20 >>=20 >> Yinxing Wei=20 >>=20 >> = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=20= >> 4.x. Federated Cross-Layer Access=20 >>=20 >> Telecom operators have a communication network infrastructures to=20= >> provider users with a wealthy of access methods. Telecom operators=20= >> have a huge number of registered users, and they can provide = trusted=20 >> identity and higher security. Therefore they have a natural = advantage=20 >> to act as an Identity Provider (IdP) to serve for service = providers.=20 >> On the contrary most service providers on the Internet have = limited=20 >> amount of users and can not assure the security of user identity, = but=20 >> they can provide abundant kinds of service. Furthermore, user is=20= >> reluctant to register too many accounts because it is inconvenient = to=20 >> remember dozens of passwords.=20 >>=20 >> Telecom network supports Web or non-Web application. In some = cases=20 >> user prefers to choose non-Web application, e.g. Messaging = service,=20 >> VoIP, EMail service, etc. Based on the result of network stratum=20= >> authentication and authorization, User equipment (UE) can access=20= >> applications without doing another authentication and = authorization=20 >> procedure. In this way, the system can implement federated = cross-layer=20 >> access. Firstly mutual authentication is performed between UE and=20= >> Network, secondly UE accesses Application based on the result of=20= >> network stratum's authentication. In this case, a federation is = formed=20 >> between Network and Application. The brief steps are as follows:=20= >>=20 >> 1. When UE attaches the Network, mutual authentication is = performed=20 >> master session key is created between them.=20 >> 2. UE visits non-Web Application, e.g Messaging service, VoIP=20 >> service, or Email service.=20 >> 3. Application has no information about the UE. The Application=20= >> contacts Network to validate the authentication result in the=20= >> network stratum. Application can find Network according to = the=20 >> configuration or dynamical discovery protocol.=20 >> 4. Network responds to Application with authentication result.=20 >> 5. UE is authorized to access the Application.=20 >>=20 >> For federated cross-layer access, Network can assure the = Application=20 >> of the authenticity of user's identity, share some of use profile=20= >> with Application. These can bring some benefits to stakeholders:=20= >>=20 >> o For telecom operators, they can provide identity service, = trusted=20 >> security service, mobile payment service and sharing some user=20= >> profiles according user's preferences. Telecom operators is not=20= >> just providing pipeline for communication, but also become a = part of=20 >> service value chain as an Identity Provider.=20 >> o For service providers, they can focus on core business and = reuse=20 >> capabilities provided by telecom operators without worrying = about=20 >> sources of users.=20 >> o For end users, they can enjoy seamless service experiences and=20= >> improve security and privacy.=20 >>=20 >> = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~ >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. >> This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. >>=20 >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From wei.yinxing@zte.com.cn Mon Oct 24 00:30:05 2011 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 70B7521F8B8F for ; Mon, 24 Oct 2011 00:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRVl8YusSSWn for ; Mon, 24 Oct 2011 00:30:04 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0024F21F8B88 for ; Mon, 24 Oct 2011 00:30:02 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 41713967931198; Mon, 24 Oct 2011 15:26:40 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 20387.3921463883; Mon, 24 Oct 2011 15:23:23 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p9O7NBMN013439; Mon, 24 Oct 2011 15:23:11 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: To: Hannes Tschofenig MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Mon, 24 Oct 2011 15:22:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-24 15:23:13, Serialize complete at 2011-10-24 15:23:13 Content-Type: multipart/alternative; boundary="=_alternative 0028939148257933_=" X-MAIL: mse01.zte.com.cn p9O7NBMN013439 Cc: kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" 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, 24 Oct 2011 07:30:05 -0000 This is a multipart message in MIME format. --=_alternative 0028939148257933_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIEhhbm5lcw0KDQogSSB0aGluayB5b3UgaGF2ZSBhbHJlYWR5IGV4cGxhaW5lZCBpdCBjbGVh cmx5LiBDdXJyZW50IG1lY2hhbmlzbXMsIHN1Y2ggDQphcyBFQVAsIEdTUy1BUEksIFNBTUwsIEFB QShSYWRpdXMvRGlhbWV0ZXIpIGFyZSBlbm91Z2ggZm9yIHRoaXMgdXNlIGNhc2UuIA0KRm9yIG1l LCBUaGUgbmV4dCBzdGVwIGlzIHRvIG1ha2UgdXNlIG9mIGV4aXN0aW5nIHRvb2xzIGRlZmluZWQg aW4gYWJmYWIgdG8gDQpzdXBwb3J0IHRoaXMgdXNlIGNhc2UuIA0KDQotLS0tLS0tDQpZaW54aW5n DQoNCg0KDQpIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4gDQoy MDExLzEwLzI0IDE1OjA3DQoNCsrVvP7Iyw0KUmh5cyBTbWl0aCA8c21pdGhAQ0FSRElGRi5BQy5V Sz4NCrOty80NCkhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Piwg d2VpLnlpbnhpbmdAenRlLmNvbS5jbiwgDQprd2llcmVuZ0BjaXNjby5jb20sIGFiZmFiQGlldGYu b3JnLCBoYXJ0bWFucy1pZXRmQG1pdC5lZHUNCtb3zOINClJlOiBbYWJmYWJdIFBsZWFzZSByZXZp ZXcgdGhlIHVzZSBjYXNlICI0LnggRmVkZXJhdGVkIENyb3NzLUxheWVyIEFjY2VzcyINCg0KDQoN Cg0KDQoNCkkgaGFkIGEgbG9vayBhdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13 ZWktYWJmYWItZmNsYS0wMCBhbmQgd2FzIA0Kd29uZGVyaW5nIHdoYXQgc3BlY2lmaWNhbGx5IG5l ZWRzIHRvIGJlIGFkZHJlc3NlZCBpbiBBQkZBQiB0byBtYWtlIHVzZSBvZiANCnRoZSBleGlzdGlu ZyB0ZWxlY29tbXVuaWNhdGlvbiBzdWJzY3JpYmVyIGluZnJhc3RydWN0dXJlLiBJIGJlbGlldmUg DQpldmVyeXRoaW5nIGlzIHN1cHBvcnRlZCBhbHJlYWR5Lg0KDQpFQVAgaXMgdXNlZCBpbiBBQkZB QiAod2l0aGluIHRoZSBHU1MtQVBJKSBhbmQgdGhhdCBhbGxvd3MgYW55IA0KYXV0aGVudGljYXRp b24gbWVjaGFuaXNtcyB0byBiZSB1c2VkLCBpbmNsdWRpbmcgdGhlIEFLQS4gVGhhdCBpc24ndCBh IA0KcHJvYmxlbS4gDQoNCklmIHlvdSBkb24ndCB3YW50IHRvIHVzZSBBS0EgZGlyZWN0bHkgd2l0 aGluIEVBUCBidXQgYWRkIGFuIGFkZGl0aW9uYWwgR0JBIA0KcnVuIGJlZm9yZWhhbmQgeW91IGNh biBkbyB0aGF0IGFzIHdlbGwuDQoNClNvLCBZaW54aW5nIGNvdWxkIHlvdSBleHBsYWluIHdoYXQg YWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IGlzIG5lZWQ/IA0KDQpDaWFvDQpIYW5uZXMNCg0KT24g T2N0IDIyLCAyMDExLCBhdCAxMDo1MSBQTSwgUmh5cyBTbWl0aCB3cm90ZToNCg0KPiBIaSBZaW54 aW5nLCAoY2M6ZWQgdG8gYWJmYWIgbGlzdCBmb3IgZGlzY3Vzc2lvbikuDQo+IA0KPiBJJ20ganVz dCBsb29raW5nIGF0IG1ha2luZyB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSB1c2UgY2FzZSBkb2N1 bWVudCBmb3IgDQpBQkZBQiwgYW5kIHNvIEkndmUgYmVlbiBsb29raW5nIGF0IHRoZSB1c2UgY2Fz ZSB5b3Ugc3VnZ2VzdGVkIChiZWxvdywgaWYgDQp5b3UgZG9uJ3QgaGF2ZSBhIGNvcHkgb2YgdGhl IG9yaWdpbmFsIG1lc3NhZ2Ugc2VudCB0byB0aGUgYWJmYWIgbGlzdCkuDQo+IA0KPiBCYXNpY2Fs bHksIEkndmUgcmV2aWV3ZWQgdGhlIHN1Z2dlc3Rpb24gYW5kIEknbSBub3QgcXVpdGUgc3VyZSB3 aGF0IHRoZSANCnVzZSBjYXNlIGFjdHVhbGx5IGlzPw0KPiANCj4gRmlyc3QsIGl0IHNlZW1zIGFz IHRob3VnaCBtb3N0IGFsbCBvZiB0aGUgY29udGVudCBpbiB0aGUgdGV4dCB5b3UndmUgDQpzdWJt aXR0ZWQgc2ltcGx5IGRlc2NyaWJlcyB3aHkgZmVkZXJhdGVkIGF1dGhlbnRpY2F0aW9uIGluIGdl bmVyYWwgaXMgYSANCmdvb2QgdGhpbmcgLSB1c2VyIHJlZ2lzdHJhdGlvbiBhdCB0aGUgdXNlcidz ICJob21lIiBpZGVudGl0eSBwcm92aWRlciwgDQpiZXR0ZXIgdXNlciBleHBlcmllbmNlLCBldGMu IEluIHlvdXIgY2FzZSwgdGhlIG1vYmlsZSBuZXR3b3JrIG9wZXJhdG9yIGlzIA0KdGhlIElkUCwg YnV0IHRoZXkgd291bGQgYmUgYSBob21lIG9yZ2FuaXNhdGlvbiB0byBzb21lIHVzZXJzIGFuZCAN CmNvbnNlcXVlbnRseSBhbiBJZFAsIGp1c3QgbGlrZSBhbnkgb3RoZXIgb3JnYW5pc2F0aW9uIHBl cmZvcm1pbmcgdGhlIHNhbWUgDQp0YXNrLiBJJ20gbm90IGFyZ3VpbmcgdGhhdCB5b3UncmUgbm90 IHJpZ2h0IGFib3V0IGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbiANCmJlaW5nIGEgZ29vZCB0aGlu ZyAtIGJ1dCB0aGF0J3Mgbm90IHRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBT ZWNvbmQsIHRoZSBvbmUgdGhpbmcgdGhhdCBzZWVtcyBsaWtlIGl0IGNvdWxkIGJlIGRpZmZlcmVu dCBhdCBmaXJzdCANCmdsYW5jZSBpbiB5b3VyIHVzZSBjYXNlIGlzIHRoYXQgeW91IGhhdmUgYSBs YXllcmVkIGFyY2hpdGVjdHVyZSB3aGVyZSANCnVzZXJzIGFyZSB1c2luZyBtb2JpbGUgZGV2aWNl cywgYXR0YWNoaW5nIHRvIHRoZSBuZXR3b3JrIHVzaW5nIHN0YW5kYXJkIA0KbWVhbnMsIGFuZCB0 aGVuIHBlcmZvcm1pbmcgZmVkZXJhdGVkIGF1dGhlbnRpY2F0aW9uIGZyb20gdGhlaXIgZGV2aWNl cy4gDQpIb3dldmVyLCBJIGRvbid0IHNlZSBob3cgdGhpcyBpcyBkaWZmZXJlbnQgYXQgYWxsIC0g YXBwbGljYXRpb25zIHRoYXQgDQp1c2VycyBvbiB0aGVpciBtb2JpbGUgZGV2aWNlcyBhcmUgdXNp bmcgY29udGFjdCB0aGUgaG9tZSBJZFAgKGluIHRoaXMgY2FzZSANCml0IHNvIGhhcHBlbnMgdGhl aXIgaG9tZSBJZFAgaXMgcnVuIGJ5IHRoZSBuZXR3b3JrIHByb3ZpZGVyKSBhbmQgDQphdXRoZW50 aWNhdGUgdGhlIHVzZXIgYmFzZWQgdXBvbiB0aGF0LiBUaGF0J3Mgc3RhbmRhcmQgZmVkZXJhdGVk IA0KYXV0aGVudGljYXRpb24sIGp1c3QgZnJvbSBhIG1vYmlsZSBkZXZpY2UgaW5zdGVhZCBvZiwg c2F5LCBhIGRlc2t0b3Agb3IgDQpsYXB0b3AuDQo+IA0KPiBJIHRoaW5rIHRoZXJlJ3MgYSBnb29k IGFyZ3VtZW50IGluIHRoZXJlIHRoYXQgbW9iaWxlIHRlbGVjb21zIHByb3ZpZGVycyANCm1pZ2h0 IG1ha2UgYSBnb29kIGNsYXNzIG9mIElkUCwgYnV0IHVuZm9ydHVuYXRlbHkgdGhhdCdzIG5vdCBh cHBsaWNhYmxlIHRvIA0KdGhpcyBkb2N1bWVudCwgSSBkb24ndCB0aGluay4NCj4gDQo+IFRoZSBr ZXkgdGhpbmcgaXMgdGhhdCBJIGRvbid0IHNlZSBhbnkgbmV3IHBhcnRpY3VsYXIgYXBwbGljYXRp b25zIG9yIHVzZSANCmNhc2VzIGZvciBmZWRlcmF0ZWQgYXV0aGVudGljYXRpb24gaW4geW91ciB0 ZXh0LCBqdXN0IGEgc28gSSdtIHN0cnVnZ2xpbmcgDQp0byBzZWUgaG93LCBvciBpZiwgaXQgZml0 cyBpbnRvIHRoZSB1c2UgY2FzZSBkb2N1bWVudC4NCj4gDQo+IFlpbnhpbmcgLSBJZiB5b3UgdGhp bmsgSSdtIG1pc3VuZGVyc3RhbmRpbmcgeW91ciB1c2UgY2FzZSwgcGxlYXNlIGRvIGdldCANCmJh Y2sgaW4gdG91Y2ggYW5kIHdlIGNhbiB0cnkgdG8gZmlndXJlIG91dCB3aGF0IGl0IGlzIGFuZCBo b3cgaXQgZml0cyBpbnRvIA0KdGhlIGRvY3VtZW50Lg0KPiANCj4gRXZlcnlvbmUgZWxzZSAtIElm IGFueW9uZSBkaXNhZ3JlZXMgd2l0aCB0aGlzIChpZiBJJ20gbWlzc2luZyBzb21ldGhpbmcgDQpv YnZpb3VzIGhlcmUpLCB0aGVuIHBsZWFzZSBsZXQgbWUga25vdyB3aGVyZSBJJ20gZ29pbmcgd3Jv bmcuLi4NCj4gDQo+IFIuDQo+IC0tDQo+IERyIFJoeXMgU21pdGg6IElkZW50aXR5LCBBY2Nlc3Ms IGFuZCBNaWRkbGV3YXJlIFNwZWNpYWxpc3QNCj4gQ2FyZGlmZiBVbml2ZXJzaXR5ICYgSkFORVQo VUspDQo+IA0KPiBlbWFpbDogc21pdGhAY2FyZGlmZi5hYy51ayAvIHJoeXMuc21pdGhAamEubmV0 DQo+IEdQRzogMHhERTJGMDI0Qw0KPiANCj4gT24gMiBBdWcgMjAxMSwgYXQgMjA6NTMsIHdlaS55 aW54aW5nQHp0ZS5jb20uY24gd3JvdGU6DQo+IA0KPj4gDQo+PiBEZWFyIFJoeXMgU21pdGgsIA0K Pj4gDQo+PiBBY2NvcmRpbmcgdG8gdGhlIGFjdGlvbiBpbiBJRVRGIzgxLCBJIHN1bW1hcml6ZWQg dGhlIHVzZSBjYXNlIGluIA0KPj4gZHJhZnQtd2VpLWFiZmFiLWZjbGEtMDAgYXMgYW4gaW5wdXQg dG8gZHJhZnQtaWV0Zi1hYmZhYi11c2VjYXNlcy0wMS4gDQo+PiBQbGVhc2UgcmV2aWV3IGl0LiAN Cj4+IA0KPj4gVGhhbmtzISANCj4+IA0KPj4gWWlueGluZyBXZWkgDQo+PiANCj4+IH5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+IA0KDQo+PiA0LnguIEZlZGVyYXRlZCBDcm9zcy1MYXllciBBY2Nlc3MgDQo+PiANCj4+ ICAgIFRlbGVjb20gb3BlcmF0b3JzIGhhdmUgYSBjb21tdW5pY2F0aW9uIG5ldHdvcmsgaW5mcmFz dHJ1Y3R1cmVzIHRvIA0KPj4gICAgcHJvdmlkZXIgdXNlcnMgd2l0aCBhIHdlYWx0aHkgb2YgYWNj ZXNzIG1ldGhvZHMuIFRlbGVjb20gb3BlcmF0b3JzIA0KPj4gICAgaGF2ZSBhIGh1Z2UgbnVtYmVy IG9mIHJlZ2lzdGVyZWQgdXNlcnMsIGFuZCB0aGV5IGNhbiBwcm92aWRlIHRydXN0ZWQgDQoNCj4+ ICAgIGlkZW50aXR5IGFuZCBoaWdoZXIgc2VjdXJpdHkuIFRoZXJlZm9yZSB0aGV5IGhhdmUgYSBu YXR1cmFsIA0KYWR2YW50YWdlIA0KPj4gICAgdG8gYWN0IGFzIGFuIElkZW50aXR5IFByb3ZpZGVy IChJZFApIHRvIHNlcnZlIGZvciBzZXJ2aWNlIHByb3ZpZGVycy4gDQoNCj4+ICAgIE9uIHRoZSBj b250cmFyeSBtb3N0IHNlcnZpY2UgcHJvdmlkZXJzIG9uIHRoZSBJbnRlcm5ldCBoYXZlIGxpbWl0 ZWQgDQo+PiAgICBhbW91bnQgb2YgdXNlcnMgYW5kIGNhbiBub3QgYXNzdXJlIHRoZSBzZWN1cml0 eSBvZiB1c2VyIGlkZW50aXR5LCANCmJ1dCANCj4+ICAgIHRoZXkgY2FuIHByb3ZpZGUgYWJ1bmRh bnQga2luZHMgb2Ygc2VydmljZS4gRnVydGhlcm1vcmUsIHVzZXIgaXMgDQo+PiAgICByZWx1Y3Rh bnQgdG8gcmVnaXN0ZXIgdG9vIG1hbnkgYWNjb3VudHMgYmVjYXVzZSBpdCBpcyBpbmNvbnZlbmll bnQgDQp0byANCj4+ICAgIHJlbWVtYmVyIGRvemVucyBvZiBwYXNzd29yZHMuIA0KPj4gDQo+PiAg ICBUZWxlY29tIG5ldHdvcmsgc3VwcG9ydHMgV2ViIG9yIG5vbi1XZWIgYXBwbGljYXRpb24uICBJ biBzb21lIGNhc2VzIA0KPj4gICAgdXNlciBwcmVmZXJzIHRvIGNob29zZSBub24tV2ViIGFwcGxp Y2F0aW9uLCBlLmcuICBNZXNzYWdpbmcgc2VydmljZSwgDQoNCj4+ICAgIFZvSVAsIEVNYWlsIHNl cnZpY2UsIGV0Yy4gQmFzZWQgb24gdGhlIHJlc3VsdCBvZiBuZXR3b3JrIHN0cmF0dW0gDQo+PiAg ICBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiwgVXNlciBlcXVpcG1lbnQgKFVFKSBj YW4gYWNjZXNzIA0KPj4gICAgYXBwbGljYXRpb25zIHdpdGhvdXQgZG9pbmcgYW5vdGhlciBhdXRo ZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiANCj4+ICAgIHByb2NlZHVyZS4gSW4gdGhpcyB3 YXksIHRoZSBzeXN0ZW0gY2FuIGltcGxlbWVudCBmZWRlcmF0ZWQgDQpjcm9zcy1sYXllciANCj4+ ICAgIGFjY2Vzcy4gRmlyc3RseSBtdXR1YWwgYXV0aGVudGljYXRpb24gaXMgcGVyZm9ybWVkIGJl dHdlZW4gVUUgYW5kIA0KPj4gICAgTmV0d29yaywgc2Vjb25kbHkgVUUgYWNjZXNzZXMgQXBwbGlj YXRpb24gYmFzZWQgb24gdGhlIHJlc3VsdCBvZiANCj4+ICAgIG5ldHdvcmsgc3RyYXR1bSdzIGF1 dGhlbnRpY2F0aW9uLiBJbiB0aGlzIGNhc2UsIGEgZmVkZXJhdGlvbiBpcyANCmZvcm1lZCANCj4+ ICAgIGJldHdlZW4gTmV0d29yayBhbmQgQXBwbGljYXRpb24uIFRoZSBicmllZiBzdGVwcyBhcmUg YXMgZm9sbG93czogDQo+PiANCj4+ICAgIDEuICBXaGVuIFVFIGF0dGFjaGVzIHRoZSBOZXR3b3Jr LCBtdXR1YWwgYXV0aGVudGljYXRpb24gaXMgcGVyZm9ybWVkIA0KDQo+PiAgICAgICAgbWFzdGVy IHNlc3Npb24ga2V5IGlzIGNyZWF0ZWQgYmV0d2VlbiB0aGVtLiANCj4+ICAgIDIuICBVRSB2aXNp dHMgbm9uLVdlYiBBcHBsaWNhdGlvbiwgZS5nIE1lc3NhZ2luZyBzZXJ2aWNlLCBWb0lQIA0KPj4g ICAgICAgIHNlcnZpY2UsIG9yIEVtYWlsIHNlcnZpY2UuIA0KPj4gICAgMy4gIEFwcGxpY2F0aW9u IGhhcyBubyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgVUUuICBUaGUgQXBwbGljYXRpb24gDQo+PiAg ICAgICAgY29udGFjdHMgTmV0d29yayB0byB2YWxpZGF0ZSB0aGUgYXV0aGVudGljYXRpb24gcmVz dWx0IGluIHRoZSANCj4+ICAgICAgICBuZXR3b3JrIHN0cmF0dW0uICBBcHBsaWNhdGlvbiBjYW4g ZmluZCBOZXR3b3JrIGFjY29yZGluZyB0byB0aGUgDQo+PiAgICAgICAgY29uZmlndXJhdGlvbiBv ciBkeW5hbWljYWwgZGlzY292ZXJ5IHByb3RvY29sLiANCj4+ICAgIDQuICBOZXR3b3JrIHJlc3Bv bmRzIHRvIEFwcGxpY2F0aW9uIHdpdGggYXV0aGVudGljYXRpb24gcmVzdWx0LiANCj4+ICAgIDUu ICBVRSBpcyBhdXRob3JpemVkIHRvIGFjY2VzcyB0aGUgQXBwbGljYXRpb24uIA0KPj4gDQo+PiAg ICBGb3IgZmVkZXJhdGVkIGNyb3NzLWxheWVyIGFjY2VzcywgTmV0d29yayBjYW4gYXNzdXJlIHRo ZSBBcHBsaWNhdGlvbiANCg0KPj4gICAgb2YgdGhlIGF1dGhlbnRpY2l0eSBvZiB1c2VyJ3MgaWRl bnRpdHksIHNoYXJlIHNvbWUgb2YgdXNlIHByb2ZpbGUgDQo+PiAgICB3aXRoIEFwcGxpY2F0aW9u LiAgVGhlc2UgY2FuIGJyaW5nIHNvbWUgYmVuZWZpdHMgdG8gc3Rha2Vob2xkZXJzOiANCj4+IA0K Pj4gICAgbyAgRm9yIHRlbGVjb20gb3BlcmF0b3JzLCB0aGV5IGNhbiBwcm92aWRlIGlkZW50aXR5 IHNlcnZpY2UsIHRydXN0ZWQgDQoNCj4+ICAgICAgIHNlY3VyaXR5IHNlcnZpY2UsIG1vYmlsZSBw YXltZW50IHNlcnZpY2UgYW5kIHNoYXJpbmcgc29tZSB1c2VyIA0KPj4gICAgICAgcHJvZmlsZXMg YWNjb3JkaW5nIHVzZXIncyBwcmVmZXJlbmNlcy4gVGVsZWNvbSBvcGVyYXRvcnMgaXMgbm90IA0K Pj4gICAgICAganVzdCBwcm92aWRpbmcgcGlwZWxpbmUgZm9yIGNvbW11bmljYXRpb24sIGJ1dCBh bHNvIGJlY29tZSBhIHBhcnQgDQpvZiANCj4+ICAgICAgIHNlcnZpY2UgdmFsdWUgY2hhaW4gYXMg YW4gSWRlbnRpdHkgUHJvdmlkZXIuIA0KPj4gICAgbyAgRm9yIHNlcnZpY2UgcHJvdmlkZXJzLCAg dGhleSBjYW4gZm9jdXMgb24gY29yZSBidXNpbmVzcyBhbmQgcmV1c2UgDQoNCj4+ICAgICAgIGNh cGFiaWxpdGllcyBwcm92aWRlZCBieSB0ZWxlY29tIG9wZXJhdG9ycyB3aXRob3V0IHdvcnJ5aW5n IGFib3V0IA0KDQo+PiAgICAgICBzb3VyY2VzIG9mIHVzZXJzLiANCj4+ICAgIG8gIEZvciBlbmQg dXNlcnMsIHRoZXkgY2FuIGVuam95IHNlYW1sZXNzIHNlcnZpY2UgZXhwZXJpZW5jZXMgYW5kIA0K Pj4gICAgICAgaW1wcm92ZSBzZWN1cml0eSBhbmQgcHJpdmFjeS4gDQo+PiANCj4+IA0Kfn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgDQppcyBzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24g DQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0 byBtYWludGFpbiBzZWNyZWN5IA0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRo ZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMuDQo+PiBUaGlzIGVt YWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFu ZCANCmludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRp dHkgdG8gd2hvbSB0aGV5IGFyZSANCmFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSANCm9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSANCm9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCj4+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQo+PiANCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFi ZmFiIG1haWxpbmcgbGlzdA0KPiBhYmZhYkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FiZmFiDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMg c29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBj b21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUg b2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRp c2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0028939148257933_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBIYW5uZXM8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO0kgdGhpbmsgeW91 IGhhdmUgYWxyZWFkeSBleHBsYWluZWQNCml0IGNsZWFybHkuIEN1cnJlbnQgbWVjaGFuaXNtcywg c3VjaCBhcyBFQVAsIEdTUy1BUEksIFNBTUwsIEFBQShSYWRpdXMvRGlhbWV0ZXIpDQphcmUgZW5v dWdoIGZvciB0aGlzIHVzZSBjYXNlLiBGb3IgbWUsIFRoZSBuZXh0IHN0ZXAgaXMgdG8gbWFrZSB1 c2Ugb2YgZXhpc3RpbmcNCnRvb2xzIGRlZmluZWQgaW4gYWJmYWIgdG8gc3VwcG9ydCB0aGlzIHVz ZSBjYXNlLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pi0tLS0tLS08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPllpbnhp bmc8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ SGFubmVzIFRzY2hvZmVuaWcgJmx0O2hhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQmZ3Q7PC9iPg0K PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEvMTAvMjQgMTU6 MDc8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+Umh5cyBTbWl0aCAmbHQ7c21pdGhAQ0FSRElGRi5BQy5VSyZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPkhhbm5lcyBUc2Nob2ZlbmlnICZsdDtoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Jmd0OywN CndlaS55aW54aW5nQHp0ZS5jb20uY24sIGt3aWVyZW5nQGNpc2NvLmNvbSwgYWJmYWJAaWV0Zi5v cmcsIGhhcnRtYW5zLWlldGZAbWl0LmVkdTwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFthYmZhYl0g UGxlYXNlIHJldmlldyB0aGUgdXNlIGNhc2UNCiZxdW90OzQueCBGZWRlcmF0ZWQgQ3Jvc3MtTGF5 ZXIgQWNjZXNzJnF1b3Q7PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD5JIGhhZCBhIGxvb2sgYXQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtd2VpLWFiZmFiLWZjbGEtMDANCmFuZCB3YXMgd29uZGVyaW5nIHdoYXQgc3BlY2lm aWNhbGx5IG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBpbiBBQkZBQiB0byBtYWtlDQp1c2Ugb2YgdGhl IGV4aXN0aW5nIHRlbGVjb21tdW5pY2F0aW9uIHN1YnNjcmliZXIgaW5mcmFzdHJ1Y3R1cmUuIEkg YmVsaWV2ZQ0KZXZlcnl0aGluZyBpcyBzdXBwb3J0ZWQgYWxyZWFkeS48YnI+DQo8YnI+DQpFQVAg aXMgdXNlZCBpbiBBQkZBQiAod2l0aGluIHRoZSBHU1MtQVBJKSBhbmQgdGhhdCBhbGxvd3MgYW55 IGF1dGhlbnRpY2F0aW9uDQptZWNoYW5pc21zIHRvIGJlIHVzZWQsIGluY2x1ZGluZyB0aGUgQUtB LiBUaGF0IGlzbid0IGEgcHJvYmxlbS4gPGJyPg0KPGJyPg0KSWYgeW91IGRvbid0IHdhbnQgdG8g dXNlIEFLQSBkaXJlY3RseSB3aXRoaW4gRUFQIGJ1dCBhZGQgYW4gYWRkaXRpb25hbA0KR0JBIHJ1 biBiZWZvcmVoYW5kIHlvdSBjYW4gZG8gdGhhdCBhcyB3ZWxsLjxicj4NCjxicj4NClNvLCBZaW54 aW5nIGNvdWxkIHlvdSBleHBsYWluIHdoYXQgYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IGlzIG5l ZWQ/IDxicj4NCjxicj4NCkNpYW88YnI+DQpIYW5uZXM8YnI+DQo8YnI+DQpPbiBPY3QgMjIsIDIw MTEsIGF0IDEwOjUxIFBNLCBSaHlzIFNtaXRoIHdyb3RlOjxicj4NCjxicj4NCiZndDsgSGkgWWlu eGluZywgKGNjOmVkIHRvIGFiZmFiIGxpc3QgZm9yIGRpc2N1c3Npb24pLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBJJ20ganVzdCBsb29raW5nIGF0IG1ha2luZyB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRo ZSB1c2UgY2FzZSBkb2N1bWVudA0KZm9yIEFCRkFCLCBhbmQgc28gSSd2ZSBiZWVuIGxvb2tpbmcg YXQgdGhlIHVzZSBjYXNlIHlvdSBzdWdnZXN0ZWQgKGJlbG93LA0KaWYgeW91IGRvbid0IGhhdmUg YSBjb3B5IG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlIHNlbnQgdG8gdGhlIGFiZmFiIGxpc3QpLjxi cj4NCiZndDsgPGJyPg0KJmd0OyBCYXNpY2FsbHksIEkndmUgcmV2aWV3ZWQgdGhlIHN1Z2dlc3Rp b24gYW5kIEknbSBub3QgcXVpdGUgc3VyZSB3aGF0DQp0aGUgdXNlIGNhc2UgYWN0dWFsbHkgaXM/ PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZpcnN0LCBpdCBzZWVtcyBhcyB0aG91Z2ggbW9zdCBhbGwg b2YgdGhlIGNvbnRlbnQgaW4gdGhlIHRleHQgeW91J3ZlDQpzdWJtaXR0ZWQgc2ltcGx5IGRlc2Ny aWJlcyB3aHkgZmVkZXJhdGVkIGF1dGhlbnRpY2F0aW9uIGluIGdlbmVyYWwgaXMgYQ0KZ29vZCB0 aGluZyAtIHVzZXIgcmVnaXN0cmF0aW9uIGF0IHRoZSB1c2VyJ3MgJnF1b3Q7aG9tZSZxdW90OyBp ZGVudGl0eQ0KcHJvdmlkZXIsIGJldHRlciB1c2VyIGV4cGVyaWVuY2UsIGV0Yy4gSW4geW91ciBj YXNlLCB0aGUgbW9iaWxlIG5ldHdvcmsNCm9wZXJhdG9yIGlzIHRoZSBJZFAsIGJ1dCB0aGV5IHdv dWxkIGJlIGEgaG9tZSBvcmdhbmlzYXRpb24gdG8gc29tZSB1c2Vycw0KYW5kIGNvbnNlcXVlbnRs eSBhbiBJZFAsIGp1c3QgbGlrZSBhbnkgb3RoZXIgb3JnYW5pc2F0aW9uIHBlcmZvcm1pbmcgdGhl DQpzYW1lIHRhc2suIEknbSBub3QgYXJndWluZyB0aGF0IHlvdSdyZSBub3QgcmlnaHQgYWJvdXQg ZmVkZXJhdGVkIGF1dGhlbnRpY2F0aW9uDQpiZWluZyBhIGdvb2QgdGhpbmcgLSBidXQgdGhhdCdz IG5vdCB0aGUgcHVycG9zZSBvZiB0aGlzIGRvY3VtZW50Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBT ZWNvbmQsIHRoZSBvbmUgdGhpbmcgdGhhdCBzZWVtcyBsaWtlIGl0IGNvdWxkIGJlIGRpZmZlcmVu dCBhdCBmaXJzdA0KZ2xhbmNlIGluIHlvdXIgdXNlIGNhc2UgaXMgdGhhdCB5b3UgaGF2ZSBhIGxh eWVyZWQgYXJjaGl0ZWN0dXJlIHdoZXJlIHVzZXJzDQphcmUgdXNpbmcgbW9iaWxlIGRldmljZXMs IGF0dGFjaGluZyB0byB0aGUgbmV0d29yayB1c2luZyBzdGFuZGFyZCBtZWFucywNCmFuZCB0aGVu IHBlcmZvcm1pbmcgZmVkZXJhdGVkIGF1dGhlbnRpY2F0aW9uIGZyb20gdGhlaXIgZGV2aWNlcy4g SG93ZXZlciwNCkkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGlzIGRpZmZlcmVudCBhdCBhbGwgLSBhcHBs aWNhdGlvbnMgdGhhdCB1c2VycyBvbiB0aGVpcg0KbW9iaWxlIGRldmljZXMgYXJlIHVzaW5nIGNv bnRhY3QgdGhlIGhvbWUgSWRQIChpbiB0aGlzIGNhc2UgaXQgc28gaGFwcGVucw0KdGhlaXIgaG9t ZSBJZFAgaXMgcnVuIGJ5IHRoZSBuZXR3b3JrIHByb3ZpZGVyKSBhbmQgYXV0aGVudGljYXRlIHRo ZSB1c2VyDQpiYXNlZCB1cG9uIHRoYXQuIFRoYXQncyBzdGFuZGFyZCBmZWRlcmF0ZWQgYXV0aGVu dGljYXRpb24sIGp1c3QgZnJvbSBhDQptb2JpbGUgZGV2aWNlIGluc3RlYWQgb2YsIHNheSwgYSBk ZXNrdG9wIG9yIGxhcHRvcC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0aGluayB0aGVyZSdzIGEg Z29vZCBhcmd1bWVudCBpbiB0aGVyZSB0aGF0IG1vYmlsZSB0ZWxlY29tcyBwcm92aWRlcnMNCm1p Z2h0IG1ha2UgYSBnb29kIGNsYXNzIG9mIElkUCwgYnV0IHVuZm9ydHVuYXRlbHkgdGhhdCdzIG5v dCBhcHBsaWNhYmxlDQp0byB0aGlzIGRvY3VtZW50LCBJIGRvbid0IHRoaW5rLjxicj4NCiZndDsg PGJyPg0KJmd0OyBUaGUga2V5IHRoaW5nIGlzIHRoYXQgSSBkb24ndCBzZWUgYW55IG5ldyBwYXJ0 aWN1bGFyIGFwcGxpY2F0aW9ucw0Kb3IgdXNlIGNhc2VzIGZvciBmZWRlcmF0ZWQgYXV0aGVudGlj YXRpb24gaW4geW91ciB0ZXh0LCBqdXN0IGEgc28gSSdtIHN0cnVnZ2xpbmcNCnRvIHNlZSBob3cs IG9yIGlmLCBpdCBmaXRzIGludG8gdGhlIHVzZSBjYXNlIGRvY3VtZW50Ljxicj4NCiZndDsgPGJy Pg0KJmd0OyBZaW54aW5nIC0gSWYgeW91IHRoaW5rIEknbSBtaXN1bmRlcnN0YW5kaW5nIHlvdXIg dXNlIGNhc2UsIHBsZWFzZQ0KZG8gZ2V0IGJhY2sgaW4gdG91Y2ggYW5kIHdlIGNhbiB0cnkgdG8g ZmlndXJlIG91dCB3aGF0IGl0IGlzIGFuZCBob3cgaXQNCmZpdHMgaW50byB0aGUgZG9jdW1lbnQu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEV2ZXJ5b25lIGVsc2UgLSBJZiBhbnlvbmUgZGlzYWdyZWVz IHdpdGggdGhpcyAoaWYgSSdtIG1pc3Npbmcgc29tZXRoaW5nDQpvYnZpb3VzIGhlcmUpLCB0aGVu IHBsZWFzZSBsZXQgbWUga25vdyB3aGVyZSBJJ20gZ29pbmcgd3JvbmcuLi48YnI+DQomZ3Q7IDxi cj4NCiZndDsgUi48YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBEciBSaHlzIFNtaXRoOiBJZGVudGl0 eSwgQWNjZXNzLCBhbmQgTWlkZGxld2FyZSBTcGVjaWFsaXN0PGJyPg0KJmd0OyBDYXJkaWZmIFVu aXZlcnNpdHkgJmFtcDsgSkFORVQoVUspPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGVtYWlsOiBzbWl0 aEBjYXJkaWZmLmFjLnVrIC8gcmh5cy5zbWl0aEBqYS5uZXQ8YnI+DQomZ3Q7IEdQRzogMHhERTJG MDI0Qzxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiAyIEF1ZyAyMDExLCBhdCAyMDo1Mywgd2VpLnlp bnhpbmdAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IERlYXIgUmh5cyBTbWl0aCwgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQWNj b3JkaW5nIHRvIHRoZSBhY3Rpb24gaW4gSUVURiM4MSwgSSBzdW1tYXJpemVkIHRoZSB1c2UgY2Fz ZQ0KaW4gPGJyPg0KJmd0OyZndDsgZHJhZnQtd2VpLWFiZmFiLWZjbGEtMDAgYXMgYW4gaW5wdXQg dG8gZHJhZnQtaWV0Zi1hYmZhYi11c2VjYXNlcy0wMS4NCjxicj4NCiZndDsmZ3Q7IFBsZWFzZSBy ZXZpZXcgaXQuIDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRoYW5rcyEgPGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsgWWlueGluZyBXZWkgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0 OyZndDsgfn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn4NCjxicj4NCiZndDsmZ3Q7IDQueC4gRmVkZXJhdGVkIENyb3Nz LUxheWVyIEFjY2VzcyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 VGVsZWNvbSBvcGVyYXRvcnMgaGF2ZSBhIGNvbW11bmljYXRpb24gbmV0d29yayBpbmZyYXN0cnVj dHVyZXMNCnRvIDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtwcm92aWRlciB1c2VycyB3aXRo IGEgd2VhbHRoeSBvZiBhY2Nlc3MgbWV0aG9kcy4NClRlbGVjb20gb3BlcmF0b3JzIDxicj4NCiZn dDsmZ3Q7ICZuYnNwOyAmbmJzcDtoYXZlIGEgaHVnZSBudW1iZXIgb2YgcmVnaXN0ZXJlZCB1c2Vy cywgYW5kIHRoZXkNCmNhbiBwcm92aWRlIHRydXN0ZWQgPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZu YnNwO2lkZW50aXR5IGFuZCBoaWdoZXIgc2VjdXJpdHkuIFRoZXJlZm9yZSB0aGV5IGhhdmUNCmEg bmF0dXJhbCBhZHZhbnRhZ2UgPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO3RvIGFjdCBhcyBh biBJZGVudGl0eSBQcm92aWRlciAoSWRQKSB0byBzZXJ2ZSBmb3INCnNlcnZpY2UgcHJvdmlkZXJz LiA8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7T24gdGhlIGNvbnRyYXJ5IG1vc3Qgc2Vydmlj ZSBwcm92aWRlcnMgb24gdGhlIEludGVybmV0DQpoYXZlIGxpbWl0ZWQgPGJyPg0KJmd0OyZndDsg Jm5ic3A7ICZuYnNwO2Ftb3VudCBvZiB1c2VycyBhbmQgY2FuIG5vdCBhc3N1cmUgdGhlIHNlY3Vy aXR5IG9mDQp1c2VyIGlkZW50aXR5LCBidXQgPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO3Ro ZXkgY2FuIHByb3ZpZGUgYWJ1bmRhbnQga2luZHMgb2Ygc2VydmljZS4gRnVydGhlcm1vcmUsDQp1 c2VyIGlzIDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtyZWx1Y3RhbnQgdG8gcmVnaXN0ZXIg dG9vIG1hbnkgYWNjb3VudHMgYmVjYXVzZSBpdA0KaXMgaW5jb252ZW5pZW50IHRvIDxicj4NCiZn dDsmZ3Q7ICZuYnNwOyAmbmJzcDtyZW1lbWJlciBkb3plbnMgb2YgcGFzc3dvcmRzLiA8YnI+DQom Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7VGVsZWNvbSBuZXR3b3JrIHN1cHBv cnRzIFdlYiBvciBub24tV2ViIGFwcGxpY2F0aW9uLg0KJm5ic3A7SW4gc29tZSBjYXNlcyA8YnI+ DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7dXNlciBwcmVmZXJzIHRvIGNob29zZSBub24tV2ViIGFw cGxpY2F0aW9uLCBlLmcuDQombmJzcDtNZXNzYWdpbmcgc2VydmljZSwgPGJyPg0KJmd0OyZndDsg Jm5ic3A7ICZuYnNwO1ZvSVAsIEVNYWlsIHNlcnZpY2UsIGV0Yy4gQmFzZWQgb24gdGhlIHJlc3Vs dCBvZg0KbmV0d29yayBzdHJhdHVtIDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDthdXRoZW50 aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiwgVXNlciBlcXVpcG1lbnQNCihVRSkgY2FuIGFjY2Vz cyA8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7YXBwbGljYXRpb25zIHdpdGhvdXQgZG9pbmcg YW5vdGhlciBhdXRoZW50aWNhdGlvbg0KYW5kIGF1dGhvcml6YXRpb24gPGJyPg0KJmd0OyZndDsg Jm5ic3A7ICZuYnNwO3Byb2NlZHVyZS4gSW4gdGhpcyB3YXksIHRoZSBzeXN0ZW0gY2FuIGltcGxl bWVudA0KZmVkZXJhdGVkIGNyb3NzLWxheWVyIDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDth Y2Nlc3MuIEZpcnN0bHkgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGlzIHBlcmZvcm1lZA0KYmV0d2Vl biBVRSBhbmQgPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO05ldHdvcmssIHNlY29uZGx5IFVF IGFjY2Vzc2VzIEFwcGxpY2F0aW9uIGJhc2VkIG9uDQp0aGUgcmVzdWx0IG9mIDxicj4NCiZndDsm Z3Q7ICZuYnNwOyAmbmJzcDtuZXR3b3JrIHN0cmF0dW0ncyBhdXRoZW50aWNhdGlvbi4gSW4gdGhp cyBjYXNlLCBhDQpmZWRlcmF0aW9uIGlzIGZvcm1lZCA8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5i c3A7YmV0d2VlbiBOZXR3b3JrIGFuZCBBcHBsaWNhdGlvbi4gVGhlIGJyaWVmIHN0ZXBzDQphcmUg YXMgZm9sbG93czogPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOzEu ICZuYnNwO1doZW4gVUUgYXR0YWNoZXMgdGhlIE5ldHdvcmssIG11dHVhbCBhdXRoZW50aWNhdGlv bg0KaXMgcGVyZm9ybWVkIDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O21hc3RlciBzZXNzaW9uIGtleSBpcyBjcmVhdGVkIGJldHdlZW4NCnRoZW0uIDxicj4NCiZndDsm Z3Q7ICZuYnNwOyAmbmJzcDsyLiAmbmJzcDtVRSB2aXNpdHMgbm9uLVdlYiBBcHBsaWNhdGlvbiwg ZS5nIE1lc3NhZ2luZw0Kc2VydmljZSwgVm9JUCA8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtzZXJ2aWNlLCBvciBFbWFpbCBzZXJ2aWNlLiA8YnI+DQomZ3Q7Jmd0OyAm bmJzcDsgJm5ic3A7My4gJm5ic3A7QXBwbGljYXRpb24gaGFzIG5vIGluZm9ybWF0aW9uIGFib3V0 IHRoZQ0KVUUuICZuYnNwO1RoZSBBcHBsaWNhdGlvbiA8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtjb250YWN0cyBOZXR3b3JrIHRvIHZhbGlkYXRlIHRoZSBhdXRoZW50 aWNhdGlvbg0KcmVzdWx0IGluIHRoZSA8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtuZXR3b3JrIHN0cmF0dW0uICZuYnNwO0FwcGxpY2F0aW9uDQpjYW4gZmluZCBOZXR3 b3JrIGFjY29yZGluZyB0byB0aGUgPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Y29uZmlndXJhdGlvbiBvciBkeW5hbWljYWwgZGlzY292ZXJ5DQpwcm90b2NvbC4gPGJy Pg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOzQuICZuYnNwO05ldHdvcmsgcmVzcG9uZHMgdG8gQXBw bGljYXRpb24gd2l0aCBhdXRoZW50aWNhdGlvbg0KcmVzdWx0LiA8YnI+DQomZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7NS4gJm5ic3A7VUUgaXMgYXV0aG9yaXplZCB0byBhY2Nlc3MgdGhlIEFwcGxpY2F0 aW9uLg0KPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO0ZvciBmZWRl cmF0ZWQgY3Jvc3MtbGF5ZXIgYWNjZXNzLCBOZXR3b3JrIGNhbiBhc3N1cmUNCnRoZSBBcHBsaWNh dGlvbiA8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7b2YgdGhlIGF1dGhlbnRpY2l0eSBvZiB1 c2VyJ3MgaWRlbnRpdHksIHNoYXJlIHNvbWUNCm9mIHVzZSBwcm9maWxlIDxicj4NCiZndDsmZ3Q7 ICZuYnNwOyAmbmJzcDt3aXRoIEFwcGxpY2F0aW9uLiAmbmJzcDtUaGVzZSBjYW4gYnJpbmcgc29t ZSBiZW5lZml0cw0KdG8gc3Rha2Vob2xkZXJzOiA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0 OyAmbmJzcDsgJm5ic3A7byAmbmJzcDtGb3IgdGVsZWNvbSBvcGVyYXRvcnMsIHRoZXkgY2FuIHBy b3ZpZGUgaWRlbnRpdHkNCnNlcnZpY2UsIHRydXN0ZWQgPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgc2VjdXJpdHkgc2VydmljZSwgbW9iaWxlIHBheW1lbnQgc2VydmljZQ0KYW5k IHNoYXJpbmcgc29tZSB1c2VyIDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBy b2ZpbGVzIGFjY29yZGluZyB1c2VyJ3MgcHJlZmVyZW5jZXMuIFRlbGVjb20NCm9wZXJhdG9ycyBp cyBub3QgPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsganVzdCBwcm92aWRpbmcg cGlwZWxpbmUgZm9yIGNvbW11bmljYXRpb24sDQpidXQgYWxzbyBiZWNvbWUgYSBwYXJ0IG9mIDxi cj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNlcnZpY2UgdmFsdWUgY2hhaW4gYXMg YW4gSWRlbnRpdHkgUHJvdmlkZXIuDQo8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7byAmbmJz cDtGb3Igc2VydmljZSBwcm92aWRlcnMsICZuYnNwO3RoZXkgY2FuIGZvY3VzDQpvbiBjb3JlIGJ1 c2luZXNzIGFuZCByZXVzZSA8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjYXBh YmlsaXRpZXMgcHJvdmlkZWQgYnkgdGVsZWNvbSBvcGVyYXRvcnMNCndpdGhvdXQgd29ycnlpbmcg YWJvdXQgPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc291cmNlcyBvZiB1c2Vy cy4gPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO28gJm5ic3A7Rm9yIGVuZCB1c2VycywgdGhl eSBjYW4gZW5qb3kgc2VhbWxlc3Mgc2VydmljZQ0KZXhwZXJpZW5jZXMgYW5kIDxicj4NCiZndDsm Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGltcHJvdmUgc2VjdXJpdHkgYW5kIHByaXZhY3kuIDxi cj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IH5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fjxicj4NCiZn dDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KJmd0OyZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbg0KdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBv ZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbg0KaXMg Y29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFp bnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48YnI+DQomZ3Q7Jmd0OyBUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs DQphbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkNCmFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUNCm9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZQ0Kb2Yg dGhlIGluZGl2aWR1YWwgc2VuZGVyLjxicj4NCiZndDsmZ3Q7IFRoaXMgbWVzc2FnZSBoYXMgYmVl biBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0NCnN5c3RlbS48 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGFiZmFiIG1haWxpbmcgbGlzdDxi cj4NCiZndDsgYWJmYWJAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYWJmYWI8YnI+DQo8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4N Cjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3Rp Y2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNw O3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNw O21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7 UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQm bmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNw O25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtj b250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNw O290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5i c3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRp YWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZu YnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50 aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4m bmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtl bWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUm bmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZu YnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZu YnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7 c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5l ZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDta VEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0028939148257933_=-- From hannes.tschofenig@gmx.net Mon Oct 24 01:24:16 2011 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 1766121F8C7B for ; Mon, 24 Oct 2011 01:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.515 X-Spam-Level: X-Spam-Status: No, score=-100.515 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WPvU+9nqxrP for ; Mon, 24 Oct 2011 01:24:15 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 82D1021F8C78 for ; Mon, 24 Oct 2011 01:24:14 -0700 (PDT) Received: (qmail invoked by alias); 24 Oct 2011 08:24:12 -0000 Received: from unknown (EHLO [10.255.133.75]) [192.100.123.77] by mail.gmx.net (mp015) with SMTP; 24 Oct 2011 10:24:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1++VbBUe5G+eYCGpLNOECdAa/Ue3c/0vSqndK1Nmd Kwp0h1RCEPBxUD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=GB2312 From: Hannes Tschofenig In-Reply-To: Date: Mon, 24 Oct 2011 11:24:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <946C7107-AD04-4034-A00C-119A6EB3C28E@gmx.net> References: To: wei.yinxing@zte.com.cn X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" 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, 24 Oct 2011 08:24:16 -0000 Hi Yinxing,=20 thanks for the quick response.=20 It may make sense to somewhere (but not in the scenario document) to = describe how the different building blocks are put together since there = are a couple of different options.=20 Ciao Hannes On Oct 24, 2011, at 10:22 AM, wei.yinxing@zte.com.cn wrote: >=20 > Hi, Hannes=20 >=20 > I think you have already explained it clearly. Current mechanisms, = such as EAP, GSS-API, SAML, AAA(Radius/Diameter) are enough for this use = case. For me, The next step is to make use of existing tools defined in = abfab to support this use case.=20 >=20 > -------=20 > Yinxing=20 >=20 >=20 > Hannes Tschofenig > 2011/10/24 15:07 >=20 > =CA=D5=BC=FE=C8=CB > Rhys Smith > =B3=AD=CB=CD > Hannes Tschofenig , wei.yinxing@zte.com.cn, = kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu > =D6=F7=CC=E2 > Re: [abfab] Please review the use case "4.x Federated Cross-Layer = Access" >=20 >=20 >=20 >=20 >=20 > I had a look at http://tools.ietf.org/html/draft-wei-abfab-fcla-00 and = was wondering what specifically needs to be addressed in ABFAB to make = use of the existing telecommunication subscriber infrastructure. I = believe everything is supported already. >=20 > EAP is used in ABFAB (within the GSS-API) and that allows any = authentication mechanisms to be used, including the AKA. That isn't a = problem.=20 >=20 > If you don't want to use AKA directly within EAP but add an additional = GBA run beforehand you can do that as well. >=20 > So, Yinxing could you explain what additional functionality is need?=20= >=20 > Ciao > Hannes >=20 > On Oct 22, 2011, at 10:51 PM, Rhys Smith wrote: >=20 > > Hi Yinxing, (cc:ed to abfab list for discussion). > >=20 > > I'm just looking at making the next version of the use case document = for ABFAB, and so I've been looking at the use case you suggested = (below, if you don't have a copy of the original message sent to the = abfab list). > >=20 > > Basically, I've reviewed the suggestion and I'm not quite sure what = the use case actually is? > >=20 > > First, it seems as though most all of the content in the text you've = submitted simply describes why federated authentication in general is a = good thing - user registration at the user's "home" identity provider, = better user experience, etc. In your case, the mobile network operator = is the IdP, but they would be a home organisation to some users and = consequently an IdP, just like any other organisation performing the = same task. I'm not arguing that you're not right about federated = authentication being a good thing - but that's not the purpose of this = document. > >=20 > > Second, the one thing that seems like it could be different at first = glance in your use case is that you have a layered architecture where = users are using mobile devices, attaching to the network using standard = means, and then performing federated authentication from their devices. = However, I don't see how this is different at all - applications that = users on their mobile devices are using contact the home IdP (in this = case it so happens their home IdP is run by the network provider) and = authenticate the user based upon that. That's standard federated = authentication, just from a mobile device instead of, say, a desktop or = laptop. > >=20 > > I think there's a good argument in there that mobile telecoms = providers might make a good class of IdP, but unfortunately that's not = applicable to this document, I don't think. > >=20 > > The key thing is that I don't see any new particular applications or = use cases for federated authentication in your text, just a so I'm = struggling to see how, or if, it fits into the use case document. > >=20 > > Yinxing - If you think I'm misunderstanding your use case, please do = get back in touch and we can try to figure out what it is and how it = fits into the document. > >=20 > > Everyone else - If anyone disagrees with this (if I'm missing = something obvious here), then please let me know where I'm going = wrong... > >=20 > > R. > > -- > > Dr Rhys Smith: Identity, Access, and Middleware Specialist > > Cardiff University & JANET(UK) > >=20 > > email: smith@cardiff.ac.uk / rhys.smith@ja.net > > GPG: 0xDE2F024C > >=20 > > On 2 Aug 2011, at 20:53, wei.yinxing@zte.com.cn wrote: > >=20 > >>=20 > >> Dear Rhys Smith,=20 > >>=20 > >> According to the action in IETF#81, I summarized the use case in=20 > >> draft-wei-abfab-fcla-00 as an input to = draft-ietf-abfab-usecases-01.=20 > >> Please review it.=20 > >>=20 > >> Thanks!=20 > >>=20 > >> Yinxing Wei=20 > >>=20 > >> = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=20= > >> 4.x. Federated Cross-Layer Access=20 > >>=20 > >> Telecom operators have a communication network infrastructures = to=20 > >> provider users with a wealthy of access methods. Telecom = operators=20 > >> have a huge number of registered users, and they can provide = trusted=20 > >> identity and higher security. Therefore they have a natural = advantage=20 > >> to act as an Identity Provider (IdP) to serve for service = providers.=20 > >> On the contrary most service providers on the Internet have = limited=20 > >> amount of users and can not assure the security of user = identity, but=20 > >> they can provide abundant kinds of service. Furthermore, user is=20= > >> reluctant to register too many accounts because it is = inconvenient to=20 > >> remember dozens of passwords.=20 > >>=20 > >> Telecom network supports Web or non-Web application. In some = cases=20 > >> user prefers to choose non-Web application, e.g. Messaging = service,=20 > >> VoIP, EMail service, etc. Based on the result of network stratum=20= > >> authentication and authorization, User equipment (UE) can access=20= > >> applications without doing another authentication and = authorization=20 > >> procedure. In this way, the system can implement federated = cross-layer=20 > >> access. Firstly mutual authentication is performed between UE = and=20 > >> Network, secondly UE accesses Application based on the result of=20= > >> network stratum's authentication. In this case, a federation is = formed=20 > >> between Network and Application. The brief steps are as follows:=20= > >>=20 > >> 1. When UE attaches the Network, mutual authentication is = performed=20 > >> master session key is created between them.=20 > >> 2. UE visits non-Web Application, e.g Messaging service, VoIP=20= > >> service, or Email service.=20 > >> 3. Application has no information about the UE. The = Application=20 > >> contacts Network to validate the authentication result in = the=20 > >> network stratum. Application can find Network according to = the=20 > >> configuration or dynamical discovery protocol.=20 > >> 4. Network responds to Application with authentication result.=20= > >> 5. UE is authorized to access the Application.=20 > >>=20 > >> For federated cross-layer access, Network can assure the = Application=20 > >> of the authenticity of user's identity, share some of use = profile=20 > >> with Application. These can bring some benefits to = stakeholders:=20 > >>=20 > >> o For telecom operators, they can provide identity service, = trusted=20 > >> security service, mobile payment service and sharing some = user=20 > >> profiles according user's preferences. Telecom operators is = not=20 > >> just providing pipeline for communication, but also become a = part of=20 > >> service value chain as an Identity Provider.=20 > >> o For service providers, they can focus on core business and = reuse=20 > >> capabilities provided by telecom operators without worrying = about=20 > >> sources of users.=20 > >> o For end users, they can enjoy seamless service experiences = and=20 > >> improve security and privacy.=20 > >>=20 > >> = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~ > >> -------------------------------------------------------- > >> ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > >> This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > >> This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. > >>=20 > >=20 > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab >=20 >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. >=20 From wei.yinxing@zte.com.cn Mon Oct 24 01:43:28 2011 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 1761121F8CA3 for ; Mon, 24 Oct 2011 01:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.705 X-Spam-Level: X-Spam-Status: No, score=-93.705 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5VyItgG7Ui9 for ; Mon, 24 Oct 2011 01:43:26 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB7A21F8CA2 for ; Mon, 24 Oct 2011 01:43:25 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 46621967931198; Mon, 24 Oct 2011 16:35:43 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 15054.3921463883; Mon, 24 Oct 2011 16:43:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p9O8goj7056699; Mon, 24 Oct 2011 16:42:50 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: <946C7107-AD04-4034-A00C-119A6EB3C28E@gmx.net> To: Hannes Tschofenig MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Mon, 24 Oct 2011 16:42:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-24 16:42:52, Serialize complete at 2011-10-24 16:42:52 Content-Type: multipart/alternative; boundary="=_alternative 002FDECF48257933_=" X-MAIL: mse01.zte.com.cn p9O8goj7056699 Cc: kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu Subject: [abfab] =?gb2312?b?tPC4tDogUmU6ICBQbGVhc2UgcmV2aWV3IHRoZSB1c2Ug?= =?gb2312?b?Y2FzZSAiNC54IEZlZGVyYXRlZCBDcm9zcy1MYXllciBBY2Nlc3Mi?= 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, 24 Oct 2011 08:43:28 -0000 This is a multipart message in MIME format. --=_alternative 002FDECF48257933_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIEhhbm5lcw0KDQogIEkgYWdyZWUgd2l0aCB5b3VyIGFkdmljZS4gDQogIE9uZSB3YXkgaXMg dG8gbW92ZSB0aGUgdXNlIGNhc2UgZnJvbSBkcmFmdC13ZWktYWJmYWItZmNsYSB0byANCmRyYWZ0 LWlldGYtYWJmYWItdXNlY2FzZXMsIGFuZCBwdXQgdGhlIGRpZmZlcmVudCBvcHRpb25zIGludG8g dGhlIA0KZHJhZnQtd2VpLWFiZmFiLWZjbGEuIA0KDQpEb2VzIGl0IG1ha2Ugc2Vuc2U/DQoNCi0t LS0tLS0NCllpbnhpbmcNCg0KDQoNCkhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5p Z0BnbXgubmV0PiANCjIwMTEvMTAvMjQgMTY6MjQNCg0KytW8/sjLDQp3ZWkueWlueGluZ0B6dGUu Y29tLmNuDQqzrcvNDQpIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5l dD4sIGFiZmFiQGlldGYub3JnLCANCmhhcnRtYW5zLWlldGZAbWl0LmVkdSwga3dpZXJlbmdAY2lz Y28uY29tLCBSaHlzIFNtaXRoIA0KPHNtaXRoQENBUkRJRkYuQUMuVUs+DQrW98ziDQpSZTogW2Fi ZmFiXSBQbGVhc2UgcmV2aWV3IHRoZSB1c2UgY2FzZSAiNC54IEZlZGVyYXRlZCBDcm9zcy1MYXll ciBBY2Nlc3MiDQoNCg0KDQoNCg0KDQpIaSBZaW54aW5nLCANCg0KdGhhbmtzIGZvciB0aGUgcXVp Y2sgcmVzcG9uc2UuIA0KDQpJdCBtYXkgbWFrZSBzZW5zZSB0byBzb21ld2hlcmUgKGJ1dCBub3Qg aW4gdGhlIHNjZW5hcmlvIGRvY3VtZW50KSB0byANCmRlc2NyaWJlIGhvdyB0aGUgZGlmZmVyZW50 IGJ1aWxkaW5nIGJsb2NrcyBhcmUgcHV0IHRvZ2V0aGVyIHNpbmNlIHRoZXJlIA0KYXJlIGEgY291 cGxlIG9mIGRpZmZlcmVudCBvcHRpb25zLiANCg0KQ2lhbw0KSGFubmVzDQoNCk9uIE9jdCAyNCwg MjAxMSwgYXQgMTA6MjIgQU0sIHdlaS55aW54aW5nQHp0ZS5jb20uY24gd3JvdGU6DQoNCj4gDQo+ IEhpLCBIYW5uZXMgDQo+IA0KPiAgSSB0aGluayB5b3UgaGF2ZSBhbHJlYWR5IGV4cGxhaW5lZCBp dCBjbGVhcmx5LiBDdXJyZW50IG1lY2hhbmlzbXMsIHN1Y2ggDQphcyBFQVAsIEdTUy1BUEksIFNB TUwsIEFBQShSYWRpdXMvRGlhbWV0ZXIpIGFyZSBlbm91Z2ggZm9yIHRoaXMgdXNlIGNhc2UuIA0K Rm9yIG1lLCBUaGUgbmV4dCBzdGVwIGlzIHRvIG1ha2UgdXNlIG9mIGV4aXN0aW5nIHRvb2xzIGRl ZmluZWQgaW4gYWJmYWIgdG8gDQpzdXBwb3J0IHRoaXMgdXNlIGNhc2UuIA0KPiANCj4gLS0tLS0t LSANCj4gWWlueGluZyANCj4gDQo+IA0KPiBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hv ZmVuaWdAZ214Lm5ldD4NCj4gMjAxMS8xMC8yNCAxNTowNw0KPiANCj4gytW8/sjLDQo+IFJoeXMg U21pdGggPHNtaXRoQENBUkRJRkYuQUMuVUs+DQo+ILOty80NCj4gSGFubmVzIFRzY2hvZmVuaWcg PGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+LCB3ZWkueWlueGluZ0B6dGUuY29tLmNuLCANCmt3 aWVyZW5nQGNpc2NvLmNvbSwgYWJmYWJAaWV0Zi5vcmcsIGhhcnRtYW5zLWlldGZAbWl0LmVkdQ0K PiDW98ziDQo+IFJlOiBbYWJmYWJdIFBsZWFzZSByZXZpZXcgdGhlIHVzZSBjYXNlICI0LnggRmVk ZXJhdGVkIENyb3NzLUxheWVyIA0KQWNjZXNzIg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEkgaGFk IGEgbG9vayBhdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13ZWktYWJmYWItZmNs YS0wMCBhbmQgDQp3YXMgd29uZGVyaW5nIHdoYXQgc3BlY2lmaWNhbGx5IG5lZWRzIHRvIGJlIGFk ZHJlc3NlZCBpbiBBQkZBQiB0byBtYWtlIHVzZSANCm9mIHRoZSBleGlzdGluZyB0ZWxlY29tbXVu aWNhdGlvbiBzdWJzY3JpYmVyIGluZnJhc3RydWN0dXJlLiBJIGJlbGlldmUgDQpldmVyeXRoaW5n IGlzIHN1cHBvcnRlZCBhbHJlYWR5Lg0KPiANCj4gRUFQIGlzIHVzZWQgaW4gQUJGQUIgKHdpdGhp biB0aGUgR1NTLUFQSSkgYW5kIHRoYXQgYWxsb3dzIGFueSANCmF1dGhlbnRpY2F0aW9uIG1lY2hh bmlzbXMgdG8gYmUgdXNlZCwgaW5jbHVkaW5nIHRoZSBBS0EuIFRoYXQgaXNuJ3QgYSANCnByb2Js ZW0uIA0KPiANCj4gSWYgeW91IGRvbid0IHdhbnQgdG8gdXNlIEFLQSBkaXJlY3RseSB3aXRoaW4g RUFQIGJ1dCBhZGQgYW4gYWRkaXRpb25hbCANCkdCQSBydW4gYmVmb3JlaGFuZCB5b3UgY2FuIGRv IHRoYXQgYXMgd2VsbC4NCj4gDQo+IFNvLCBZaW54aW5nIGNvdWxkIHlvdSBleHBsYWluIHdoYXQg YWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IGlzIG5lZWQ/IA0KPiANCj4gQ2lhbw0KPiBIYW5uZXMN Cj4gDQo+IE9uIE9jdCAyMiwgMjAxMSwgYXQgMTA6NTEgUE0sIFJoeXMgU21pdGggd3JvdGU6DQo+ IA0KPiA+IEhpIFlpbnhpbmcsIChjYzplZCB0byBhYmZhYiBsaXN0IGZvciBkaXNjdXNzaW9uKS4N Cj4gPiANCj4gPiBJJ20ganVzdCBsb29raW5nIGF0IG1ha2luZyB0aGUgbmV4dCB2ZXJzaW9uIG9m IHRoZSB1c2UgY2FzZSBkb2N1bWVudCANCmZvciBBQkZBQiwgYW5kIHNvIEkndmUgYmVlbiBsb29r aW5nIGF0IHRoZSB1c2UgY2FzZSB5b3Ugc3VnZ2VzdGVkIChiZWxvdywgDQppZiB5b3UgZG9uJ3Qg aGF2ZSBhIGNvcHkgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugc2VudCB0byB0aGUgYWJmYWIgbGlz dCkuDQo+ID4gDQo+ID4gQmFzaWNhbGx5LCBJJ3ZlIHJldmlld2VkIHRoZSBzdWdnZXN0aW9uIGFu ZCBJJ20gbm90IHF1aXRlIHN1cmUgd2hhdCANCnRoZSB1c2UgY2FzZSBhY3R1YWxseSBpcz8NCj4g PiANCj4gPiBGaXJzdCwgaXQgc2VlbXMgYXMgdGhvdWdoIG1vc3QgYWxsIG9mIHRoZSBjb250ZW50 IGluIHRoZSB0ZXh0IHlvdSd2ZSANCnN1Ym1pdHRlZCBzaW1wbHkgZGVzY3JpYmVzIHdoeSBmZWRl cmF0ZWQgYXV0aGVudGljYXRpb24gaW4gZ2VuZXJhbCBpcyBhIA0KZ29vZCB0aGluZyAtIHVzZXIg cmVnaXN0cmF0aW9uIGF0IHRoZSB1c2VyJ3MgImhvbWUiIGlkZW50aXR5IHByb3ZpZGVyLCANCmJl dHRlciB1c2VyIGV4cGVyaWVuY2UsIGV0Yy4gSW4geW91ciBjYXNlLCB0aGUgbW9iaWxlIG5ldHdv cmsgb3BlcmF0b3IgaXMgDQp0aGUgSWRQLCBidXQgdGhleSB3b3VsZCBiZSBhIGhvbWUgb3JnYW5p c2F0aW9uIHRvIHNvbWUgdXNlcnMgYW5kIA0KY29uc2VxdWVudGx5IGFuIElkUCwganVzdCBsaWtl IGFueSBvdGhlciBvcmdhbmlzYXRpb24gcGVyZm9ybWluZyB0aGUgc2FtZSANCnRhc2suIEknbSBu b3QgYXJndWluZyB0aGF0IHlvdSdyZSBub3QgcmlnaHQgYWJvdXQgZmVkZXJhdGVkIGF1dGhlbnRp Y2F0aW9uIA0KYmVpbmcgYSBnb29kIHRoaW5nIC0gYnV0IHRoYXQncyBub3QgdGhlIHB1cnBvc2Ug b2YgdGhpcyBkb2N1bWVudC4NCj4gPiANCj4gPiBTZWNvbmQsIHRoZSBvbmUgdGhpbmcgdGhhdCBz ZWVtcyBsaWtlIGl0IGNvdWxkIGJlIGRpZmZlcmVudCBhdCBmaXJzdCANCmdsYW5jZSBpbiB5b3Vy IHVzZSBjYXNlIGlzIHRoYXQgeW91IGhhdmUgYSBsYXllcmVkIGFyY2hpdGVjdHVyZSB3aGVyZSAN CnVzZXJzIGFyZSB1c2luZyBtb2JpbGUgZGV2aWNlcywgYXR0YWNoaW5nIHRvIHRoZSBuZXR3b3Jr IHVzaW5nIHN0YW5kYXJkIA0KbWVhbnMsIGFuZCB0aGVuIHBlcmZvcm1pbmcgZmVkZXJhdGVkIGF1 dGhlbnRpY2F0aW9uIGZyb20gdGhlaXIgZGV2aWNlcy4gDQpIb3dldmVyLCBJIGRvbid0IHNlZSBo b3cgdGhpcyBpcyBkaWZmZXJlbnQgYXQgYWxsIC0gYXBwbGljYXRpb25zIHRoYXQgDQp1c2VycyBv biB0aGVpciBtb2JpbGUgZGV2aWNlcyBhcmUgdXNpbmcgY29udGFjdCB0aGUgaG9tZSBJZFAgKGlu IHRoaXMgY2FzZSANCml0IHNvIGhhcHBlbnMgdGhlaXIgaG9tZSBJZFAgaXMgcnVuIGJ5IHRoZSBu ZXR3b3JrIHByb3ZpZGVyKSBhbmQgDQphdXRoZW50aWNhdGUgdGhlIHVzZXIgYmFzZWQgdXBvbiB0 aGF0LiBUaGF0J3Mgc3RhbmRhcmQgZmVkZXJhdGVkIA0KYXV0aGVudGljYXRpb24sIGp1c3QgZnJv bSBhIG1vYmlsZSBkZXZpY2UgaW5zdGVhZCBvZiwgc2F5LCBhIGRlc2t0b3Agb3IgDQpsYXB0b3Au DQo+ID4gDQo+ID4gSSB0aGluayB0aGVyZSdzIGEgZ29vZCBhcmd1bWVudCBpbiB0aGVyZSB0aGF0 IG1vYmlsZSB0ZWxlY29tcyANCnByb3ZpZGVycyBtaWdodCBtYWtlIGEgZ29vZCBjbGFzcyBvZiBJ ZFAsIGJ1dCB1bmZvcnR1bmF0ZWx5IHRoYXQncyBub3QgDQphcHBsaWNhYmxlIHRvIHRoaXMgZG9j dW1lbnQsIEkgZG9uJ3QgdGhpbmsuDQo+ID4gDQo+ID4gVGhlIGtleSB0aGluZyBpcyB0aGF0IEkg ZG9uJ3Qgc2VlIGFueSBuZXcgcGFydGljdWxhciBhcHBsaWNhdGlvbnMgb3IgDQp1c2UgY2FzZXMg Zm9yIGZlZGVyYXRlZCBhdXRoZW50aWNhdGlvbiBpbiB5b3VyIHRleHQsIGp1c3QgYSBzbyBJJ20g DQpzdHJ1Z2dsaW5nIHRvIHNlZSBob3csIG9yIGlmLCBpdCBmaXRzIGludG8gdGhlIHVzZSBjYXNl IGRvY3VtZW50Lg0KPiA+IA0KPiA+IFlpbnhpbmcgLSBJZiB5b3UgdGhpbmsgSSdtIG1pc3VuZGVy c3RhbmRpbmcgeW91ciB1c2UgY2FzZSwgcGxlYXNlIGRvIA0KZ2V0IGJhY2sgaW4gdG91Y2ggYW5k IHdlIGNhbiB0cnkgdG8gZmlndXJlIG91dCB3aGF0IGl0IGlzIGFuZCBob3cgaXQgZml0cyANCmlu dG8gdGhlIGRvY3VtZW50Lg0KPiA+IA0KPiA+IEV2ZXJ5b25lIGVsc2UgLSBJZiBhbnlvbmUgZGlz YWdyZWVzIHdpdGggdGhpcyAoaWYgSSdtIG1pc3NpbmcgDQpzb21ldGhpbmcgb2J2aW91cyBoZXJl KSwgdGhlbiBwbGVhc2UgbGV0IG1lIGtub3cgd2hlcmUgSSdtIGdvaW5nIHdyb25nLi4uDQo+ID4g DQo+ID4gUi4NCj4gPiAtLQ0KPiA+IERyIFJoeXMgU21pdGg6IElkZW50aXR5LCBBY2Nlc3MsIGFu ZCBNaWRkbGV3YXJlIFNwZWNpYWxpc3QNCj4gPiBDYXJkaWZmIFVuaXZlcnNpdHkgJiBKQU5FVChV SykNCj4gPiANCj4gPiBlbWFpbDogc21pdGhAY2FyZGlmZi5hYy51ayAvIHJoeXMuc21pdGhAamEu bmV0DQo+ID4gR1BHOiAweERFMkYwMjRDDQo+ID4gDQo+ID4gT24gMiBBdWcgMjAxMSwgYXQgMjA6 NTMsIHdlaS55aW54aW5nQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4gDQo+ID4+IA0KPiA+PiBEZWFy IFJoeXMgU21pdGgsIA0KPiA+PiANCj4gPj4gQWNjb3JkaW5nIHRvIHRoZSBhY3Rpb24gaW4gSUVU RiM4MSwgSSBzdW1tYXJpemVkIHRoZSB1c2UgY2FzZSBpbiANCj4gPj4gZHJhZnQtd2VpLWFiZmFi LWZjbGEtMDAgYXMgYW4gaW5wdXQgdG8gZHJhZnQtaWV0Zi1hYmZhYi11c2VjYXNlcy0wMS4gDQo+ ID4+IFBsZWFzZSByZXZpZXcgaXQuIA0KPiA+PiANCj4gPj4gVGhhbmtzISANCj4gPj4gDQo+ID4+ IFlpbnhpbmcgV2VpIA0KPiA+PiANCj4gPj4gDQp+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fiANCj4gPj4gNC54LiBG ZWRlcmF0ZWQgQ3Jvc3MtTGF5ZXIgQWNjZXNzIA0KPiA+PiANCj4gPj4gICAgVGVsZWNvbSBvcGVy YXRvcnMgaGF2ZSBhIGNvbW11bmljYXRpb24gbmV0d29yayBpbmZyYXN0cnVjdHVyZXMgdG8gDQo+ ID4+ICAgIHByb3ZpZGVyIHVzZXJzIHdpdGggYSB3ZWFsdGh5IG9mIGFjY2VzcyBtZXRob2RzLiBU ZWxlY29tIG9wZXJhdG9ycyANCg0KPiA+PiAgICBoYXZlIGEgaHVnZSBudW1iZXIgb2YgcmVnaXN0 ZXJlZCB1c2VycywgYW5kIHRoZXkgY2FuIHByb3ZpZGUgDQp0cnVzdGVkIA0KPiA+PiAgICBpZGVu dGl0eSBhbmQgaGlnaGVyIHNlY3VyaXR5LiBUaGVyZWZvcmUgdGhleSBoYXZlIGEgbmF0dXJhbCAN CmFkdmFudGFnZSANCj4gPj4gICAgdG8gYWN0IGFzIGFuIElkZW50aXR5IFByb3ZpZGVyIChJZFAp IHRvIHNlcnZlIGZvciBzZXJ2aWNlIA0KcHJvdmlkZXJzLiANCj4gPj4gICAgT24gdGhlIGNvbnRy YXJ5IG1vc3Qgc2VydmljZSBwcm92aWRlcnMgb24gdGhlIEludGVybmV0IGhhdmUgDQpsaW1pdGVk IA0KPiA+PiAgICBhbW91bnQgb2YgdXNlcnMgYW5kIGNhbiBub3QgYXNzdXJlIHRoZSBzZWN1cml0 eSBvZiB1c2VyIGlkZW50aXR5LCANCmJ1dCANCj4gPj4gICAgdGhleSBjYW4gcHJvdmlkZSBhYnVu ZGFudCBraW5kcyBvZiBzZXJ2aWNlLiBGdXJ0aGVybW9yZSwgdXNlciBpcyANCj4gPj4gICAgcmVs dWN0YW50IHRvIHJlZ2lzdGVyIHRvbyBtYW55IGFjY291bnRzIGJlY2F1c2UgaXQgaXMgaW5jb252 ZW5pZW50IA0KdG8gDQo+ID4+ICAgIHJlbWVtYmVyIGRvemVucyBvZiBwYXNzd29yZHMuIA0KPiA+ PiANCj4gPj4gICAgVGVsZWNvbSBuZXR3b3JrIHN1cHBvcnRzIFdlYiBvciBub24tV2ViIGFwcGxp Y2F0aW9uLiAgSW4gc29tZSANCmNhc2VzIA0KPiA+PiAgICB1c2VyIHByZWZlcnMgdG8gY2hvb3Nl IG5vbi1XZWIgYXBwbGljYXRpb24sIGUuZy4gIE1lc3NhZ2luZyANCnNlcnZpY2UsIA0KPiA+PiAg ICBWb0lQLCBFTWFpbCBzZXJ2aWNlLCBldGMuIEJhc2VkIG9uIHRoZSByZXN1bHQgb2YgbmV0d29y ayBzdHJhdHVtIA0KPiA+PiAgICBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiwgVXNl ciBlcXVpcG1lbnQgKFVFKSBjYW4gYWNjZXNzIA0KPiA+PiAgICBhcHBsaWNhdGlvbnMgd2l0aG91 dCBkb2luZyBhbm90aGVyIGF1dGhlbnRpY2F0aW9uIGFuZCANCmF1dGhvcml6YXRpb24gDQo+ID4+ ICAgIHByb2NlZHVyZS4gSW4gdGhpcyB3YXksIHRoZSBzeXN0ZW0gY2FuIGltcGxlbWVudCBmZWRl cmF0ZWQgDQpjcm9zcy1sYXllciANCj4gPj4gICAgYWNjZXNzLiBGaXJzdGx5IG11dHVhbCBhdXRo ZW50aWNhdGlvbiBpcyBwZXJmb3JtZWQgYmV0d2VlbiBVRSBhbmQgDQo+ID4+ICAgIE5ldHdvcmss IHNlY29uZGx5IFVFIGFjY2Vzc2VzIEFwcGxpY2F0aW9uIGJhc2VkIG9uIHRoZSByZXN1bHQgb2Yg DQo+ID4+ICAgIG5ldHdvcmsgc3RyYXR1bSdzIGF1dGhlbnRpY2F0aW9uLiBJbiB0aGlzIGNhc2Us IGEgZmVkZXJhdGlvbiBpcyANCmZvcm1lZCANCj4gPj4gICAgYmV0d2VlbiBOZXR3b3JrIGFuZCBB cHBsaWNhdGlvbi4gVGhlIGJyaWVmIHN0ZXBzIGFyZSBhcyBmb2xsb3dzOiANCj4gPj4gDQo+ID4+ ICAgIDEuICBXaGVuIFVFIGF0dGFjaGVzIHRoZSBOZXR3b3JrLCBtdXR1YWwgYXV0aGVudGljYXRp b24gaXMgDQpwZXJmb3JtZWQgDQo+ID4+ICAgICAgICBtYXN0ZXIgc2Vzc2lvbiBrZXkgaXMgY3Jl YXRlZCBiZXR3ZWVuIHRoZW0uIA0KPiA+PiAgICAyLiAgVUUgdmlzaXRzIG5vbi1XZWIgQXBwbGlj YXRpb24sIGUuZyBNZXNzYWdpbmcgc2VydmljZSwgVm9JUCANCj4gPj4gICAgICAgIHNlcnZpY2Us IG9yIEVtYWlsIHNlcnZpY2UuIA0KPiA+PiAgICAzLiAgQXBwbGljYXRpb24gaGFzIG5vIGluZm9y bWF0aW9uIGFib3V0IHRoZSBVRS4gIFRoZSBBcHBsaWNhdGlvbiANCj4gPj4gICAgICAgIGNvbnRh Y3RzIE5ldHdvcmsgdG8gdmFsaWRhdGUgdGhlIGF1dGhlbnRpY2F0aW9uIHJlc3VsdCBpbiB0aGUg DQo+ID4+ICAgICAgICBuZXR3b3JrIHN0cmF0dW0uICBBcHBsaWNhdGlvbiBjYW4gZmluZCBOZXR3 b3JrIGFjY29yZGluZyB0byANCnRoZSANCj4gPj4gICAgICAgIGNvbmZpZ3VyYXRpb24gb3IgZHlu YW1pY2FsIGRpc2NvdmVyeSBwcm90b2NvbC4gDQo+ID4+ICAgIDQuICBOZXR3b3JrIHJlc3BvbmRz IHRvIEFwcGxpY2F0aW9uIHdpdGggYXV0aGVudGljYXRpb24gcmVzdWx0LiANCj4gPj4gICAgNS4g IFVFIGlzIGF1dGhvcml6ZWQgdG8gYWNjZXNzIHRoZSBBcHBsaWNhdGlvbi4gDQo+ID4+IA0KPiA+ PiAgICBGb3IgZmVkZXJhdGVkIGNyb3NzLWxheWVyIGFjY2VzcywgTmV0d29yayBjYW4gYXNzdXJl IHRoZSANCkFwcGxpY2F0aW9uIA0KPiA+PiAgICBvZiB0aGUgYXV0aGVudGljaXR5IG9mIHVzZXIn cyBpZGVudGl0eSwgc2hhcmUgc29tZSBvZiB1c2UgcHJvZmlsZSANCj4gPj4gICAgd2l0aCBBcHBs aWNhdGlvbi4gIFRoZXNlIGNhbiBicmluZyBzb21lIGJlbmVmaXRzIHRvIHN0YWtlaG9sZGVyczog DQo+ID4+IA0KPiA+PiAgICBvICBGb3IgdGVsZWNvbSBvcGVyYXRvcnMsIHRoZXkgY2FuIHByb3Zp ZGUgaWRlbnRpdHkgc2VydmljZSwgDQp0cnVzdGVkIA0KPiA+PiAgICAgICBzZWN1cml0eSBzZXJ2 aWNlLCBtb2JpbGUgcGF5bWVudCBzZXJ2aWNlIGFuZCBzaGFyaW5nIHNvbWUgdXNlciANCj4gPj4g ICAgICAgcHJvZmlsZXMgYWNjb3JkaW5nIHVzZXIncyBwcmVmZXJlbmNlcy4gVGVsZWNvbSBvcGVy YXRvcnMgaXMgbm90IA0KDQo+ID4+ICAgICAgIGp1c3QgcHJvdmlkaW5nIHBpcGVsaW5lIGZvciBj b21tdW5pY2F0aW9uLCBidXQgYWxzbyBiZWNvbWUgYSANCnBhcnQgb2YgDQo+ID4+ICAgICAgIHNl cnZpY2UgdmFsdWUgY2hhaW4gYXMgYW4gSWRlbnRpdHkgUHJvdmlkZXIuIA0KPiA+PiAgICBvICBG b3Igc2VydmljZSBwcm92aWRlcnMsICB0aGV5IGNhbiBmb2N1cyBvbiBjb3JlIGJ1c2luZXNzIGFu ZCANCnJldXNlIA0KPiA+PiAgICAgICBjYXBhYmlsaXRpZXMgcHJvdmlkZWQgYnkgdGVsZWNvbSBv cGVyYXRvcnMgd2l0aG91dCB3b3JyeWluZyANCmFib3V0IA0KPiA+PiAgICAgICBzb3VyY2VzIG9m IHVzZXJzLiANCj4gPj4gICAgbyAgRm9yIGVuZCB1c2VycywgdGhleSBjYW4gZW5qb3kgc2VhbWxl c3Mgc2VydmljZSBleHBlcmllbmNlcyBhbmQgDQo+ID4+ICAgICAgIGltcHJvdmUgc2VjdXJpdHkg YW5kIHByaXZhY3kuIA0KPiA+PiANCj4gPj4gDQp+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn4NCj4gPj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPj4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIA0KbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIA0KY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byANCm1haW50YWluIHNlY3Jl Y3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlz IA0KY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQo+ID4+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIA0KaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIA0KYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y IHBsZWFzZSBub3RpZnkgdGhlIA0Kb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIA0Kb2YgdGhlIGluZGl2aWR1YWwg c2VuZGVyLg0KPiA+PiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBh bmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KPiA+PiANCj4gPiANCj4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGFiZmFiIG1h aWxpbmcgbGlzdA0KPiA+IGFiZmFiQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hYmZhYg0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h aWwgDQppcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24gDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQg YWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IA0KYW5kIGFyZSBub3QgcGVy bWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8g DQpvdGhlcnMuDQo+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0 IGFyZSBjb25maWRlbnRpYWwgYW5kIA0KaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIA0KYWRkcmVzc2VkLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIA0K b3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1l c3NhZ2UgYXJlIHRob3NlIA0Kb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KPiBUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IA0Kc3lzdGVtLg0KPiANCg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJv cGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRp b24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQg dG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhl IGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFu ZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo b20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2 aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVh bCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQg U3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 002FDECF48257933_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBIYW5uZXM8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJIGFncmVlIHdp dGggeW91ciBhZHZpY2UuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7IE9uZSB3YXkgaXMgdG8gbW92ZSB0aGUgdXNlIGNhc2UNCmZyb20gPC9mb250Pjxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC13ZWktYWJmYWItZmNsYS0wMC50 eHQiPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1PmRyYWZ0LXdlaS1hYmZhYi1mY2xhPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj50byA8L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2FiZmFiL2Ry YWZ0LWlldGYtYWJmYWItdXNlY2FzZXMvIj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5kcmFm dC1pZXRmLWFiZmFiLXVzZWNhc2VzPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPiwNCmFuZCBw dXQgdGhlIGRpZmZlcmVudCBvcHRpb25zIGludG8gdGhlIDwvZm9udD48YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd2VpLWFiZmFiLWZjbGEtMDAudHh0Ij48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZT48dT5kcmFmdC13ZWktYWJmYWItZmNsYS48L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTM+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkRvZXMgaXQgbWFrZSBz ZW5zZT88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPi0tLS0tLS08L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zPllpbnhpbmc8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+SGFubmVzIFRzY2hvZmVuaWcgJmx0O2hhbm5lcy50c2Nob2Zlbmln QGdteC5uZXQmZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjIwMTEvMTAvMjQgMTY6MjQ8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+d2VpLnlpbnhpbmdAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+SGFubmVzIFRzY2hvZmVuaWcgJmx0O2hhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQmZ3Q7 LA0KYWJmYWJAaWV0Zi5vcmcsIGhhcnRtYW5zLWlldGZAbWl0LmVkdSwga3dpZXJlbmdAY2lzY28u Y29tLCBSaHlzIFNtaXRoICZsdDtzbWl0aEBDQVJESUZGLkFDLlVLJmd0OzwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+UmU6IFthYmZhYl0gUGxlYXNlIHJldmlldyB0aGUgdXNlIGNhc2UNCiZxdW90OzQueCBG ZWRlcmF0ZWQgQ3Jvc3MtTGF5ZXIgQWNjZXNzJnF1b3Q7PC9mb250PjwvdGFibGU+DQo8YnI+DQo8 dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+ DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5IaSBZaW54aW5nLCA8YnI+DQo8YnI+ DQp0aGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZS4gPGJyPg0KPGJyPg0KSXQgbWF5IG1ha2Ug c2Vuc2UgdG8gc29tZXdoZXJlIChidXQgbm90IGluIHRoZSBzY2VuYXJpbyBkb2N1bWVudCkgdG8g ZGVzY3JpYmUNCmhvdyB0aGUgZGlmZmVyZW50IGJ1aWxkaW5nIGJsb2NrcyBhcmUgcHV0IHRvZ2V0 aGVyIHNpbmNlIHRoZXJlIGFyZSBhIGNvdXBsZQ0Kb2YgZGlmZmVyZW50IG9wdGlvbnMuIDxicj4N Cjxicj4NCkNpYW88YnI+DQpIYW5uZXM8YnI+DQo8YnI+DQpPbiBPY3QgMjQsIDIwMTEsIGF0IDEw OjIyIEFNLCB3ZWkueWlueGluZ0B6dGUuY29tLmNuIHdyb3RlOjxicj4NCjxicj4NCiZndDsgPGJy Pg0KJmd0OyBIaSwgSGFubmVzIDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDtJIHRoaW5rIHlv dSBoYXZlIGFscmVhZHkgZXhwbGFpbmVkIGl0IGNsZWFybHkuIEN1cnJlbnQgbWVjaGFuaXNtcywN CnN1Y2ggYXMgRUFQLCBHU1MtQVBJLCBTQU1MLCBBQUEoUmFkaXVzL0RpYW1ldGVyKSBhcmUgZW5v dWdoIGZvciB0aGlzIHVzZQ0KY2FzZS4gRm9yIG1lLCBUaGUgbmV4dCBzdGVwIGlzIHRvIG1ha2Ug dXNlIG9mIGV4aXN0aW5nIHRvb2xzIGRlZmluZWQgaW4NCmFiZmFiIHRvIHN1cHBvcnQgdGhpcyB1 c2UgY2FzZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tLS0tLS0gPGJyPg0KJmd0OyBZaW54aW5n IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDto YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Jmd0Ozxicj4NCiZndDsgMjAxMS8xMC8yNCAxNTowNzxi cj4NCiZndDsgPGJyPg0KJmd0OyDK1bz+yMs8YnI+DQomZ3Q7IFJoeXMgU21pdGggJmx0O3NtaXRo QENBUkRJRkYuQUMuVUsmZ3Q7PGJyPg0KJmd0OyCzrcvNPGJyPg0KJmd0OyBIYW5uZXMgVHNjaG9m ZW5pZyAmbHQ7aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCZndDssIHdlaS55aW54aW5nQHp0ZS5j b20uY24sDQprd2llcmVuZ0BjaXNjby5jb20sIGFiZmFiQGlldGYub3JnLCBoYXJ0bWFucy1pZXRm QG1pdC5lZHU8YnI+DQomZ3Q7INb3zOI8YnI+DQomZ3Q7IFJlOiBbYWJmYWJdIFBsZWFzZSByZXZp ZXcgdGhlIHVzZSBjYXNlICZxdW90OzQueCBGZWRlcmF0ZWQgQ3Jvc3MtTGF5ZXINCkFjY2VzcyZx dW90Ozxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEkgaGFkIGEgbG9vayBhdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC13ZWktYWJmYWItZmNsYS0wMA0KYW5kIHdhcyB3b25kZXJpbmcgd2hhdCBzcGVjaWZpY2Fs bHkgbmVlZHMgdG8gYmUgYWRkcmVzc2VkIGluIEFCRkFCIHRvIG1ha2UNCnVzZSBvZiB0aGUgZXhp c3RpbmcgdGVsZWNvbW11bmljYXRpb24gc3Vic2NyaWJlciBpbmZyYXN0cnVjdHVyZS4gSSBiZWxp ZXZlDQpldmVyeXRoaW5nIGlzIHN1cHBvcnRlZCBhbHJlYWR5Ljxicj4NCiZndDsgPGJyPg0KJmd0 OyBFQVAgaXMgdXNlZCBpbiBBQkZBQiAod2l0aGluIHRoZSBHU1MtQVBJKSBhbmQgdGhhdCBhbGxv d3MgYW55IGF1dGhlbnRpY2F0aW9uDQptZWNoYW5pc21zIHRvIGJlIHVzZWQsIGluY2x1ZGluZyB0 aGUgQUtBLiBUaGF0IGlzbid0IGEgcHJvYmxlbS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIHlv dSBkb24ndCB3YW50IHRvIHVzZSBBS0EgZGlyZWN0bHkgd2l0aGluIEVBUCBidXQgYWRkIGFuIGFk ZGl0aW9uYWwNCkdCQSBydW4gYmVmb3JlaGFuZCB5b3UgY2FuIGRvIHRoYXQgYXMgd2VsbC48YnI+ DQomZ3Q7IDxicj4NCiZndDsgU28sIFlpbnhpbmcgY291bGQgeW91IGV4cGxhaW4gd2hhdCBhZGRp dGlvbmFsIGZ1bmN0aW9uYWxpdHkgaXMgbmVlZD8NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBDaWFv PGJyPg0KJmd0OyBIYW5uZXM8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gT2N0IDIyLCAyMDExLCBh dCAxMDo1MSBQTSwgUmh5cyBTbWl0aCB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBI aSBZaW54aW5nLCAoY2M6ZWQgdG8gYWJmYWIgbGlzdCBmb3IgZGlzY3Vzc2lvbikuPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJJ20ganVzdCBsb29raW5nIGF0IG1ha2luZyB0aGUgbmV4 dCB2ZXJzaW9uIG9mIHRoZSB1c2UgY2FzZSBkb2N1bWVudA0KZm9yIEFCRkFCLCBhbmQgc28gSSd2 ZSBiZWVuIGxvb2tpbmcgYXQgdGhlIHVzZSBjYXNlIHlvdSBzdWdnZXN0ZWQgKGJlbG93LA0KaWYg eW91IGRvbid0IGhhdmUgYSBjb3B5IG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlIHNlbnQgdG8gdGhl IGFiZmFiIGxpc3QpLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQmFzaWNhbGx5LCBJ J3ZlIHJldmlld2VkIHRoZSBzdWdnZXN0aW9uIGFuZCBJJ20gbm90IHF1aXRlIHN1cmUNCndoYXQg dGhlIHVzZSBjYXNlIGFjdHVhbGx5IGlzPzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Rmlyc3QsIGl0IHNlZW1zIGFzIHRob3VnaCBtb3N0IGFsbCBvZiB0aGUgY29udGVudCBpbiB0aGUg dGV4dA0KeW91J3ZlIHN1Ym1pdHRlZCBzaW1wbHkgZGVzY3JpYmVzIHdoeSBmZWRlcmF0ZWQgYXV0 aGVudGljYXRpb24gaW4gZ2VuZXJhbA0KaXMgYSBnb29kIHRoaW5nIC0gdXNlciByZWdpc3RyYXRp b24gYXQgdGhlIHVzZXIncyAmcXVvdDtob21lJnF1b3Q7IGlkZW50aXR5DQpwcm92aWRlciwgYmV0 dGVyIHVzZXIgZXhwZXJpZW5jZSwgZXRjLiBJbiB5b3VyIGNhc2UsIHRoZSBtb2JpbGUgbmV0d29y aw0Kb3BlcmF0b3IgaXMgdGhlIElkUCwgYnV0IHRoZXkgd291bGQgYmUgYSBob21lIG9yZ2FuaXNh dGlvbiB0byBzb21lIHVzZXJzDQphbmQgY29uc2VxdWVudGx5IGFuIElkUCwganVzdCBsaWtlIGFu eSBvdGhlciBvcmdhbmlzYXRpb24gcGVyZm9ybWluZyB0aGUNCnNhbWUgdGFzay4gSSdtIG5vdCBh cmd1aW5nIHRoYXQgeW91J3JlIG5vdCByaWdodCBhYm91dCBmZWRlcmF0ZWQgYXV0aGVudGljYXRp b24NCmJlaW5nIGEgZ29vZCB0aGluZyAtIGJ1dCB0aGF0J3Mgbm90IHRoZSBwdXJwb3NlIG9mIHRo aXMgZG9jdW1lbnQuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBTZWNvbmQsIHRoZSBv bmUgdGhpbmcgdGhhdCBzZWVtcyBsaWtlIGl0IGNvdWxkIGJlIGRpZmZlcmVudCBhdA0KZmlyc3Qg Z2xhbmNlIGluIHlvdXIgdXNlIGNhc2UgaXMgdGhhdCB5b3UgaGF2ZSBhIGxheWVyZWQgYXJjaGl0 ZWN0dXJlIHdoZXJlDQp1c2VycyBhcmUgdXNpbmcgbW9iaWxlIGRldmljZXMsIGF0dGFjaGluZyB0 byB0aGUgbmV0d29yayB1c2luZyBzdGFuZGFyZA0KbWVhbnMsIGFuZCB0aGVuIHBlcmZvcm1pbmcg ZmVkZXJhdGVkIGF1dGhlbnRpY2F0aW9uIGZyb20gdGhlaXIgZGV2aWNlcy4NCkhvd2V2ZXIsIEkg ZG9uJ3Qgc2VlIGhvdyB0aGlzIGlzIGRpZmZlcmVudCBhdCBhbGwgLSBhcHBsaWNhdGlvbnMgdGhh dCB1c2Vycw0Kb24gdGhlaXIgbW9iaWxlIGRldmljZXMgYXJlIHVzaW5nIGNvbnRhY3QgdGhlIGhv bWUgSWRQIChpbiB0aGlzIGNhc2UgaXQNCnNvIGhhcHBlbnMgdGhlaXIgaG9tZSBJZFAgaXMgcnVu IGJ5IHRoZSBuZXR3b3JrIHByb3ZpZGVyKSBhbmQgYXV0aGVudGljYXRlDQp0aGUgdXNlciBiYXNl ZCB1cG9uIHRoYXQuIFRoYXQncyBzdGFuZGFyZCBmZWRlcmF0ZWQgYXV0aGVudGljYXRpb24sIGp1 c3QNCmZyb20gYSBtb2JpbGUgZGV2aWNlIGluc3RlYWQgb2YsIHNheSwgYSBkZXNrdG9wIG9yIGxh cHRvcC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgdGhpbmsgdGhlcmUncyBhIGdv b2QgYXJndW1lbnQgaW4gdGhlcmUgdGhhdCBtb2JpbGUgdGVsZWNvbXMNCnByb3ZpZGVycyBtaWdo dCBtYWtlIGEgZ29vZCBjbGFzcyBvZiBJZFAsIGJ1dCB1bmZvcnR1bmF0ZWx5IHRoYXQncyBub3QN CmFwcGxpY2FibGUgdG8gdGhpcyBkb2N1bWVudCwgSSBkb24ndCB0aGluay48YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBrZXkgdGhpbmcgaXMgdGhhdCBJIGRvbid0IHNlZSBhbnkg bmV3IHBhcnRpY3VsYXIgYXBwbGljYXRpb25zDQpvciB1c2UgY2FzZXMgZm9yIGZlZGVyYXRlZCBh dXRoZW50aWNhdGlvbiBpbiB5b3VyIHRleHQsIGp1c3QgYSBzbyBJJ20gc3RydWdnbGluZw0KdG8g c2VlIGhvdywgb3IgaWYsIGl0IGZpdHMgaW50byB0aGUgdXNlIGNhc2UgZG9jdW1lbnQuPGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBZaW54aW5nIC0gSWYgeW91IHRoaW5rIEknbSBtaXN1 bmRlcnN0YW5kaW5nIHlvdXIgdXNlIGNhc2UsIHBsZWFzZQ0KZG8gZ2V0IGJhY2sgaW4gdG91Y2gg YW5kIHdlIGNhbiB0cnkgdG8gZmlndXJlIG91dCB3aGF0IGl0IGlzIGFuZCBob3cgaXQNCmZpdHMg aW50byB0aGUgZG9jdW1lbnQuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBFdmVyeW9u ZSBlbHNlIC0gSWYgYW55b25lIGRpc2FncmVlcyB3aXRoIHRoaXMgKGlmIEknbSBtaXNzaW5nDQpz b21ldGhpbmcgb2J2aW91cyBoZXJlKSwgdGhlbiBwbGVhc2UgbGV0IG1lIGtub3cgd2hlcmUgSSdt IGdvaW5nIHdyb25nLi4uPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBSLjxicj4NCiZn dDsgJmd0OyAtLTxicj4NCiZndDsgJmd0OyBEciBSaHlzIFNtaXRoOiBJZGVudGl0eSwgQWNjZXNz LCBhbmQgTWlkZGxld2FyZSBTcGVjaWFsaXN0PGJyPg0KJmd0OyAmZ3Q7IENhcmRpZmYgVW5pdmVy c2l0eSAmYW1wOyBKQU5FVChVSyk8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IGVtYWls OiBzbWl0aEBjYXJkaWZmLmFjLnVrIC8gcmh5cy5zbWl0aEBqYS5uZXQ8YnI+DQomZ3Q7ICZndDsg R1BHOiAweERFMkYwMjRDPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBPbiAyIEF1ZyAy MDExLCBhdCAyMDo1Mywgd2VpLnlpbnhpbmdAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IERlYXIgUmh5cyBTbWl0 aCwgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IEFjY29yZGluZyB0byB0 aGUgYWN0aW9uIGluIElFVEYjODEsIEkgc3VtbWFyaXplZCB0aGUgdXNlDQpjYXNlIGluIDxicj4N CiZndDsgJmd0OyZndDsgZHJhZnQtd2VpLWFiZmFiLWZjbGEtMDAgYXMgYW4gaW5wdXQgdG8gZHJh ZnQtaWV0Zi1hYmZhYi11c2VjYXNlcy0wMS4NCjxicj4NCiZndDsgJmd0OyZndDsgUGxlYXNlIHJl dmlldyBpdC4gPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRoYW5rcyEg PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IFlpbnhpbmcgV2VpIDxicj4N CiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fg0KPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyA0LnguIEZlZGVyYXRlZCBDcm9zcy1MYXllciBBY2Nlc3MgPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtUZWxlY29tIG9wZXJh dG9ycyBoYXZlIGEgY29tbXVuaWNhdGlvbiBuZXR3b3JrDQppbmZyYXN0cnVjdHVyZXMgdG8gPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7cHJvdmlkZXIgdXNlcnMgd2l0aCBhIHdlYWx0 aHkgb2YgYWNjZXNzIG1ldGhvZHMuDQpUZWxlY29tIG9wZXJhdG9ycyA8YnI+DQomZ3Q7ICZndDsm Z3Q7ICZuYnNwOyAmbmJzcDtoYXZlIGEgaHVnZSBudW1iZXIgb2YgcmVnaXN0ZXJlZCB1c2Vycywg YW5kDQp0aGV5IGNhbiBwcm92aWRlIHRydXN0ZWQgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsg Jm5ic3A7aWRlbnRpdHkgYW5kIGhpZ2hlciBzZWN1cml0eS4gVGhlcmVmb3JlIHRoZXkNCmhhdmUg YSBuYXR1cmFsIGFkdmFudGFnZSA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDt0byBh Y3QgYXMgYW4gSWRlbnRpdHkgUHJvdmlkZXIgKElkUCkgdG8gc2VydmUNCmZvciBzZXJ2aWNlIHBy b3ZpZGVycy4gPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7T24gdGhlIGNvbnRyYXJ5 IG1vc3Qgc2VydmljZSBwcm92aWRlcnMgb24gdGhlDQpJbnRlcm5ldCBoYXZlIGxpbWl0ZWQgPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7YW1vdW50IG9mIHVzZXJzIGFuZCBjYW4gbm90 IGFzc3VyZSB0aGUgc2VjdXJpdHkNCm9mIHVzZXIgaWRlbnRpdHksIGJ1dCA8YnI+DQomZ3Q7ICZn dDsmZ3Q7ICZuYnNwOyAmbmJzcDt0aGV5IGNhbiBwcm92aWRlIGFidW5kYW50IGtpbmRzIG9mIHNl cnZpY2UuDQpGdXJ0aGVybW9yZSwgdXNlciBpcyA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAm bmJzcDtyZWx1Y3RhbnQgdG8gcmVnaXN0ZXIgdG9vIG1hbnkgYWNjb3VudHMgYmVjYXVzZQ0KaXQg aXMgaW5jb252ZW5pZW50IHRvIDxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwO3JlbWVt YmVyIGRvemVucyBvZiBwYXNzd29yZHMuIDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAm Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7VGVsZWNvbSBuZXR3b3JrIHN1cHBvcnRzIFdlYiBvciBub24t V2ViIGFwcGxpY2F0aW9uLg0KJm5ic3A7SW4gc29tZSBjYXNlcyA8YnI+DQomZ3Q7ICZndDsmZ3Q7 ICZuYnNwOyAmbmJzcDt1c2VyIHByZWZlcnMgdG8gY2hvb3NlIG5vbi1XZWIgYXBwbGljYXRpb24s DQplLmcuICZuYnNwO01lc3NhZ2luZyBzZXJ2aWNlLCA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNw OyAmbmJzcDtWb0lQLCBFTWFpbCBzZXJ2aWNlLCBldGMuIEJhc2VkIG9uIHRoZSByZXN1bHQNCm9m IG5ldHdvcmsgc3RyYXR1bSA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDthdXRoZW50 aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiwgVXNlciBlcXVpcG1lbnQNCihVRSkgY2FuIGFjY2Vz cyA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDthcHBsaWNhdGlvbnMgd2l0aG91dCBk b2luZyBhbm90aGVyIGF1dGhlbnRpY2F0aW9uDQphbmQgYXV0aG9yaXphdGlvbiA8YnI+DQomZ3Q7 ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtwcm9jZWR1cmUuIEluIHRoaXMgd2F5LCB0aGUgc3lzdGVt IGNhbiBpbXBsZW1lbnQNCmZlZGVyYXRlZCBjcm9zcy1sYXllciA8YnI+DQomZ3Q7ICZndDsmZ3Q7 ICZuYnNwOyAmbmJzcDthY2Nlc3MuIEZpcnN0bHkgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGlzIHBl cmZvcm1lZA0KYmV0d2VlbiBVRSBhbmQgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 TmV0d29yaywgc2Vjb25kbHkgVUUgYWNjZXNzZXMgQXBwbGljYXRpb24gYmFzZWQNCm9uIHRoZSBy ZXN1bHQgb2YgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7bmV0d29yayBzdHJhdHVt J3MgYXV0aGVudGljYXRpb24uIEluIHRoaXMgY2FzZSwNCmEgZmVkZXJhdGlvbiBpcyBmb3JtZWQg PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7YmV0d2VlbiBOZXR3b3JrIGFuZCBBcHBs aWNhdGlvbi4gVGhlIGJyaWVmIHN0ZXBzDQphcmUgYXMgZm9sbG93czogPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsxLiAmbmJzcDtXaGVuIFVFIGF0 dGFjaGVzIHRoZSBOZXR3b3JrLCBtdXR1YWwNCmF1dGhlbnRpY2F0aW9uIGlzIHBlcmZvcm1lZCA8 YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21hc3RlciBzZXNz aW9uIGtleSBpcyBjcmVhdGVkDQpiZXR3ZWVuIHRoZW0uIDxicj4NCiZndDsgJmd0OyZndDsgJm5i c3A7ICZuYnNwOzIuICZuYnNwO1VFIHZpc2l0cyBub24tV2ViIEFwcGxpY2F0aW9uLCBlLmcNCk1l c3NhZ2luZyBzZXJ2aWNlLCBWb0lQIDxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7c2VydmljZSwgb3IgRW1haWwgc2VydmljZS4gPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyAmbmJzcDsgJm5ic3A7My4gJm5ic3A7QXBwbGljYXRpb24gaGFzIG5vIGluZm9ybWF0aW9uIGFi b3V0DQp0aGUgVUUuICZuYnNwO1RoZSBBcHBsaWNhdGlvbiA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbnRhY3RzIE5ldHdvcmsgdG8gdmFsaWRhdGUgdGhl DQphdXRoZW50aWNhdGlvbiByZXN1bHQgaW4gdGhlIDxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7bmV0d29yayBzdHJhdHVtLiAmbmJzcDtBcHBsaWNhdGlvbg0K Y2FuIGZpbmQgTmV0d29yayBhY2NvcmRpbmcgdG8gdGhlIDxicj4NCiZndDsgJmd0OyZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29uZmlndXJhdGlvbiBvciBkeW5hbWljYWwgZGlzY292 ZXJ5DQpwcm90b2NvbC4gPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7NC4gJm5ic3A7 TmV0d29yayByZXNwb25kcyB0byBBcHBsaWNhdGlvbiB3aXRoDQphdXRoZW50aWNhdGlvbiByZXN1 bHQuIDxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOzUuICZuYnNwO1VFIGlzIGF1dGhv cml6ZWQgdG8gYWNjZXNzIHRoZSBBcHBsaWNhdGlvbi4NCjxicj4NCiZndDsgJmd0OyZndDsgPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7Rm9yIGZlZGVyYXRlZCBjcm9zcy1sYXllciBh Y2Nlc3MsIE5ldHdvcmsgY2FuDQphc3N1cmUgdGhlIEFwcGxpY2F0aW9uIDxicj4NCiZndDsgJmd0 OyZndDsgJm5ic3A7ICZuYnNwO29mIHRoZSBhdXRoZW50aWNpdHkgb2YgdXNlcidzIGlkZW50aXR5 LCBzaGFyZQ0Kc29tZSBvZiB1c2UgcHJvZmlsZSA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAm bmJzcDt3aXRoIEFwcGxpY2F0aW9uLiAmbmJzcDtUaGVzZSBjYW4gYnJpbmcgc29tZQ0KYmVuZWZp dHMgdG8gc3Rha2Vob2xkZXJzOiA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZn dDsgJm5ic3A7ICZuYnNwO28gJm5ic3A7Rm9yIHRlbGVjb20gb3BlcmF0b3JzLCB0aGV5IGNhbiBw cm92aWRlDQppZGVudGl0eSBzZXJ2aWNlLCB0cnVzdGVkIDxicj4NCiZndDsgJmd0OyZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgc2VjdXJpdHkgc2VydmljZSwgbW9iaWxlIHBheW1lbnQgc2Vydmlj ZQ0KYW5kIHNoYXJpbmcgc29tZSB1c2VyIDxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgcHJvZmlsZXMgYWNjb3JkaW5nIHVzZXIncyBwcmVmZXJlbmNlcy4NClRlbGVjb20g b3BlcmF0b3JzIGlzIG5vdCA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGp1c3QgcHJvdmlkaW5nIHBpcGVsaW5lIGZvciBjb21tdW5pY2F0aW9uLA0KYnV0IGFsc28gYmVj b21lIGEgcGFydCBvZiA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNl cnZpY2UgdmFsdWUgY2hhaW4gYXMgYW4gSWRlbnRpdHkgUHJvdmlkZXIuDQo8YnI+DQomZ3Q7ICZn dDsmZ3Q7ICZuYnNwOyAmbmJzcDtvICZuYnNwO0ZvciBzZXJ2aWNlIHByb3ZpZGVycywgJm5ic3A7 dGhleSBjYW4NCmZvY3VzIG9uIGNvcmUgYnVzaW5lc3MgYW5kIHJldXNlIDxicj4NCiZndDsgJmd0 OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2FwYWJpbGl0aWVzIHByb3ZpZGVkIGJ5IHRlbGVj b20gb3BlcmF0b3JzDQp3aXRob3V0IHdvcnJ5aW5nIGFib3V0IDxicj4NCiZndDsgJmd0OyZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc291cmNlcyBvZiB1c2Vycy4gPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyAmbmJzcDsgJm5ic3A7byAmbmJzcDtGb3IgZW5kIHVzZXJzLCB0aGV5IGNhbiBlbmpveSBzZWFt bGVzcw0Kc2VydmljZSBleHBlcmllbmNlcyBhbmQgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBpbXByb3ZlIHNlY3VyaXR5IGFuZCBwcml2YWN5LiA8YnI+DQomZ3Q7ICZn dDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgfn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5v dGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZA0KaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwNCmNvbW11bmlj YXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0 ZWQgdG8NCm1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzDQpjb21tdW5pY2F0aW9uIHRvIG90aGVycy48YnI+DQomZ3Q7 ICZndDsmZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFy ZSBjb25maWRlbnRpYWwNCmFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleQ0KYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZQ0Kb3JpZ2lu YXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2Ug YXJlIHRob3NlDQpvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBU aGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUN CkFudGktU3BhbSBzeXN0ZW0uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyAmZ3Q7IGFiZmFiIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyBhYmZh YkBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FiZmFiPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCm1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppcyBj b25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWlu dGFpbiBzZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRl bnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NCiZndDsgVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQN CmludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hvbSB0aGV5IGFyZQ0KYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3INCm9mIHRoZSBtZXNzYWdl LiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGlu ZGl2aWR1YWwNCnNlbmRlci48YnI+DQomZ3Q7IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0NCnN5c3RlbS48YnI+DQomZ3Q7 IDxicj4NCjxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5i c3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtp bmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJz cDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5k ZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmlj YXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFt ZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRh aW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVk Jm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJz cDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNw O2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNw O3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2lu dGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJz cDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3do b20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5i c3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtl cnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJz cDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHBy ZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2Um bmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7 bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmly dXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZu YnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 002FDECF48257933_=-- From klaas@cisco.com Mon Oct 24 02:28:39 2011 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 86A2121F8C1F for ; Mon, 24 Oct 2011 02:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.374 X-Spam-Level: X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pu5z8vbYyR0G for ; Mon, 24 Oct 2011 02:28:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 32A6221F8B9F for ; Mon, 24 Oct 2011 02:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=12067; q=dns/txt; s=iport; t=1319448518; x=1320658118; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hWE5sb8ibUXIlamXkDbJElat5OmzuqZS0sc5sz6pIDQ=; b=Z8SUB3x5NyuVa/NEso3IPTRtL46uxXlnNcEQC9lveR2MiF55Jd3eGoVj csxw/IqV2pNLc1sboAa0kHcSa358daxBnu/Kk43cQl9KEeUuZ9yiAuH0p 54yj7WCs9M5mipLCrqGUQ4dawePnomb0LFgigvlh27OxbbMb6grXomuE6 w=; X-IronPort-AV: E=Sophos;i="4.69,397,1315180800"; d="scan'208";a="30475167" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 24 Oct 2011 09:28:38 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9O9SZNJ003252; Mon, 24 Oct 2011 09:28:36 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=GB2312 From: Klaas Wierenga In-Reply-To: Date: Mon, 24 Oct 2011 11:28:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: wei.yinxing@zte.com.cn X-Mailer: Apple Mail (2.1251.1) Cc: kwiereng@cisco.com, abfab@ietf.org, hartmans-ietf@mit.edu Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" 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, 24 Oct 2011 09:28:39 -0000 On Oct 24, 2011, at 10:42 AM, wei.yinxing@zte.com.cn wrote: Hi Yinxing, >=20 > I agree with your advice.=20 > One way is to move the use case from draft-wei-abfab-fcla to = draft-ietf-abfab-usecases, and put the different options into the = draft-wei-abfab-fcla.=20 >=20 > Does it make sense?=20 yes it does. Klaas >=20 > -------=20 > Yinxing=20 >=20 >=20 > Hannes Tschofenig > 2011/10/24 16:24 >=20 > =CA=D5=BC=FE=C8=CB > wei.yinxing@zte.com.cn > =B3=AD=CB=CD > Hannes Tschofenig , abfab@ietf.org, = hartmans-ietf@mit.edu, kwiereng@cisco.com, Rhys Smith = > =D6=F7=CC=E2 > Re: [abfab] Please review the use case "4.x Federated Cross-Layer = Access" >=20 >=20 >=20 >=20 >=20 > Hi Yinxing,=20 >=20 > thanks for the quick response.=20 >=20 > It may make sense to somewhere (but not in the scenario document) to = describe how the different building blocks are put together since there = are a couple of different options.=20 >=20 > Ciao > Hannes >=20 > On Oct 24, 2011, at 10:22 AM, wei.yinxing@zte.com.cn wrote: >=20 > >=20 > > Hi, Hannes=20 > >=20 > > I think you have already explained it clearly. Current mechanisms, = such as EAP, GSS-API, SAML, AAA(Radius/Diameter) are enough for this use = case. For me, The next step is to make use of existing tools defined in = abfab to support this use case.=20 > >=20 > > -------=20 > > Yinxing=20 > >=20 > >=20 > > Hannes Tschofenig > > 2011/10/24 15:07 > >=20 > > =CA=D5=BC=FE=C8=CB > > Rhys Smith > > =B3=AD=CB=CD > > Hannes Tschofenig , = wei.yinxing@zte.com.cn, kwiereng@cisco.com, abfab@ietf.org, = hartmans-ietf@mit.edu > > =D6=F7=CC=E2 > > Re: [abfab] Please review the use case "4.x Federated Cross-Layer = Access" > >=20 > >=20 > >=20 > >=20 > >=20 > > I had a look at http://tools.ietf.org/html/draft-wei-abfab-fcla-00 = and was wondering what specifically needs to be addressed in ABFAB to = make use of the existing telecommunication subscriber infrastructure. I = believe everything is supported already. > >=20 > > EAP is used in ABFAB (within the GSS-API) and that allows any = authentication mechanisms to be used, including the AKA. That isn't a = problem.=20 > >=20 > > If you don't want to use AKA directly within EAP but add an = additional GBA run beforehand you can do that as well. > >=20 > > So, Yinxing could you explain what additional functionality is need?=20= > >=20 > > Ciao > > Hannes > >=20 > > On Oct 22, 2011, at 10:51 PM, Rhys Smith wrote: > >=20 > > > Hi Yinxing, (cc:ed to abfab list for discussion). > > >=20 > > > I'm just looking at making the next version of the use case = document for ABFAB, and so I've been looking at the use case you = suggested (below, if you don't have a copy of the original message sent = to the abfab list). > > >=20 > > > Basically, I've reviewed the suggestion and I'm not quite sure = what the use case actually is? > > >=20 > > > First, it seems as though most all of the content in the text = you've submitted simply describes why federated authentication in = general is a good thing - user registration at the user's "home" = identity provider, better user experience, etc. In your case, the mobile = network operator is the IdP, but they would be a home organisation to = some users and consequently an IdP, just like any other organisation = performing the same task. I'm not arguing that you're not right about = federated authentication being a good thing - but that's not the purpose = of this document. > > >=20 > > > Second, the one thing that seems like it could be different at = first glance in your use case is that you have a layered architecture = where users are using mobile devices, attaching to the network using = standard means, and then performing federated authentication from their = devices. However, I don't see how this is different at all - = applications that users on their mobile devices are using contact the = home IdP (in this case it so happens their home IdP is run by the = network provider) and authenticate the user based upon that. That's = standard federated authentication, just from a mobile device instead of, = say, a desktop or laptop. > > >=20 > > > I think there's a good argument in there that mobile telecoms = providers might make a good class of IdP, but unfortunately that's not = applicable to this document, I don't think. > > >=20 > > > The key thing is that I don't see any new particular applications = or use cases for federated authentication in your text, just a so I'm = struggling to see how, or if, it fits into the use case document. > > >=20 > > > Yinxing - If you think I'm misunderstanding your use case, please = do get back in touch and we can try to figure out what it is and how it = fits into the document. > > >=20 > > > Everyone else - If anyone disagrees with this (if I'm missing = something obvious here), then please let me know where I'm going = wrong... > > >=20 > > > R. > > > -- > > > Dr Rhys Smith: Identity, Access, and Middleware Specialist > > > Cardiff University & JANET(UK) > > >=20 > > > email: smith@cardiff.ac.uk / rhys.smith@ja.net > > > GPG: 0xDE2F024C > > >=20 > > > On 2 Aug 2011, at 20:53, wei.yinxing@zte.com.cn wrote: > > >=20 > > >>=20 > > >> Dear Rhys Smith,=20 > > >>=20 > > >> According to the action in IETF#81, I summarized the use case in=20= > > >> draft-wei-abfab-fcla-00 as an input to = draft-ietf-abfab-usecases-01.=20 > > >> Please review it.=20 > > >>=20 > > >> Thanks!=20 > > >>=20 > > >> Yinxing Wei=20 > > >>=20 > > >> = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=20= > > >> 4.x. Federated Cross-Layer Access=20 > > >>=20 > > >> Telecom operators have a communication network infrastructures = to=20 > > >> provider users with a wealthy of access methods. Telecom = operators=20 > > >> have a huge number of registered users, and they can provide = trusted=20 > > >> identity and higher security. Therefore they have a natural = advantage=20 > > >> to act as an Identity Provider (IdP) to serve for service = providers.=20 > > >> On the contrary most service providers on the Internet have = limited=20 > > >> amount of users and can not assure the security of user = identity, but=20 > > >> they can provide abundant kinds of service. Furthermore, user = is=20 > > >> reluctant to register too many accounts because it is = inconvenient to=20 > > >> remember dozens of passwords.=20 > > >>=20 > > >> Telecom network supports Web or non-Web application. In some = cases=20 > > >> user prefers to choose non-Web application, e.g. Messaging = service,=20 > > >> VoIP, EMail service, etc. Based on the result of network = stratum=20 > > >> authentication and authorization, User equipment (UE) can = access=20 > > >> applications without doing another authentication and = authorization=20 > > >> procedure. In this way, the system can implement federated = cross-layer=20 > > >> access. Firstly mutual authentication is performed between UE = and=20 > > >> Network, secondly UE accesses Application based on the result = of=20 > > >> network stratum's authentication. In this case, a federation = is formed=20 > > >> between Network and Application. The brief steps are as = follows:=20 > > >>=20 > > >> 1. When UE attaches the Network, mutual authentication is = performed=20 > > >> master session key is created between them.=20 > > >> 2. UE visits non-Web Application, e.g Messaging service, VoIP=20= > > >> service, or Email service.=20 > > >> 3. Application has no information about the UE. The = Application=20 > > >> contacts Network to validate the authentication result in = the=20 > > >> network stratum. Application can find Network according = to the=20 > > >> configuration or dynamical discovery protocol.=20 > > >> 4. Network responds to Application with authentication = result.=20 > > >> 5. UE is authorized to access the Application.=20 > > >>=20 > > >> For federated cross-layer access, Network can assure the = Application=20 > > >> of the authenticity of user's identity, share some of use = profile=20 > > >> with Application. These can bring some benefits to = stakeholders:=20 > > >>=20 > > >> o For telecom operators, they can provide identity service, = trusted=20 > > >> security service, mobile payment service and sharing some = user=20 > > >> profiles according user's preferences. Telecom operators is = not=20 > > >> just providing pipeline for communication, but also become = a part of=20 > > >> service value chain as an Identity Provider.=20 > > >> o For service providers, they can focus on core business and = reuse=20 > > >> capabilities provided by telecom operators without worrying = about=20 > > >> sources of users.=20 > > >> o For end users, they can enjoy seamless service experiences = and=20 > > >> improve security and privacy.=20 > > >>=20 > > >> = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~ > > >> -------------------------------------------------------- > > >> ZTE Information Security Notice: The information contained in = this mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > > >> This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > > >> This message has been scanned for viruses and Spam by ZTE = Anti-Spam system. > > >>=20 > > >=20 > > > _______________________________________________ > > > abfab mailing list > > > abfab@ietf.org > > > https://www.ietf.org/mailman/listinfo/abfab > >=20 > >=20 > >=20 > >=20 > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. > >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. >=20 From leifj@mnt.se Mon Oct 24 06:15:13 2011 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 5EE5A21F8D77 for ; Mon, 24 Oct 2011 06:15: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjeCGDDnGbwx for ; Mon, 24 Oct 2011 06:15:12 -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 5FA9721F8D74 for ; Mon, 24 Oct 2011 06:15:12 -0700 (PDT) Received: from [212.25.132.67] ([212.25.132.67]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9ODF5H1018510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Oct 2011 15:15:10 +0200 (CEST) Message-ID: <4EA564D9.4010801@mnt.se> Date: Mon, 24 Oct 2011 15:15:05 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Please review the use case "4.x Federated Cross-Layer Access" 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, 24 Oct 2011 13:15:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/24/2011 11:28 AM, Klaas Wierenga wrote: > > On Oct 24, 2011, at 10:42 AM, wei.yinxing@zte.com.cn wrote: > > Hi Yinxing, > >> >> I agree with your advice. >> One way is to move the use case from draft-wei-abfab-fcla to draft-ietf-abfab-usecases, and put the different options into the draft-wei-abfab-fcla. >> >> Does it make sense? > > yes it does. I'm assuming we're talking about keeping draft-wei-abfab-fcla an individual submission then? Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6lZNUACgkQ8Jx8FtbMZndHmgCfceOR6s6InT7BSoErliF423CO oF4An3x9nSlAC0wdSWIabZm/3Be/jIR6 =OffB -----END PGP SIGNATURE----- From hartmans@painless-security.com Wed Oct 26 06:39:49 2011 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 9C25321F8AEC for ; Wed, 26 Oct 2011 06:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNWt5OiMz2Cd for ; Wed, 26 Oct 2011 06:39:49 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1712721F8AB0 for ; Wed, 26 Oct 2011 06:39:48 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9DF3720424 for ; Wed, 26 Oct 2011 09:40:40 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2A4CD4239; Wed, 26 Oct 2011 09:39:35 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Wed, 26 Oct 2011 09:39:35 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [abfab] Sample GSSEAP token 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, 26 Oct 2011 13:39:49 -0000 --=-=-= Hi,. Attached please find an example token to demonstrate the layout. The OID will obviously change once we resolve the open protocol issues and confirm what the new OID means. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Mon, 24 Oct 2011 18:23:29 -0400 X-Sieve: CMU Sieve 2.2 Received: from snt0-omc1-s7.snt0.hotmail.com (snt0-omc1-s7.snt0.hotmail.com [65.55.90.18]) by mail.suchdamage.org (Postfix) with ESMTP id 70FD4202C9; Mon, 24 Oct 2011 18:23:27 -0400 (EDT) Received: from SNT101-DS22 ([65.55.90.8]) by snt0-omc1-s7.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 15:22:17 -0700 X-Originating-IP: [108.7.232.64] X-Originating-Email: [krwasserman@hotmail.com] Message-ID: From: "Kevin Wasserman" To: "Sam Hartman" Cc: References: <20111021163859.3EB8D4239@carter-zimmerman.suchdamage.org> In-Reply-To: <20111021163859.3EB8D4239@carter-zimmerman.suchdamage.org> Subject: GSSEAP initiator context token hexdump ascii diagram Date: Mon, 24 Oct 2011 18:22:14 -0400 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-OriginalArrivalTime: 24 Oct 2011 22:22:17.0281 (UTC) FILETIME=[63709310:01CC929B] X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Oct 24 18:23:29 2011 X-DSPAM-Confidence: 0.5370 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,4ea5e561229281336617527 X-DSPAM-Factors: 27, From*"Kevin Wasserman" , 0.00010, References*zimmerman.suchdamage.org>, 0.00038, References*carter+zimmerman.suchdamage.org>, 0.00038, References*carter, 0.00038, From*, 0.00050, To*painless, 0.00169, X-OriginalArrivalTime*24, 0.00481, To*security.com>, 0.00486, To*painless+security.com>, 0.00486, To* 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 AE91521F8610 for ; Fri, 28 Oct 2011 14:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvqYc9Z0H-3w for ; Fri, 28 Oct 2011 14:35:50 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id C4C0021F85F7 for ; Fri, 28 Oct 2011 14:35:49 -0700 (PDT) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (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 7CD7A38F48; Fri, 28 Oct 2011 14:35:49 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 28 Oct 2011 14:35:21 -0700 Message-ID: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AcyVuSM9IgVK3HdiR5SDQEXsLZR1iw== Cc: abfab@ietf.org Subject: [abfab] Review on gss-eap-03 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, 28 Oct 2011 21:35:50 -0000 Here are some quick comments on the -03 draft. Jim In section 1.2 - should disucss reliablity requriements in the event that you are an EAP passthrough authenticator in last paragraph Is the ABNF for "name" still wrong? section 3.4 missing Section 4 - does/should the application get any control ovret the set of allowable EAP methods to be used or is that purely a fucntion of your GSS-API library For consistency the paragraph: Tokens from the initiator to acceptor use an outer token type of 06 01; tokens from acceptor to initiator use an outer token type of 06 02. These token types are registered in the registry of RFC 4121 token types; see Section 8.1. should refer to the "token ID" rather than the "outer token type" either that or the item in the table should be updated. section 5.2 refers to "token type" - I think that maybe this is the most constant phrase to be used. I will say that this version did harmonize and make the token naming scheme much more consistent and readable. I think this is a big improvement. s/secondsubtoken/second subtoken/ (in the table) Section 5.3 - Is there going to be a rule that you should send two error subtokens in the even t\the length is greater than 8? I can understand saying you should ignore the extended bytes but should you really ignore the error code itself? Section 5.4 - you have different names for the acceptor name subtokens in the description of what is permitted and the actual subtoken names - I think you might want to harmonize this. Is there a rason that the EAP request subtoken is not documented in section 5.4 since it is a required subtoken from in the Initial State message from the acceptor? Section 5.4.1 - I realize this is a debugging string (Vender Subtoken) but is there any reason in this day and age not make it a UTF8 string? (Other than it is not one for Kerbros) Section 5.4.3 - Should something be said about what the acceptor should do if the initiator sends an acceptor name which is not completely correct for the specific acceptor. I am thinking specifically of things like adding a host name or adding some service specifics to the acceptor name. Is this permitted? Or is this and error condition or since this is typically not sent is the acceptor name from the client to be used in all events. (unless totally wrong) para #2 s/this token/This token/ Section 5.5 s/ACCEPTOR/acceptor/ The first bullet of this section is causing me some mental problems. The acceptor cannot confirm that the protected result and the final result are consistent - this is hidden from the acceptor. --- or you need to be passing the protected result as a RADIUS attribute, at which point it is not really protected anymore. The acceptor can confirm that a key has been delivered to it, but it does not know the source of the key - i.e. was it derived or just transmitted inside of the EAP session. Should the acceptor or the initiator send the error subtoken - or should the acceptor be looking for clear EAP messages and generate a failure? I think you need to carefully re-read the section and verify that you think it is correct. Setion 5.6 - Please tell me which type of channel binding I am getting at this point. (I know it is GSS-API channel binding, but given that two different types are discussed in the document I think being explcit would be good.) Section 6 - Is the KMSK in the "Tn = " line supposed to be GMSK? Section 6.1 - I am unclear what the extension option field is referring to please clarify. From lukeh@padl.com Fri Oct 28 15:18:14 2011 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 4631011E8088 for ; Fri, 28 Oct 2011 15:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42xrSyyWfXUf for ; Fri, 28 Oct 2011 15:18:13 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id ADFEB11E807F for ; Fri, 28 Oct 2011 15:18:13 -0700 (PDT) Received: by us.padl.com with ESMTP id p9SMHknw032500; Fri, 28 Oct 2011 18:17:48 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> Date: Sat, 29 Oct 2011 09:17:45 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C892B86-9249-4400-8062-13B52F9023FF@padl.com> References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1251.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: draft-ietf-abfab-gss-eap-authors@ietf.org, abfab@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 28 Oct 2011 22:18:14 -0000 > Section 4 - does/should the application get any control ovret the set = of > allowable EAP methods to be used or is that purely a fucntion of your > GSS-API library That's a good question. The application can select which GSS EAP = variants (i.e. encryption type) using GSS_Set_neg_mechs (RFC 4178). But = I'm not sure how the application might select EAP methods. Sounds like = something we could make a settable attribute on either the credential or = context object. > Is there going to be a rule that you should send two error = subtokens > in the even t\the length is greater than 8? I can understand saying = you > should ignore the extended bytes but should you really ignore the = error code > itself? This doesn't sound right, there should be a single error token, extra = bytes are ignored for extensibility. > Section 5.4.1 - I realize this is a debugging string (Vender Subtoken) = but > is there any reason in this day and age not make it a UTF8 string? = (Other > than it is not one for Kerbros) Makes sense. > Section 5.4.3 - Should something be said about what the acceptor = should do > if the initiator sends an acceptor name which is not completely = correct for > the specific acceptor. I am thinking specifically of things like = adding a > host name or adding some service specifics to the acceptor name. Is = this > permitted? Or is this and error condition or since this is typically = not > sent is the acceptor name from the client to be used in all events. = (unless > totally wrong) Also, given the entire exchange is not protected, what are the security = implications given the acceptor name is vulnerable to a MITM? Should we = send a MIC of it in the last token? > Setion 5.6 - Please tell me which type of channel binding I am getting = at > this point. (I know it is GSS-API channel binding, but given that two > different types are discussed in the document I think being explcit = would be > good.) Being explicit in every instance would be useful, I agree, because it is = very confusing when you first start to understand this protocol. -- Luke= From nico@cryptonector.com Fri Oct 28 16:02:06 2011 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 CAA2C1F0C43 for ; Fri, 28 Oct 2011 16:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o+kXuI-PClw for ; Fri, 28 Oct 2011 16:02:06 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCFB1F0C34 for ; Fri, 28 Oct 2011 16:02:06 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id E095C428079; Fri, 28 Oct 2011 16:02:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=qBvW3RRg6UfP+fbGsyvgtRmgx0hSGBvYSgoDy5ocsTU0 DV0CbnBCMM8z8MlEmWUKr/LcIxXkR2MrsYnhKgo/1BpOxtpWCqFxzKjH1S/e2tzp EcjOPM7psHuwlocpWDWwF/BPjYo/bty4+2DxMXsduRfLkTsQNyAY2eQKMZcCtM0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=ZtRHY0luapFvW/LkD9UW5x815LI=; b=ch0/3421MEL VlEOyB9fgI1sTaBn/5Uq4uJIDW87mUhFoUQwwfFll61EswNX09RsJZe+PvADgVlN 60UiJe9hjvf7EQIhCK28okhOpfFn+dBqCNZRNJa9OdyqpRGdkVaBqNAB6KNbg5Tv CYKQ9cOgLdx4N82qolMb2ioYWR0QLRGc= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id BC2B7428076; Fri, 28 Oct 2011 16:02:05 -0700 (PDT) Received: by pzk34 with SMTP id 34so11068062pzk.9 for ; Fri, 28 Oct 2011 16:02:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.12.199 with SMTP id a7mr6446742pbc.58.1319842924939; Fri, 28 Oct 2011 16:02:04 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Fri, 28 Oct 2011 16:02:04 -0700 (PDT) In-Reply-To: <6C892B86-9249-4400-8062-13B52F9023FF@padl.com> References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> <6C892B86-9249-4400-8062-13B52F9023FF@padl.com> Date: Fri, 28 Oct 2011 18:02:04 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org, Jim Schaad , draft-ietf-abfab-gss-eap-authors@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 28 Oct 2011 23:02:06 -0000 On Fri, Oct 28, 2011 at 5:17 PM, Luke Howard wrote: >> Section 4 - does/should the application get any control ovret the set of >> allowable EAP methods to be used or is that purely a fucntion of your >> GSS-API library > > That's a good question. The application can select which GSS EAP variants= (i.e. encryption type) using GSS_Set_neg_mechs (RFC 4178). But I'm not sur= e how the application might select EAP methods. Sounds like something we co= uld make a settable attribute on either the credential or context object. Oh, two-level negotiation. I've wondered before about this. We in the SASL/GSS community have grown to dislike two-level negotiations very much. The primary issue relates to cryptographic strength. I expect GSS-EAP to not imply a two-level negotiation for per-msg token enctypes. But a two-level negotiation for authentication would not exactly be great. IHow about an option of OID per EAP method, and an OID for the variant that will negotiate any EAP method? Nico -- From lukeh@padl.com Fri Oct 28 16:05:39 2011 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 B80521F0C43 for ; Fri, 28 Oct 2011 16:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Cu9Q+U8g4VV for ; Fri, 28 Oct 2011 16:05:39 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 0220D11E8088 for ; Fri, 28 Oct 2011 16:05:38 -0700 (PDT) Received: by us.padl.com with ESMTP id p9SN5UHP032323; Fri, 28 Oct 2011 19:05:33 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Sat, 29 Oct 2011 10:05:30 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> <6C892B86-9249-4400-8062-13B52F9023FF@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1251.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org, Jim Schaad , draft-ietf-abfab-gss-eap-authors@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 28 Oct 2011 23:05:39 -0000 > How about an option of OID per EAP method, and an OID for the variant > that will negotiate any EAP method? So NxM OIDs, where N is the |enctypes| and M |EAP mechanisms|? Sounds a = bit ugly... -- Luke= From nico@cryptonector.com Fri Oct 28 16:08:28 2011 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 DDB181F0C52 for ; Fri, 28 Oct 2011 16:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLYC5KSuDI24 for ; Fri, 28 Oct 2011 16:08:28 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4C62D1F0C4A for ; Fri, 28 Oct 2011 16:08:28 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id F22161F0089; Fri, 28 Oct 2011 16:08:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=w83k96UADBlrb3k3UxaS6 V0FuFl75RVIeKGiAKn9l3AoCNrrHpowXLirQN0qnaxz+TudAZ5NnM3z8JpUyu40N N5jLIIESO2Kvyve9I70uNJ+hG203U4ZZOwC0wLpKMLKeQ2Rei44WalrgTv1oxq5R pZZmzQm4cwSrajZrpH6TJo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=IN7izxE4fNbD7xpYczZU S9aLxmA=; b=GiFfmiGNnDavjuFdrM/ka4njIRmgI9O3ax4r5bLRbP6doPxk0jLP IEq4CSpEVJSkBQhbD7qfk0OZM9ONiaKvIdd/+WFq58WLpf9wiwL+lKHCFT3uJSga owIO15N1wR3YRemoHO71zmddVsE0oAh98REW1faTgnDTFUfS2AuBohE= Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id BFE571F0087; Fri, 28 Oct 2011 16:08:27 -0700 (PDT) Received: by ggnv1 with SMTP id v1so4813411ggn.31 for ; Fri, 28 Oct 2011 16:08:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.129 with SMTP id h1mr6480586pbj.92.1319843306898; Fri, 28 Oct 2011 16:08:26 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Fri, 28 Oct 2011 16:08:26 -0700 (PDT) In-Reply-To: References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> <6C892B86-9249-4400-8062-13B52F9023FF@padl.com> Date: Fri, 28 Oct 2011 18:08:26 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org, Jim Schaad , draft-ietf-abfab-gss-eap-authors@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 28 Oct 2011 23:08:29 -0000 On Fri, Oct 28, 2011 at 6:05 PM, Luke Howard wrote: >> How about an option of OID per EAP method, and an OID for the variant >> that will negotiate any EAP method? > > > So NxM OIDs, where N is the |enctypes| and M |EAP mechanisms|? Sounds a bit ugly... N = 1 for now. But, yeah. I don't really mind this. From lukeh@padl.com Fri Oct 28 16:10:58 2011 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 BB1F021F853A for ; Fri, 28 Oct 2011 16:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhNT5siJD9h1 for ; Fri, 28 Oct 2011 16:10:58 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3FB21F8531 for ; Fri, 28 Oct 2011 16:10:50 -0700 (PDT) Received: by us.padl.com with ESMTP id p9SNAhmo028522; Fri, 28 Oct 2011 19:10:45 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Sat, 29 Oct 2011 10:10:42 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> <6C892B86-9249-4400-8062-13B52F9023FF@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1251.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org, Jim Schaad , draft-ietf-abfab-gss-eap-authors@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 28 Oct 2011 23:10:58 -0000 >> So NxM OIDs, where N is the |enctypes| and M |EAP mechanisms|? Sounds = a bit ugly... >=20 > N =3D 1 for now. 2: AES-128 and AES-256. > But, yeah. I don't really mind this. I suppose if it's done dynamically, it's not so bad... -- Luke= From nico@cryptonector.com Fri Oct 28 16:30:37 2011 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 0092D1F0C43 for ; Fri, 28 Oct 2011 16:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZV0vUq0bceL for ; Fri, 28 Oct 2011 16:30:36 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id AB0071F0C3D for ; Fri, 28 Oct 2011 16:30:32 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 4517D43807C; Fri, 28 Oct 2011 16:30:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=IzFfTgPX+hzjBbLeRnTo4DA2Tdx8w+3Fv9Ea+ynSbPp4 3nLnMcjov+nDAstYLAEvwuhw1bPOvsPfrF2MBq04XEpytUqAIBUNh52WP43lh5dg /PVdekYA3AdVKvuW+P6SEywOZMamK8njtJXbojzm3LuKCUMRgrsaQ9ukaFGSAyo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=xzlyFxBfqVDRjJER9Hzz4XNlSHw=; b=ny0EnXhC0Sp pSXtpAOHrI9ClCzCqVEx43oLmGoPAX2vATKmdo+edOmpTouhTUz9CbQExgnYVh86 bpHeeitlZmXx8ReRwiVcLT9DCFOT6ik9ihHt60huP/lovF2AM4eOX6T2EeNqQy8S A/YA+44QM3HNQDHGYZN6o+2+DrLrZhBk= Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 0DA2C438072; Fri, 28 Oct 2011 16:30:31 -0700 (PDT) Received: by gyh20 with SMTP id 20so4865308gyh.31 for ; Fri, 28 Oct 2011 16:30:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.102 with SMTP id h6mr6593863pbq.7.1319844631092; Fri, 28 Oct 2011 16:30:31 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Fri, 28 Oct 2011 16:30:31 -0700 (PDT) In-Reply-To: References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> <6C892B86-9249-4400-8062-13B52F9023FF@padl.com> Date: Fri, 28 Oct 2011 18:30:31 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org, Jim Schaad , draft-ietf-abfab-gss-eap-authors@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 28 Oct 2011 23:30:37 -0000 On Fri, Oct 28, 2011 at 6:10 PM, Luke Howard wrote: >>> So NxM OIDs, where N is the |enctypes| and M |EAP mechanisms|? Sounds a= bit ugly... >> >> N =3D 1 for now. > > 2: AES-128 and AES-256. > >> But, yeah. =C2=A0I don't really mind this. > > I suppose if it's done dynamically, it's not so bad... Using mech attrs APIs it can be pretty easy, methinks! From ietf@augustcellars.com Fri Oct 28 18:19:06 2011 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 969F711E8091 for ; Fri, 28 Oct 2011 18:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnPi0-57x400 for ; Fri, 28 Oct 2011 18:19:06 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id D81CF11E8088 for ; Fri, 28 Oct 2011 18:19:05 -0700 (PDT) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (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 6BF722C9FE; Fri, 28 Oct 2011 18:19:05 -0700 (PDT) From: "Jim Schaad" To: "'Nico Williams'" , "'Luke Howard'" References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> <6C892B86-9249-4400-8062-13B52F9023FF@padl.com> In-Reply-To: Date: Fri, 28 Oct 2011 18:18:36 -0700 Message-ID: <014e01cc95d8$af683b20$0e38b160$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQETpEEniQkn/k2uDh7nlzFmlDNLFgGokef2AjAV6u6W5aNZMA== Cc: draft-ietf-abfab-gss-eap-authors@ietf.org, abfab@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 29 Oct 2011 01:19:06 -0000 > -----Original Message----- > From: Nico Williams [mailto:nico@cryptonector.com] > Sent: Friday, October 28, 2011 4:02 PM > To: Luke Howard > Cc: Jim Schaad; draft-ietf-abfab-gss-eap-authors@ietf.org; = abfab@ietf.org > Subject: Re: [abfab] Review on gss-eap-03 >=20 > On Fri, Oct 28, 2011 at 5:17 PM, Luke Howard wrote: > >> Section 4 - does/should the application get any control ovret the = set > >> of allowable EAP methods to be used or is that purely a fucntion of > >> your GSS-API library > > > > That's a good question. The application can select which GSS EAP = variants > (i.e. encryption type) using GSS_Set_neg_mechs (RFC 4178). But I'm not = sure > how the application might select EAP methods. Sounds like something we > could make a settable attribute on either the credential or context = object. >=20 > Oh, two-level negotiation. I've wondered before about this. We in = the > SASL/GSS community have grown to dislike two-level negotiations very > much. The primary issue relates to cryptographic strength. I expect = GSS-EAP > to not imply a two-level negotiation for per-msg token enctypes. But = a two- > level negotiation for authentication would not exactly be great. I don't think that is an issue for this. I would assume that the EAP = method is going to be required to generate enough bytes for the selected = GSS-API key derivation function. >=20 > IHow about an option of OID per EAP method, and an OID for the variant = that > will negotiate any EAP method? >=20 > Nico > -- From ietf@augustcellars.com Fri Oct 28 18:21:15 2011 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 9271F11E8088 for ; Fri, 28 Oct 2011 18:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOoQVBoWdEIy for ; Fri, 28 Oct 2011 18:21:15 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9499711E8081 for ; Fri, 28 Oct 2011 18:21:12 -0700 (PDT) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (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 6B51938F07; Fri, 28 Oct 2011 18:21:12 -0700 (PDT) From: "Jim Schaad" To: "'Luke Howard'" , "'Nico Williams'" References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> <6C892B86-9249-4400-8062-13B52F9023FF@padl.com> In-Reply-To: Date: Fri, 28 Oct 2011 18:20:44 -0700 Message-ID: <014f01cc95d8$fb1a2150$f14e63f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQETpEEniQkn/k2uDh7nlzFmlDNLFgGokef2AjAV6u4CHpK6a5bUrxMQ Cc: draft-ietf-abfab-gss-eap-authors@ietf.org, abfab@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 29 Oct 2011 01:21:15 -0000 > -----Original Message----- > From: Luke Howard [mailto:lukeh@padl.com] > Sent: Friday, October 28, 2011 4:06 PM > To: Nico Williams > Cc: Jim Schaad; draft-ietf-abfab-gss-eap-authors@ietf.org; abfab@ietf.org > Subject: Re: [abfab] Review on gss-eap-03 > > > How about an option of OID per EAP method, and an OID for the variant > > that will negotiate any EAP method? > > > So NxM OIDs, where N is the |enctypes| and M |EAP mechanisms|? Sounds > a bit ugly... I think it might get even uglier which is why I hesitated to mention it. You might say that you require to use of the new EAP-TLS-Tunnel method (and might want to say something about the cert domain although that is probably derived from the credential) and then want to specify that a machine and user EAP method need to be run inside of the tunnel. This starts making the array huge. Jim > > -- Luke= From hartmans@painless-security.com Sat Oct 29 08:08:27 2011 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 8031521F8713 for ; Sat, 29 Oct 2011 08:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShxTsE30pPIc for ; Sat, 29 Oct 2011 08:08:27 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 147E221F8515 for ; Sat, 29 Oct 2011 08:08:26 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0405B20383; Sat, 29 Oct 2011 11:09:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4797B435A; Sat, 29 Oct 2011 11:08:22 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> <6C892B86-9249-4400-8062-13B52F9023FF@padl.com> Date: Sat, 29 Oct 2011 11:08:22 -0400 In-Reply-To: (Nico Williams's message of "Fri, 28 Oct 2011 18:02:04 -0500") 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, draft-ietf-abfab-gss-eap-authors@ietf.org, Jim Schaad Subject: Re: [abfab] Review on gss-eap-03 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, 29 Oct 2011 15:08:27 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Fri, Oct 28, 2011 at 5:17 PM, Luke Howard wrote: >>> Section 4 - does/should the application get any control ovret >>> the set of allowable EAP methods to be used or is that purely a >>> fucntion of your GSS-API library >> >> That's a good question. The application can select which GSS EAP >> variants (i.e. encryption type) using GSS_Set_neg_mechs (RFC >> 4178). But I'm not sure how the application might select EAP >> methods. Sounds like something we could make a settable attribute >> on either the credential or context object. Nico> Oh, two-level negotiation. I've wondered before about this. Nico> We in the SASL/GSS community have grown to dislike two-level Nico> negotiations very much. The primary issue relates to Nico> cryptographic strength. I expect GSS-EAP to not imply a Nico> two-level negotiation for per-msg token enctypes. But a Nico> two-level negotiation for authentication would not exactly be Nico> great. Please see the discussion in section 4. I thought we already had consensus on this approach even though it was a Nico> two-level approach. If we do I am not in favor of opening it again. Nico> IHow about an option of OID per EAP method, and an OID for the Nico> variant that will negotiate any EAP method? The main problem with this is that the acceptor does not choose or influence the EAP method. The EAP method is a factor of what identity is chosen. IT's like proposing an OID for kerberos plus a particular preauth type. --Sam From hartmans@painless-security.com Sun Oct 30 16:20:29 2011 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 6EF8621F8BF9 for ; Sun, 30 Oct 2011 16:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7bcydhFTwju for ; Sun, 30 Oct 2011 16:20:28 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6C97421F8BE9 for ; Sun, 30 Oct 2011 16:20:27 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4FF8920439; Sun, 30 Oct 2011 19:21:22 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 601AB435A; Sun, 30 Oct 2011 19:20:18 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> Date: Sun, 30 Oct 2011 19:20:18 -0400 In-Reply-To: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> (Jim Schaad's message of "Fri, 28 Oct 2011 14:35:21 -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: draft-ietf-abfab-gss-eap-authors@ietf.org, abfab@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 30 Oct 2011 23:20:29 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> Is the ABNF for "name" still wrong? I don't think so. What problem or oddity do you see? Hmm. I see that realm is only permitted if host is present. I think I've fixed that. I think it's correct now in 04. Jim> section 3.4 missing Jim> Section 4 - does/should the application get any control ovret Jim> the set of allowable EAP methods to be used or is that purely a Jim> fucntion of your GSS-API library Currently no mechanism is provided for an application to enfluence this. A mechanism probably should have system-level policy configuration. A mechanism could expose a credential option on the initiator. If we ever need to standardize a credential option we can, but I don't see a need for that now. Jim> For consistency the paragraph: Tokens from the initiator to Jim> acceptor use an outer token type of 06 01; tokens from acceptor Jim> to initiator use an outer token type of 06 02. These token Jim> types are registered in the registry of RFC 4121 token types; Jim> see Section 8.1. My understanding is that the ID describes which type of token (token type) we are dealing with. So, I've phrased it as token s with from acceptor to initiator use an inner token type with ID xxx. 1) token type with ID and 2) inner not outer Jim> should refer to the "token ID" rather than the "outer token Jim> type" either that or the item in the table should be updated. Jim> section 5.2 refers to "token type" - I think that maybe this is Jim> the most constant phrase to be used. I've updated the registry to talk about token type identifiers. Jim> I will say that this version did harmonize and make the token Jim> naming scheme much more consistent and readable. I think this Jim> is a big improvement. Great! Jim> s/secondsubtoken/second subtoken/ (in the table) Jim> Section 5.3 - Is there going to be a rule that you should send Jim> two error subtokens in the even t\the length is greater than 8? Jim> I can understand saying you should ignore the extended bytes Jim> but should you really ignore the error code itself? In 04 we have initiators MUST ignore octets beyond the GSS EAP error code for future extensibility. Thanks for the catch. Jim> Section 5.4 - you have different names for the acceptor name Jim> subtokens in the description of what is permitted and the Jim> actual subtoken names - I think you might want to harmonize Jim> this. Jim> Is there a rason that the EAP request subtoken is not Jim> documented in section 5.4 since it is a required subtoken from Jim> in the Initial State message from the acceptor? I've added a reference. However I think it's better to document EAP request and response near each other. Note that if we adopt the proposal to reduce a round trip this subtoken goes away from initial state. Jim> Section 5.4.1 - I realize this is a debugging string (Vender Jim> Subtoken) but is there any reason in this day and age not make Jim> it a UTF8 string? (Other than it is not one for Kerbros) It doesn't exist for Kerberos (which has no vendor string I'm aware of) so I don't think that's a concern. I've made it UTF-8; I don't care. Jim> Section 5.4.3 - Should something be said about what the Jim> acceptor should do if the initiator sends an acceptor name Jim> which is not completely correct for the specific acceptor. I Jim> am thinking specifically of things like adding a host name or Jim> adding some service specifics to the acceptor name. Is this Jim> permitted? Or is this and error condition or since this is Jim> typically not sent is the acceptor name from the client to be Jim> used in all events. (unless totally wrong) I think you mean 5.4.2 not 5.4.3? My assumption is that you need to send a superset of what the acceptor expects, else things will fail at channel binding. I think you want to leave it to channel binding to fail unless an IDP wants to implement some form of aliasing. Jim> para #2 s/this token/This token/ Jim> Section 5.5 s/ACCEPTOR/acceptor/ Jim> The first bullet of this section is causing me some mental Jim> problems. The acceptor cannot confirm that the protected Jim> result and the final result are consistent - this is hidden Jim> from the acceptor. --- or you need to be passing the protected Jim> result as a RADIUS attribute, at which point it is not really Jim> protected anymore. For combined authenticators the acceptor can and should evaluate the protected result. For pass-through authenticators the acceptor should confirm there's AAA success if there is EAP success. Jim> The acceptor can confirm that a key has been delivered to it, Jim> but it does not know the source of the key - i.e. was it Jim> derived or just transmitted inside of the EAP session. Here, we mean the security claim discussed in section 7.10 of RFC 3748, which probably includes transmitting a key. Their term, not mine. I've added a reference. Jim> Should the acceptor or the initiator send the error subtoken - Jim> or should the acceptor be looking for clear EAP messages and Jim> generate a failure? I don't understand. Jim> I think you need to carefully re-read the section and verify Jim> that you think it is correct. I think it is consistent with what EAP does and what our implementation does. There are some disadvantages to how EAP handles failures. We can discuss at IETF 82 if you like. Jim> Setion 5.6 - Please tell me which type of channel binding I am Jim> getting at this point. (I know it is GSS-API channel binding, Jim> but given that two different types are discussed in the Jim> document I think being explcit would be good.) Also added a forward reference. Jim> Section 6 - Is the KMSK in the "Tn = " line supposed to be Jim> GMSK? Yes. Jim> Section 6.1 - I am unclear what the extension option field is Jim> referring to please clarify. This was all wrong and has been fixed. Thanks for the reality check. From nico@cryptonector.com Sun Oct 30 16:34:09 2011 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 5A6B111E808A for ; Sun, 30 Oct 2011 16:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSEOGfxsTvYB for ; Sun, 30 Oct 2011 16:34:08 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id C125411E8083 for ; Sun, 30 Oct 2011 16:34:08 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 77A019406E; Sun, 30 Oct 2011 16:34:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=FpHlhT0gPC8JgsW8W7iqCAxtqbb9N/lypKHCrdS+S9OD KX3wybkO1w4m+YAKg5peN7tD/2jZGxLT612d5EOTKGv/nMcmBvqtQ6lci37l2Fwh j/etv5VWuvFi2tgxjdigOGCVtRm7dTMWUZDoomLiiqf2sgNuLQNPWmGvzfU58bs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=MiWFNubSAXiVPx7hEq5TMcdlzeo=; b=uZm4jMWh6cp sDfvulqblYG//g3+KtzPOB6MfPbo15sa/Fclzarp9gL68Qf633WJaoeoaC1aBQEh eRwoohtPBppivmaYVee/ZkUif9FuuIP/UjSpZ2cmBa+gFzVGkiDFXe0n/PeQgvbp OJMfjMcmu9Sn8/IV6vN2bf0lrxHP85vU= Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 43B479406B; Sun, 30 Oct 2011 16:34:08 -0700 (PDT) Received: by gyh20 with SMTP id 20so6411916gyh.31 for ; Sun, 30 Oct 2011 16:34:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.12.199 with SMTP id a7mr19246165pbc.58.1320017647392; Sun, 30 Oct 2011 16:34:07 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Sun, 30 Oct 2011 16:34:07 -0700 (PDT) In-Reply-To: References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> Date: Sun, 30 Oct 2011 18:34:07 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org, Jim Schaad , draft-ietf-abfab-gss-eap-authors@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 30 Oct 2011 23:34:09 -0000 On Sun, Oct 30, 2011 at 6:20 PM, Sam Hartman wrote: >>>>>> "Jim" =3D=3D Jim Schaad writes: > =C2=A0 =C2=A0Jim> Section 4 - does/should the application get any control= ovret > =C2=A0 =C2=A0Jim> the set of allowable EAP methods to be used or is that = purely a > =C2=A0 =C2=A0Jim> fucntion of your GSS-API library > > Currently no mechanism is provided for an application to enfluence this. > A mechanism probably should have system-level policy configuration. > A mechanism could expose a credential option on the initiator. > If we ever need to standardize a credential option we can, but I don't > see a need for that now. I think Luke suggested using the SPNEGO gss_get/set_neg_mechs() functions for this. I.e., you could treat GSS-EAP as a mechanism-negotiation mechanism, sort of. Of course, the way these functions work we'll need something better in the case of SPNEGO being used to negotiate GSS-EAP. We really need a notion of credentials acquired with credentials, so that we can first acquire a credential handle for GSS-EAP, set what methods it will negotiate, then pass *that* credential handle to another function for acquiring a larger credential set. In other words, we need a new credential set model for GSS, and the best thing to do for now is to punt. I don't see configuration as being satisfactory for this in the long-term. Nico -- From lukeh@padl.com Sun Oct 30 16:38:19 2011 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 B36A511E808A for ; Sun, 30 Oct 2011 16:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSYswtAYZObY for ; Sun, 30 Oct 2011 16:38:19 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC6311E8083 for ; Sun, 30 Oct 2011 16:38:19 -0700 (PDT) Received: by us.padl.com with ESMTP id p9UNc96N032431; Sun, 30 Oct 2011 19:38:12 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Mon, 31 Oct 2011 10:38:09 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <0F6C0A48-5AA6-4E55-98AA-6B44F276AEDB@padl.com> References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> To: Nico Williams X-Mailer: Apple Mail (2.1251.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org, draft-ietf-abfab-gss-eap-authors@ietf.org, Jim Schaad Subject: Re: [abfab] Review on gss-eap-03 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, 30 Oct 2011 23:38:19 -0000 > I think Luke suggested using the SPNEGO gss_get/set_neg_mechs() > functions for this. I.e., you could treat GSS-EAP as a I wasn't actually suggesting this, I just noted you could use it to = select which GSS EAP enctypes to select, but not the underlying EAP = method. Using gss_set_cred_option() would work today (even on an SPNEGO = credential, because non-EAP GSS mechanisms will ignore the call). > mechanism-negotiation mechanism, sort of. Of course, the way these > functions work we'll need something better in the case of SPNEGO being > used to negotiate GSS-EAP. We really need a notion of credentials > acquired with credentials, so that we can first acquire a credential > handle for GSS-EAP, set what methods it will negotiate, then pass > *that* credential handle to another function for acquiring a larger > credential set. In other words, we need a new credential set model > for GSS, and the best thing to do for now is to punt. Could you use gss_add_cred() for this? Myself, I find gss_acquire_cred() + gss_set_cred_option(EAP_METHODS) = easier to understand, particularly if this kind of application-level = configurability is an edge case (I really want applications not to have = to worry about this; rather, they use SPNEGO, and the mechanism and/or = its credential manager sorts things out for you). -- Luke= From nico@cryptonector.com Sun Oct 30 17:22:34 2011 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 7E92E1F0C53 for ; Sun, 30 Oct 2011 17:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngROwHtzKfC5 for ; Sun, 30 Oct 2011 17:22:34 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id E1C1D1F0C4F for ; Sun, 30 Oct 2011 17:22:33 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 75629202018; Sun, 30 Oct 2011 17:22:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=rTsSf32zNwKA1v6swXu/FY1IRNcq/z/gqMPXVQcgYCQy nrFsP+5QNkMK8WC6RO08itsPRY7lMDIfh/MtkXFNSZw2RAZanrkXHZAImPOuAEV2 pQoofFpOJ364xx/Qwt8atwXgQYlubZPA368KNTJEH2WnH0Q9YfkpBCh5YddqaJw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=+Xvx4agLEG8dNaIf9QwcCWNYH60=; b=lAOz62UnAMI wh0OAq0/mHlvPJz/ijUd5UdnNZfLdxBQHZNikaknHoEutuF+7S4IIpEgYiyC6opA WkQ8GJkONTAjdDSyXg5FTCHRmTGxLFw6WLk2BgDs9jkrqL5G2wZyuk6N6a1FQXiH RO32dvvRKiVSMjyAHdL4QIcxSysBQmgk= Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 2B8D3202017; Sun, 30 Oct 2011 17:22:33 -0700 (PDT) Received: by ggnv1 with SMTP id v1so6396403ggn.31 for ; Sun, 30 Oct 2011 17:22:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.73.6 with SMTP id h6mr19455590pbv.41.1320020552218; Sun, 30 Oct 2011 17:22:32 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Sun, 30 Oct 2011 17:22:32 -0700 (PDT) In-Reply-To: <0F6C0A48-5AA6-4E55-98AA-6B44F276AEDB@padl.com> References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> <0F6C0A48-5AA6-4E55-98AA-6B44F276AEDB@padl.com> Date: Sun, 30 Oct 2011 19:22:32 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org, draft-ietf-abfab-gss-eap-authors@ietf.org, Jim Schaad Subject: Re: [abfab] Review on gss-eap-03 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, 31 Oct 2011 00:22:34 -0000 On Sun, Oct 30, 2011 at 6:38 PM, Luke Howard wrote: >> mechanism-negotiation mechanism, sort of. =C2=A0Of course, the way these >> functions work we'll need something better in the case of SPNEGO being >> used to negotiate GSS-EAP. =C2=A0We really need a notion of credentials >> acquired with credentials, so that we can first acquire a credential >> handle for GSS-EAP, set what methods it will negotiate, then pass >> *that* credential handle to another function for acquiring a larger >> credential set. =C2=A0In other words, we need a new credential set model >> for GSS, and the best thing to do for now is to punt. > > Could you use gss_add_cred() for this? Sadly, no. You'd think, by its name, but it would need *two* input credential handles to do what we need it to. I.e., we need a GSS_Add_cred_to_cred_set() that takes one credential handle that is to be an element of the other. We'd then need not GSS_Set_neg_mechs() but GSS_Set_net_creds(). I.e., we want credential handles as sets of credential handles, with credentials for mechanism-negotiation mechanisms themselves acting as sets (nested sets). > Myself, I find gss_acquire_cred() + gss_set_cred_option(EAP_METHODS) easi= er to understand, particularly if this kind of application-level configurab= ility is an edge case (I really want applications not to have to worry abou= t this; rather, they use SPNEGO, and the mechanism and/or its credential ma= nager sorts things out for you). GSS_Add_cred() was a mistake :( We may need a wrapper around all this to make GSS dead simple for most apps= . Nico -- From internet-drafts@ietf.org Sun Oct 30 17:35:18 2011 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 9A95B11E80A2; Sun, 30 Oct 2011 17:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oywGUljTxvd; Sun, 30 Oct 2011 17:35:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E83611E8093; Sun, 30 Oct 2011 17:35:18 -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: 3.62 Message-ID: <20111031003518.23032.13331.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2011 17:35:18 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-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, 31 Oct 2011 00:35:18 -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 Ac= cess Beyond web Working Group of the IETF. Title : A GSS-API Mechanism for the Extensible Authentication Pr= otocol Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-04.txt Pages : 36 Date : 2011-10-30 This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the EAP mechanism. Through the GS2 family of mechanisms, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-04.txt From hartmans@painless-security.com Sun Oct 30 17:42:11 2011 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 1EABB1F0C52 for ; Sun, 30 Oct 2011 17:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgs594lv-dFm for ; Sun, 30 Oct 2011 17:42:10 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCBB1F0C36 for ; Sun, 30 Oct 2011 17:42:10 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2C90420439; Sun, 30 Oct 2011 20:43:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 29B11435A; Sun, 30 Oct 2011 20:42:05 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> Date: Sun, 30 Oct 2011 20:42:05 -0400 In-Reply-To: (Nico Williams's message of "Sun, 30 Oct 2011 18:34:07 -0500") 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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org, Jim Schaad , draft-ietf-abfab-gss-eap-authors@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 31 Oct 2011 00:42:11 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Sun, Oct 30, 2011 at 6:20 PM, Sam Hartman Nico> wrote: >>>>>>> "Jim" == Jim Schaad writes: >>    Jim> Section 4 - does/should the application get >> any control ovret    Jim> the set of allowable EAP >> methods to be used or is that purely a    Jim> >> fucntion of your GSS-API library >> >> Currently no mechanism is provided for an application to >> enfluence this. A mechanism probably should have system-level >> policy configuration. A mechanism could expose a credential >> option on the initiator. If we ever need to standardize a >> credential option we can, but I don't see a need for that now. Nico> I think Luke suggested using the SPNEGO Nico> gss_get/set_neg_mechs() functions for this. I.e., you could Nico> treat GSS-EAP as a mechanism-negotiation mechanism, sort of. Luke suggested that you could include the EAP type in the OID. I explained that's all sorts of wrong and pointed you to the existing text discussing multi-layer negotiation. To recap, EAP method is much more like kerberos preauth mechanism: a matter that depends on the identity. The acceptor doesn't really know what method is being used. I mean it knows the outer method, but that will probably be something like TTLS. The acceptor is not in a position to construct the set of OIDs offered if the EAP method is included, because the set of EAP methods supported depends on the initiator identity. We've discussed this issue going back as far as my initial feasibility analysis. I realize that was not a consensus document, but I think it's fair to ask you to go back and read that document's discussion of this issue and the current text before jumping into the discussion. Nico> I don't see configuration as being satisfactory for this in Nico> the long-term. I do, because it's a property of the identity. I think acceptors will sometimes want to know information about LOA of authentication and will sometimes deny authorization based on that. However, in most cases, an initiator application has no business mandating an EAP method, and in most cases an acceptor couldn't even if it wanted to. --Sam From lukeh@padl.com Sun Oct 30 17:53:19 2011 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 A9A2E11E809B for ; Sun, 30 Oct 2011 17:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xcrf4pMprqYZ for ; Sun, 30 Oct 2011 17:53:19 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1C55E11E8091 for ; Sun, 30 Oct 2011 17:53:19 -0700 (PDT) Received: by us.padl.com with ESMTP id p9V0rA9K011848; Sun, 30 Oct 2011 20:53:13 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Luke Howard In-Reply-To: Date: Mon, 31 Oct 2011 11:53:10 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> To: Sam Hartman X-Mailer: Apple Mail (2.1251.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org, draft-ietf-abfab-gss-eap-authors@ietf.org, Jim Schaad Subject: Re: [abfab] Review on gss-eap-03 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, 31 Oct 2011 00:53:19 -0000 > Luke suggested that you could include the EAP type in the OID. FTR Nico suggested this. -- Luke From nico@cryptonector.com Sun Oct 30 18:40:39 2011 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 31D011F0C34 for ; Sun, 30 Oct 2011 18:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw2dfcXa73Gf for ; Sun, 30 Oct 2011 18:40:38 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id A2D2411E8086 for ; Sun, 30 Oct 2011 18:40:38 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 3DA48584059; Sun, 30 Oct 2011 18:40:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=TA5ulaulA8auU3E8RjWMY buyNhghWdwq7IA1mjZiO4DuTeXIeVSg+W3G4VyKKfkDLSz/LjxDpsoxHjSN2QSg7 B764FdOFDmTta6FgkNkMwlG9i4fnbW3wyTunFbm98UdknLjTgsQJoOpbj6sSW8cJ e9F3UscYKK7gCC+6aeUSWQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=U+l79mEsgFN/4v6cwVTl 4BLr1sw=; b=peVMc6UWD0XQyxHKntmH3zk1C7N8hWzB4drfQysnRJW6tmtNnb0s wu/GBZD2vslC/H77PZnAXsXDfHj1HeJHM/G/xPezX8rZng4j4osBhzdx6FwYLGlh a8dp84M+dkm2oL7MwT0rLtZ9qNz5E981hi2C+vbNInfeVQ7dEiC82Xo= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 1AFE5584058; Sun, 30 Oct 2011 18:40:37 -0700 (PDT) Received: by pzk34 with SMTP id 34so15973547pzk.9 for ; Sun, 30 Oct 2011 18:40:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.12.105 with SMTP id x9mr20057077pbb.109.1320025237183; Sun, 30 Oct 2011 18:40:37 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Sun, 30 Oct 2011 18:40:37 -0700 (PDT) In-Reply-To: References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> Date: Sun, 30 Oct 2011 20:40:37 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org, Jim Schaad , draft-ietf-abfab-gss-eap-authors@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 31 Oct 2011 01:40:39 -0000 To be fair krb5 pre-auth was never an issue before because a) we didn't have initial credential acquisition interfaces for GSS, b) we didn't have IAKERB. It's likely that this will never be a real issue. Indeed, what I'd want to do as a client app is specify things like "don't use weak authentication methods" and enctypes/cipher suites. I don't think I'd care to choose "PKINIT with user certs on a smartcard" vs. "PKINIT with SACRED instead of smartcards" vs. FAST armored PA-ENC-TIMESTAMP. So, I give, thanks for the analogy. Nico -- From nico@cryptonector.com Sun Oct 30 22:45:07 2011 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 B577521F8C21 for ; Sun, 30 Oct 2011 22:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lvOGAPnVmkp for ; Sun, 30 Oct 2011 22:45:07 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 45CF021F8C1F for ; Sun, 30 Oct 2011 22:45:07 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id ED0E9428075; Sun, 30 Oct 2011 22:45:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=b+eWQVA8xNqzpqtSldIFbC42lkZwXkfPGRekzutHRO5D YQqI/ht9KMLMF5FKOBaDlDiRk70bdO67DUc0XnuQq1/K5ww2XgRRH0JWK20Vy9r0 LYEnhc6cQYA2aIwYsIVs38VquL5e/EOkRVkFoWQDOLjJ/MT8otGgkf/Whg24QTY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=0JtlHJ4GhH+xz4t3IeB+AUU08K0=; b=QsGF6tYrlHw W3kAomdi172qrMB+fSy64zrm6b2gBKpzzStGoZcyeR/WyYWQsoP0Wvxv65pJ6p7O UTrKmOWYvd4nCV/0A8kB3iZBOULI4lmGKfnErvSVjHelelcfGTkSFY13bEn86Gx7 boEnMZB8NfEkig5WuxavNn68j+xBnvN8= Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id B7B82428072; Sun, 30 Oct 2011 22:45:06 -0700 (PDT) Received: by gyh20 with SMTP id 20so6683003gyh.31 for ; Sun, 30 Oct 2011 22:45:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.102 with SMTP id h6mr21190019pbq.7.1320039541351; Sun, 30 Oct 2011 22:39:01 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Sun, 30 Oct 2011 22:39:01 -0700 (PDT) In-Reply-To: References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> Date: Mon, 31 Oct 2011 00:39:01 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org, Jim Schaad , draft-ietf-abfab-gss-eap-authors@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 31 Oct 2011 05:45:07 -0000 On Sun, Oct 30, 2011 at 8:40 PM, Nico Williams wrot= e: > To be fair krb5 pre-auth was never an issue before because a) we > didn't have initial credential acquisition interfaces for GSS, b) we > didn't have IAKERB. =C2=A0It's likely that this will never be a real issu= e. > =C2=A0Indeed, what I'd want to do as a client app is specify things like > "don't use weak authentication methods" and enctypes/cipher suites. =C2= =A0I > don't think I'd care to choose "PKINIT with user certs on a smartcard" > vs. "PKINIT with SACRED instead of smartcards" vs. FAST armored > PA-ENC-TIMESTAMP. =C2=A0So, I give, thanks for the analogy. This is what had me nervous Sam, and I now agree that I shouldn't look at GSS-EAP through the same prism when it comes to two-level negotiation. What I want is probably best left as cred options (and possibly a req_flag, but I want to avoid adding req_flags whenever we can, since that's a very limited namespace) for expressing the app policies I mentioned above. Cred options on the default credential can be had by acquiring a credential for desired_name =3D GSS_C_NO_NAME and setting cred options on that, which is how we'd avoid having to add req_flags. Nico -- From wei.yinxing@zte.com.cn Mon Oct 31 01:58:28 2011 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 EDC5B21F8D24 for ; Mon, 31 Oct 2011 01:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.772 X-Spam-Level: X-Spam-Status: No, score=-97.772 tagged_above=-999 required=5 tests=[AWL=4.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTadCNZ-DQYM for ; Mon, 31 Oct 2011 01:58:28 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 034CC21F8CFD for ; Mon, 31 Oct 2011 01:58:27 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 46621967931198; Mon, 31 Oct 2011 16:49:43 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 51298.967931198; Mon, 31 Oct 2011 16:58:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p9V8w5Kg020119 for ; Mon, 31 Oct 2011 16:58:05 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) To: abfab@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Mon, 31 Oct 2011 16:58:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-31 16:58:07, Serialize complete at 2011-10-31 16:58:07 Content-Type: multipart/alternative; boundary="=_alternative 0031437C4825793A_=" X-MAIL: mse01.zte.com.cn p9V8w5Kg020119 Subject: [abfab] draft-wei-abfab-fcla-01 is uploaded, please review it 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, 31 Oct 2011 08:58:29 -0000 This is a multipart message in MIME format. --=_alternative 0031437C4825793A_= Content-Type: text/plain; charset="US-ASCII" Hi, All The -01 version of draft-wei-abfab-fcla is uploaded, please follow the link http://www.ietf.org/id/draft-wei-abfab-fcla-01.txt to open it. Please review it, any comments are welcome! Filename: draft-wei-abfab-fcla Revision: 01 Title: Federated Cross-Layer Access Creation date: 2011-10-31 WG ID: Individual Submission Number of pages: 9 Abstract: Network stratum and application stratum form a federation to faciliate user's access. Network operator acts as Identity Provider (IdP), and application reuses underlying network's security capabilities to simlify application's access. This document is to introduce such federated cross-layer access use case and message flows. ------------ Yinxing Wei -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0031437C4825793A_= Content-Type: text/html; charset="US-ASCII"
Hi, All

  The -01 version of draft-wei-abfab-fcla is uploaded, please follow the link http://www.ietf.org/id/draft-wei-abfab-fcla-01.txt to open it.

  Please review it, any comments are welcome!

Filename:                  draft-wei-abfab-fcla
Revision:                  01
Title:                                   Federated Cross-Layer Access
Creation date:                  2011-10-31
WG ID:                                   Individual Submission
Number of pages: 9

Abstract:
  Network stratum and application stratum form a federation to
  faciliate user's access.  Network operator acts as Identity Provider
  (IdP), and application reuses underlying network's security
  capabilities to simlify application's access.  This document is to
  introduce such federated cross-layer access use case and message
  flows.


------------
Yinxing Wei
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0031437C4825793A_=-- From alex@um.es Mon Oct 31 05:56:57 2011 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 2708D21F8DB0 for ; Mon, 31 Oct 2011 05:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCDBRf2SryFV for ; Mon, 31 Oct 2011 05:56:56 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 2832A21F8D7E for ; Mon, 31 Oct 2011 05:56:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 7FF115D4AA for ; Mon, 31 Oct 2011 13:56:54 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nFw2r2Uw9UXw for ; Mon, 31 Oct 2011 13:56:53 +0100 (CET) Received: from [192.168.1.130] (28.233.17.95.dynamic.jazztel.es [95.17.233.28]) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPA id 3F2E45D49F for ; Mon, 31 Oct 2011 13:56:50 +0100 (CET) Message-ID: <4EAE9B0B.6060302@um.es> Date: Mon, 31 Oct 2011 13:56:43 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050400030307040205030907" Subject: Re: [abfab] draft-wei-abfab-fcla-01 is uploaded, please review it 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, 31 Oct 2011 12:56:57 -0000 This is a multi-part message in MIME format. --------------050400030307040205030907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Yinxing, After reading the draft, I have a doubt concerning with your proposal. In section 4, step 3, the text says: When RP receieves the request from UE, it checkes whether the credential is avialable. If not, RP initiates AAA request to retrieve credential from IdP [I-D.ietf-abfab-aaa-saml] [I-D.jones-diameter-abfab]. It is not clear to me how credentials (MSK or similar) are transported to the RP, since it seems (due to the references you cite) that it is done through SAML. Can you provide further details on this, please? Regards, Alejandro > > Hi, All > > The -01 version of draft-wei-abfab-fcla is uploaded, please follow > the link http://www.ietf.org/id/draft-wei-abfab-fcla-01.txt to open it. > > Please review it, any comments are welcome! > > Filename: draft-wei-abfab-fcla > Revision: 01 > Title: Federated Cross-Layer Access > Creation date: 2011-10-31 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > Network stratum and application stratum form a federation to > faciliate user's access. Network operator acts as Identity Provider > (IdP), and application reuses underlying network's security > capabilities to simlify application's access. This document is to > introduce such federated cross-layer access use case and message > flows. > > > ------------ > Yinxing Wei > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --------------050400030307040205030907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Yinxing,

After reading the draft, I have a doubt concerning with your proposal.  In section 4, step 3, the text says:
When RP receieves the request from UE, it checkes whether the
       credential is avialable.  If not, RP initiates AAA request to
       retrieve credential from IdP [I-D.ietf-abfab-aaa-saml]
       [I-D.jones-diameter-abfab].
It is not clear to me how credentials (MSK or similar) are transported to the RP, since it seems (due to the references you cite) that it is done through SAML.
Can you provide further details on this, please?

Regards,
Alejandro

Hi, All

  The -01 version of draft-wei-abfab-fcla is uploaded, please follow the link http://www.ietf.org/id/draft-wei-abfab-fcla-01.txt to open it.

  Please review it, any comments are welcome!

Filename:                  draft-wei-abfab-fcla
Revision:                  01
Title:                                   Federated Cross-Layer Access
Creation date:                  2011-10-31
WG ID:                                   Individual Submission
Number of pages: 9

Abstract:
  Network stratum and application stratum form a federation to
  faciliate user's access.  Network operator acts as Identity Provider
  (IdP), and application reuses underlying network's security
  capabilities to simlify application's access.  This document is to
  introduce such federated cross-layer access use case and message
  flows.


------------
Yinxing Wei
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.



_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab
--------------050400030307040205030907-- From hartmans@painless-security.com Mon Oct 31 06:10:21 2011 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 DA96221F8783 for ; Mon, 31 Oct 2011 06:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxvxKMXmJVYx for ; Mon, 31 Oct 2011 06:10:20 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBB221F8B74 for ; Mon, 31 Oct 2011 06:10:20 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 95871201CB; Mon, 31 Oct 2011 09:10:59 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 219CB435A; Mon, 31 Oct 2011 09:09:55 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> Date: Mon, 31 Oct 2011 09:09:55 -0400 In-Reply-To: (Nico Williams's message of "Mon, 31 Oct 2011 00:39:01 -0500") 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, Jim Schaad , draft-ietf-abfab-gss-eap-authors@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 31 Oct 2011 13:10:21 -0000 >>>>> "Nico" == Nico Williams writes: Nico> This is what had me nervous Sam, and I now agree that I Nico> shouldn't look at GSS-EAP through the same prism when it comes Nico> to two-level negotiation. Nico> What I want is probably best left as cred options (and Nico> possibly a req_flag, but I want to avoid adding req_flags Nico> whenever we can, since that's a very limited namespace) for Nico> expressing the app policies I mentioned above. Cred options Nico> on the default credential can be had by acquiring a credential Nico> for desired_name = GSS_C_NO_NAME and setting cred options on Nico> that, which is how we'd avoid having to add req_flags. I agree cred options are a fine way to get this sort of app policy. I think we need not specify them now; they can be in a separate spec. I'm personally dubious whether we'll need to standardize them. For me, it would be worthwhile if someone were going to implement and someone else indicated a desire to use the option in an application that was not closely associated with the implementation. If that happens I'm all for standardizing. If that doesn't happen and there's a consensus to standardize anyway, I'm not against. --Sam From nico@cryptonector.com Mon Oct 31 07:57:51 2011 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 56A9621F8D9D for ; Mon, 31 Oct 2011 07:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.98 X-Spam-Level: X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-CG6-m+XtWv for ; Mon, 31 Oct 2011 07:57:50 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 3737B21F8CF4 for ; Mon, 31 Oct 2011 07:57:50 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id E479610062; Mon, 31 Oct 2011 07:57:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=SZDGKqlCuh01otm9iwo7D P+ixB2vhNfHO6Kn9CDQIUjMgnodd8vltMlejbhkjALf+grbcHGkifdvjYn34KFtD 8sHjutOjEDXeubtLSie79mpv92kmHWf2Tj463+3u1rLZqjB96GzYTcnZ05aZIR4u ESijUSllZnuNZsAZzAFMVc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=sUGfVFWAIwGhmamfv/cU My7ZGE0=; b=BICPwhXCldyg6tXeFxH7frIi1zTpY4EMzA0dJGGdqshRilGc3CEW zdXzS5jHZmXdW/GDHT3Vg93RqryPTeSFkozTL1K4iWcDF0lw5AMuVNs6DGS2slb6 VpQhS0Cfjn3lsHO6HRaZbQhm7F7FbWVxHSOsJpAu/PO+OKEFaAUjqP8= Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id A168910059; Mon, 31 Oct 2011 07:57:49 -0700 (PDT) Received: by qadc10 with SMTP id c10so6411380qad.31 for ; Mon, 31 Oct 2011 07:57:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.39.34 with SMTP id m2mr23865029pbk.75.1320073068707; Mon, 31 Oct 2011 07:57:48 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Mon, 31 Oct 2011 07:57:48 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Mon, 31 Oct 2011 07:57:48 -0700 (PDT) In-Reply-To: References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> Date: Mon, 31 Oct 2011 09:57:48 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: multipart/alternative; boundary=bcaec52161a9567e4504b09976f5 Cc: Jim Schaad , draft-ietf-abfab-gss-eap-authors@ietf.org, abfab@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 31 Oct 2011 14:57:51 -0000 --bcaec52161a9567e4504b09976f5 Content-Type: text/plain; charset=UTF-8 The obvious application for these policy options is Luke's pam_gss. --bcaec52161a9567e4504b09976f5 Content-Type: text/html; charset=UTF-8

The obvious application for these policy options is Luke's pam_gss.

--bcaec52161a9567e4504b09976f5-- From internet-drafts@ietf.org Mon Oct 31 16:43:37 2011 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 55E3211E83D2; Mon, 31 Oct 2011 16:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVixlkfoe+dz; Mon, 31 Oct 2011 16:43:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF8A11E83CE; Mon, 31 Oct 2011 16:43:36 -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: 3.62 Message-ID: <20111031234336.4776.78692.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 16:43:36 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-02.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, 31 Oct 2011 23:43:37 -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 Ac= cess 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-02.txt Pages : 14 Date : 2011-10-31 This document specifies a RADIUS attribute, binding and two profiles for the Security Assertion Mark-up Language (SAML). The attribute provides RADIUS encapsulation of SAML protocol messages, while the binding describes the transport of this attribute, and the SAML protocol messages within, using RADIUS. The profiles describe the application of this binding for Abfab authentication and assertion query/request. The SAML RADIUS attribute and binding are defined generically to permit application in other scenarios, such as network access. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-02.txt From ietf@augustcellars.com Mon Oct 31 18:12:17 2011 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 B30BD11E8093 for ; Mon, 31 Oct 2011 18:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+6DCoyJ3B0J for ; Mon, 31 Oct 2011 18:12:16 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC801F0C42 for ; Mon, 31 Oct 2011 18:12:16 -0700 (PDT) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (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 B48BB2CA13; Mon, 31 Oct 2011 18:12:15 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> In-Reply-To: Date: Mon, 31 Oct 2011 18:11:46 -0700 Message-ID: <011a01cc9833$3a006440$ae012cc0$@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: AQETpEEniQkn/k2uDh7nlzFmlDNLFgKn8jeplvPZptA= Content-Language: en-us Cc: draft-ietf-abfab-gss-eap-authors@ietf.org, abfab@ietf.org Subject: Re: [abfab] Review on gss-eap-03 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, 01 Nov 2011 01:12:17 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Sunday, October 30, 2011 4:20 PM > To: Jim Schaad > Cc: draft-ietf-abfab-gss-eap-authors@ietf.org; abfab@ietf.org > Subject: Re: [abfab] Review on gss-eap-03 > > >>>>> "Jim" == Jim Schaad writes: > > > Jim> Is the ABNF for "name" still wrong? > > I don't think so. > What problem or oddity do you see? > Hmm. > I see that realm is only permitted if host is present. I think I've fixed that. > I think it's correct now in 04. That was the specific error that I saw. > > > Jim> section 3.4 missing > > Jim> Section 4 - does/should the application get any control ovret > Jim> the set of allowable EAP methods to be used or is that purely a > Jim> fucntion of your GSS-API library > > Currently no mechanism is provided for an application to enfluence this. > A mechanism probably should have system-level policy configuration. > A mechanism could expose a credential option on the initiator. > If we ever need to standardize a credential option we can, but I don't see a > need for that now. > > > > Jim> For consistency the paragraph: Tokens from the initiator to > Jim> acceptor use an outer token type of 06 01; tokens from acceptor > Jim> to initiator use an outer token type of 06 02. These token > Jim> types are registered in the registry of RFC 4121 token types; > Jim> see Section 8.1. > > My understanding is that the ID describes which type of token (token > type) we are dealing with. > So, I've phrased it as token s with from acceptor to initiator use an inner > token type with ID xxx. > 1) token type with ID > and 2) inner not outer Looks fine > > Jim> should refer to the "token ID" rather than the "outer token > Jim> type" either that or the item in the table should be updated. > > Jim> section 5.2 refers to "token type" - I think that maybe this is > Jim> the most constant phrase to be used. > > I've updated the registry to talk about token type identifiers. > > Jim> I will say that this version did harmonize and make the token > Jim> naming scheme much more consistent and readable. I think this > Jim> is a big improvement. > Great! > > Jim> s/secondsubtoken/second subtoken/ (in the table) > > Jim> Section 5.3 - Is there going to be a rule that you should send > Jim> two error subtokens in the even t\the length is greater than 8? > Jim> I can understand saying you should ignore the extended bytes > Jim> but should you really ignore the error code itself? > > In 04 we have initiators MUST ignore octets beyond the GSS EAP error code > for future extensibility. Thanks for the catch. > > Jim> Section 5.4 - you have different names for the acceptor name > Jim> subtokens in the description of what is permitted and the > Jim> actual subtoken names - I think you might want to harmonize > Jim> this. > > Jim> Is there a rason that the EAP request subtoken is not > Jim> documented in section 5.4 since it is a required subtoken from > Jim> in the Initial State message from the acceptor? > > I've added a reference. However I think it's better to document EAP request > and response near each other. > Note that if we adopt the proposal to reduce a round trip this subtoken goes > away from initial state. > > Jim> Section 5.4.1 - I realize this is a debugging string (Vender > Jim> Subtoken) but is there any reason in this day and age not make > Jim> it a UTF8 string? (Other than it is not one for Kerbros) > > It doesn't exist for Kerberos (which has no vendor string I'm aware of) so I > don't think that's a concern. > > I've made it UTF-8; I don't care. > > Jim> Section 5.4.3 - Should something be said about what the > Jim> acceptor should do if the initiator sends an acceptor name > Jim> which is not completely correct for the specific acceptor. I > Jim> am thinking specifically of things like adding a host name or > Jim> adding some service specifics to the acceptor name. Is this > Jim> permitted? Or is this and error condition or since this is > Jim> typically not sent is the acceptor name from the client to be > Jim> used in all events. (unless totally wrong) > > I think you mean 5.4.2 not 5.4.3? > My assumption is that you need to send a superset of what the acceptor > expects, else things will fail at channel binding. I think you want to leave it to > channel binding to fail unless an IDP wants to implement some form of > aliasing. In 5.4.2 s/hosntame/hostname/ I meant 5.4.3 - because I was assuming this was an Acceptor error rather than an Initiator. That is if the Acceptor name is not a superset then it would return an error. The question is should you both error and return the response in some sense. One possibility is that the Initiator sends name #1, the Acceptor replies with name #2 and then the intiator says that this is acceptable and sends name #2 as part of the channel binding. In this case the was no error but the initator name is not a superset of the acceptor name that came back. > > > > Jim> para #2 s/this token/This token/ > > Jim> Section 5.5 s/ACCEPTOR/acceptor/ Not fixed > > Jim> The first bullet of this section is causing me some mental > Jim> problems. The acceptor cannot confirm that the protected > Jim> result and the final result are consistent - this is hidden > Jim> from the acceptor. --- or you need to be passing the protected > Jim> result as a RADIUS attribute, at which point it is not really > Jim> protected anymore. > > For combined authenticators the acceptor can and should evaluate the > protected result. > For pass-through authenticators the acceptor should confirm there's AAA > success if there is EAP success. Ok - I think this is more clear now. > > Jim> The acceptor can confirm that a key has been delivered to it, > Jim> but it does not know the source of the key - i.e. was it > Jim> derived or just transmitted inside of the EAP session. > > Here, we mean the security claim discussed in section 7.10 of RFC 3748, which > probably includes transmitting a key. > Their term, not mine. > I've added a reference. > Ok > > > Jim> Should the acceptor or the initiator send the error subtoken - > Jim> or should the acceptor be looking for clear EAP messages and > Jim> generate a failure? > > I don't understand. > > Jim> I think you need to carefully re-read the section and verify > Jim> that you think it is correct. > > I think it is consistent with what EAP does and what our implementation > does. > There are some disadvantages to how EAP handles failures. > We can discuss at IETF 82 if you like. I think this would probably be a good idea - just so I can be sure that we understand each other and what the doc says. > > Jim> Setion 5.6 - Please tell me which type of channel binding I am > Jim> getting at this point. (I know it is GSS-API channel binding, > Jim> but given that two different types are discussed in the > Jim> document I think being explcit would be good.) > > Also added a forward reference. > > Jim> Section 6 - Is the KMSK in the "Tn = " line supposed to be > Jim> GMSK? > Yes. > > > Jim> Section 6.1 - I am unclear what the extension option field is > Jim> referring to please clarify. > > This was all wrong and has been fixed. Thanks for the reality check.