From nobody Mon Dec 1 14:42:37 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03241ACD54 for ; Mon, 1 Dec 2014 14:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIbwkebE0819 for ; Mon, 1 Dec 2014 14:42:24 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518F91ACD4E for ; Mon, 1 Dec 2014 14:42:24 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id w7so9366124lbi.5 for ; Mon, 01 Dec 2014 14:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FjiF6w5ZRpURQWrFVx73C5vh/bZ+B5zpklsIRW40Cd4=; b=HFabAj+dcd/zl/34cmiI8SY/5WCWPgGUCMKT0NwWz9Y6RO3rNpE0qIRIQxyPay4j3q gZcXlBXb6tPia7oZvbcyaT7sZCrNOEzUk/C9ivXvVcyuUvqhxBC3Qc6rBQ8e32mKa95Z mB8NXX8NM2V2UVyh4x7UucmSEx21TBFU1QOjLCiDOnQq+AFNwfE3VZxhgZcxf8nlYSF1 z4ueMwQIcA14mkTR64fH7V/UMofQeEbBcyjzYyrb1CjmpOjVx4GaPYy6xJgVqxhp4Rjy jpVYh5U2+LBlRzqJwcDRtTm91E/7TuYFOn9+VrKZ/C4NJNHdPhso2vSAETEyyziCX7+V +Duw== MIME-Version: 1.0 X-Received: by 10.112.93.231 with SMTP id cx7mr56968210lbb.89.1417473742767; Mon, 01 Dec 2014 14:42:22 -0800 (PST) Received: by 10.112.49.52 with HTTP; Mon, 1 Dec 2014 14:42:22 -0800 (PST) Date: Mon, 1 Dec 2014 17:42:22 -0500 Message-ID: From: Kathleen Moriarty To: http-auth@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/4qcjFX-ZR95w54TTSKq-wn-fcbE Subject: [http-auth] Review of draft-ietf-httpauth-hoba-05 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 22:42:29 -0000 Hi Stephen, Paul, & Michael, I reviewed the latest version of the HOBA draft and it is much improved from earlier versions, thanks for your work on this draft. Hopefully it will help mitigate threats to end users with reduced use of passwords and associated attacks. Here are comments for you to consider: Abstract - I'd remove the bit about phishing attacks and just state that it prevents password theft since there are no passwords to steal, which is covered nicely in the introduction. Phishing is a bit more complicated, involves several steps that include social engineering to get users to click on links, down;pad of malware/trojans, which are difficult to defeat and may or may not be targeting credentials. Spear phishing attacks that install trojans have been around for several years and are able to steal all types of credentials including PKI X.509 stored in PKCS#11 containers (Sykipot, Zeus, etc.). http://it.slashdot.org/story/12/01/13/2216218/sykipot-trojan-variant-stealing-dod-smartcard-credentials http://www.secureworks.com/cyber-threat-intelligence/threats/zeus/ There would just be a short window until HOBA was defeat-able in spear phishing related attacks using trojans installed on the client. By simply stating the password theft, you are covering more attack types that steal passwords on the client side than just those used as part of phishing attacks and lower the complexity from using a full blown PKI. This is what I think you need to target HOBA's use toward. Section 1 Curious as to how it scales since it seems private/public keys pairs would have to be stored, but I guess that's no different than passwords. Maybe it doesn't matter with that assumption. In the third paragraph possible attacks on the server side are mentioned when passwords are used, you should also mention client side issues like password theft and re-use (on same site or others) will be prevented. You may or may not want to include this, but it does have traction/interest in industry to improve password authentication: Other mechanisms with Basic could combine with other factors to use 'risk-based' authentication systems (geo-location, system properties, etc.). HOBA could do this too. This may include browser information (make sure it's the same one each time or prompt with some other auth if it changes), IP layer information to get geo-location (can't travel somewhere in less than x hours - doesn't make sense). Section 5 If this is describing both HTTP HOBA and HOBA-js, it would be good to state that explicitly and differences that should be noted. The intro reads as if it is just for HTTP, if that's the case, then leave it alone. Section 5.3 Second to last paragraph, first time you use the term join (I think), you should provide a reference or explain what it means as this will likely be asked in subsequent reviews. You describe it in section 6.1, I think it would be better to have the explanation in this section. Section 6 What do you mean by "All additional services MUST be performed in TLS-protected sessions"? If you are referring to HOBA and HOBA-js or the authentication process as the additional service, it would be better to state that explicitly. Section 8.2 Second paragraph: current text: Again it's not clear that we are worse in this regard because the same attacker could get at browser password files, etc too. One possible mitigation is to encrypt the keystore with a password/pin the user supplies. This may sound counter intuitive, but the object here is to keep passwords off of servers to mitigate the multiplier effect of a large scale compromise ala LinkedIn because of shared passwords across sites. Proposed update: Again it's not clear that we are worse in this regard because the same attacker could get at browser password files, stored PKI credentials (even via PKCS#11 interface), etc too. One possible mitigation is to encrypt the keystore with a password/pin the user supplies. This may sound counter intuitive, but the object here is to keep passwords off of servers to mitigate the multiplier effect of a large scale compromise ala LinkedIn because of shared passwords across sites. This recommendation does not help against possible client side attacks, which are inevitable with the use of phishing/spear phishing related malware and trojans. Explanation: All forms of keys stored on a computer have been subject to attacks, including attacks that automate this theft of passwords and even PKI credentials in malware. The last sentence of paragraph 2 could be stronger to reflect this inevitability. Storing the credentials in an external secure container does help, but those have been successfully attacked too. I'm glad to see the password re-use problem mentioned in the last paragraph, so you don't need that in the intro, but I'll leave my comment there as it is part of the overview as to why it might be a good idea to use HOBA. You may want to emphasize the difficulty of PKI and the advantage of preventing server side password database attacks since the credentials can be stolen on the client side (or will be once deployed). This has a niche and we should be clear on that IMO. -- Best regards, Kathleen From nobody Mon Dec 1 16:52:51 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048E41ACD44 for ; Mon, 1 Dec 2014 16:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBwGqeG0o7k1 for ; Mon, 1 Dec 2014 16:52:46 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E45371AC41F for ; Mon, 1 Dec 2014 16:52:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B4865BECA; Tue, 2 Dec 2014 00:52:44 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz8xiwtaGWZJ; Tue, 2 Dec 2014 00:52:42 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.46.26.33]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4BDF0BEC9; Tue, 2 Dec 2014 00:52:42 +0000 (GMT) Message-ID: <547D0D59.5070104@cs.tcd.ie> Date: Tue, 02 Dec 2014 00:52:41 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Kathleen Moriarty , http-auth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/mOFj37DhpbSMn68YMUMd7bMSrAU Subject: Re: [http-auth] Review of draft-ietf-httpauth-hoba-05 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 00:52:50 -0000 Hiya, On 01/12/14 22:42, Kathleen Moriarty wrote: > Hi Stephen, Paul, & Michael, > > I reviewed the latest version of the HOBA draft and it is much > improved from earlier versions, thanks for your work on this draft. > Hopefully it will help mitigate threats to end users with reduced use > of passwords and associated attacks. > > Here are comments for you to consider: Cool. Thanks for the reivew. I'm not clear if you regard these as things that need fixing before IETF LC or as things to handle during/after IETF LC. I'm guessing the latter but not sure but it'll be clear as we argue or you start the IETF LC I guess:-) (So far, I made one change below in my local copy that'd go into a -06 whenever needed.) > > Abstract - > I'd remove the bit about phishing attacks and just state that it > prevents password theft since there are no passwords to steal, which > is covered nicely in the introduction. Phishing is a bit more > complicated, involves several steps that include social engineering to > get users to click on links, down;pad of malware/trojans, which are > difficult to defeat and may or may not be targeting credentials. > Spear phishing attacks that install trojans have been around for Not all trojan installs are phishing though. > several years and are able to steal all types of credentials including > PKI X.509 stored in PKCS#11 containers (Sykipot, Zeus, etc.). > http://it.slashdot.org/story/12/01/13/2216218/sykipot-trojan-variant-stealing-dod-smartcard-credentials > http://www.secureworks.com/cyber-threat-intelligence/threats/zeus/ Hm. I don't consider theft of a private key via trojan to be a phish. It is an attack of course, and with similar impact but not a phish according to my definition. Happy to be corrected but I believe my definition is ok tbh. > > There would just be a short window until HOBA was defeat-able in spear > phishing related attacks using trojans installed on the client. Yes, but that would not be a phishing attack. HOBA is, as the abstract correctly states "not vulnerable to phishing attacks." > > By simply stating the password theft, you are covering more attack > types that steal passwords on the client side than just those used as > part of phishing attacks and lower the complexity from using a full > blown PKI. This is what I think you need to target HOBA's use toward. > > Section 1 > Curious as to how it scales since it seems private/public keys pairs > would have to be stored, but I guess that's no different than > passwords. Maybe it doesn't matter with that assumption. Yep. Scaling isn't a differentiator, it's linear in the size of the user population basically. I've used the same nosql DB as is used on hoba.ie with millions of entries on a standard server with no issues at all. > > In the third paragraph possible attacks on the server side are > mentioned when passwords are used, you should also mention client side > issues like password theft and re-use (on same site or others) will be > prevented. I'm not clear that that's worth adding but don't object. I do think the password verifier DB theft issue is the main distinction between HOBA and password based schemes though so would prefer keep that front and centre. (And as you say later, that issue is called out eventually.) > You may or may not want to include this, but it does have > traction/interest in industry to improve password authentication: > Other mechanisms with Basic could combine with other factors to use > 'risk-based' authentication systems (geo-location, system properties, > etc.). HOBA could do this too. This may include browser information > (make sure it's the same one each time or prompt with some other auth > if it changes), IP layer information to get geo-location (can't travel > somewhere in less than x hours - doesn't make sense). I don't think it'd be a good idea to start to describe other mechanisms here, nor to try cover multi-factor authentication. There is a fine RFC to be written on that, but this ain't it:-) If we tried that, we'd face potentially endless comment from all sides which I don't think would be worthwhile. And it'd also cause issues for other WG drafts too maybe if some do, and some don't try describe multi-factor auth issues. > Section 5 > If this is describing both HTTP HOBA and HOBA-js, it would be good to > state that explicitly and differences that should be noted. The intro > reads as if it is just for HTTP, if that's the case, then leave it > alone. Well, we only use the -http and -js when necessary (i.e. when there's a difference) and leave it implicit when its obvious or doesn't matter. Does it matter here? (I've no problem adding that this covers both if that helps, but I'm not clear it does help.) > Section 5.3 > Second to last paragraph, first time you use the term join (I think), > you should provide a reference or explain what it means as this will > likely be asked in subsequent reviews. You describe it in section > 6.1, I think it would be better to have the explanation in this > section. Good point. I think the following para of 5.3 addresses the issue though. Probably good to not say "already joined" as the first occurrence mind you. I guess s/already-joined/another/ would be a good change, as it's clarified in the next para. (Did that in our author's svn copy.) > > Section 6 > What do you mean by "All additional services MUST be performed in > TLS-protected sessions"? If you are referring to HOBA and HOBA-js or > the authentication process as the additional service, it would be > better to state that explicitly. All meaning all:-) We didn't see any point in being selective so the all-TLS thing seems easier. You need TLS at least to ensure there's no MITM handing off challenges or new public keys being submitted etc. So I'm not sure what's not clear tbh. > > Section 8.2 > > Second paragraph: current text: > Again it's not clear that we are > worse in this regard because the same attacker could get at browser > password files, etc too. One possible mitigation is to encrypt the > keystore with a password/pin the user supplies. This may sound > counter intuitive, but the object here is to keep passwords off of > servers to mitigate the multiplier effect of a large scale compromise > ala LinkedIn because of shared passwords across sites. > > Proposed update: > Again it's not clear that we are > worse in this regard because the same attacker could get at browser > password files, stored PKI credentials (even via PKCS#11 interface), > etc too. One possible mitigation is to encrypt the > keystore with a password/pin the user supplies. This may sound > counter intuitive, but the object here is to keep passwords off of > servers to mitigate the multiplier effect of a large scale compromise > ala LinkedIn because of shared passwords across sites. This > recommendation does not help against possible client side attacks, > which are inevitable with the use of phishing/spear phishing related > malware and trojans. > > Explanation: > All forms of keys stored on a computer have been subject to attacks, > including attacks that automate this theft of passwords and even PKI > credentials in malware. The last sentence of paragraph 2 could be > stronger to reflect this inevitability. Storing the credentials in an > external secure container does help, but those have been successfully > attacked too. I agree with your last but the section here is specific to HTPM5 localStorage as a private key store so pkcs#11 isn't relevant at this point. And I think we've hit that difference in our definitions of phishing again too:-) So I'd suggest no change there. > I'm glad to see the password re-use problem mentioned in the last > paragraph, so you don't need that in the intro, but I'll leave my > comment there as it is part of the overview as to why it might be a > good idea to use HOBA. You may want to emphasize the difficulty of > PKI and the advantage of preventing server side password database > attacks since the credentials can be stolen on the client side (or > will be once deployed). This has a niche and we should be clear on > that IMO. Fair points but I think the audience for this are probably aware of all that. I don't think we should try sell HOBA in the RFC, but just define it - the sales pitch that is absolutely required is for elsewhere/others. But maybe others think differently. Cheers, S. > > From nobody Mon Dec 1 17:24:17 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50411A1A7A for ; Mon, 1 Dec 2014 17:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ei1cHdQQueu for ; Mon, 1 Dec 2014 17:24:09 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484A41AC43A for ; Mon, 1 Dec 2014 17:24:09 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id i50so8416254qgf.23 for ; Mon, 01 Dec 2014 17:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ofW0dtbVuUQa9CVd5Fu0u2Mn2Tifa8QdOTjyx6g6zJE=; b=lapPeT9DxykSrv1O5f74Znr6BcmY0npqu0tUk/gQVDt0Re/rLvo5l9Ag021VBX731d v+zdX5QYWMpOLa9riWQ2f14mAsjeAvlW3eRm1Fwooi0ItKu2lvyc0Zt4HprwqOiid2Ye l6W5F8zqB7qEQYMnghjWVZk1vTeUKLDFv0lVbnSGupoG513+MP4e3RAaEmWUZQHLXOlH /mFSGpmtTPZH0onx4Iv6JTx4bhA6yXiZKiACsPYs/eCXNMoOZF2Anghbb5Vp3m9op/7L 1mXpF5kiafdyeFaZ0zA8GEl3lKM4HvHp7HlPMn3ZLRK0PCNjEZ5xuf+CbHh+lKomRLvr cH0A== X-Received: by 10.224.25.79 with SMTP id y15mr43127938qab.78.1417483448380; Mon, 01 Dec 2014 17:24:08 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id c7sm6204762qar.33.2014.12.01.17.24.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 17:24:06 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <547D0D59.5070104@cs.tcd.ie> Date: Mon, 1 Dec 2014 20:24:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <78620582-D88B-4B58-9E98-15941A96809C@gmail.com> References: <547D0D59.5070104@cs.tcd.ie> To: Stephen Farrell Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Xg0CNiTOGy7ouGQQFJqeBG5LML8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Review of draft-ietf-httpauth-hoba-05 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 01:24:13 -0000 Hi, Sent from my iPhone > On Dec 1, 2014, at 7:52 PM, Stephen Farrell wr= ote: >=20 >=20 > Hiya, >=20 >> On 01/12/14 22:42, Kathleen Moriarty wrote: >> Hi Stephen, Paul, & Michael, >>=20 >> I reviewed the latest version of the HOBA draft and it is much >> improved from earlier versions, thanks for your work on this draft. >> Hopefully it will help mitigate threats to end users with reduced use >> of passwords and associated attacks. >>=20 >> Here are comments for you to consider: >=20 > Cool. Thanks for the reivew. I'm not clear if you regard > these as things that need fixing before IETF LC or as > things to handle during/after IETF LC. I'm guessing the > latter but not sure but it'll be clear as we argue or > you start the IETF LC I guess:-) Either is fine. Nothing is too drastic in my review. >=20 > (So far, I made one change below in my local copy that'd go > into a -06 whenever needed.) >=20 >>=20 >> Abstract - >> I'd remove the bit about phishing attacks and just state that it >> prevents password theft since there are no passwords to steal, which >> is covered nicely in the introduction. Phishing is a bit more >> complicated, involves several steps that include social engineering to >> get users to click on links, down;pad of malware/trojans, which are >> difficult to defeat and may or may not be targeting credentials. >> Spear phishing attacks that install trojans have been around for >=20 > Not all trojan installs are phishing though. No, but they are commonly part of the phishing and spear phishing attacks th= at has the financial sector worried. I think you should just say what you m= ean instead if lumping in phishing unnecessarily. >=20 >> several years and are able to steal all types of credentials including >> PKI X.509 stored in PKCS#11 containers (Sykipot, Zeus, etc.). >> http://it.slashdot.org/story/12/01/13/2216218/sykipot-trojan-variant-stea= ling-dod-smartcard-credentials >> http://www.secureworks.com/cyber-threat-intelligence/threats/zeus/ >=20 > Hm. I don't consider theft of a private key via trojan to be a > phish. It is an attack of course, and with similar impact but > not a phish according to my definition. Happy to be corrected > but I believe my definition is ok tbh. >=20 You may not, but the incident response world does. I can get you some links= to show why I think this is a problem. I've been deeply embedded in the in= cident response world for several years and the folks that work on phishing a= ttacks include the download of malware/Trojans that result when a user click= s on a link in a phishing email as part of a phishing attack. The malware/T= rojans frequently steal credentials among other data of interest. The APWG h= elps with the takedown of malware distribution servers as part of their resp= onse to the phishing use case they support (they do a few other attack types= now too). >>=20 >> There would just be a short window until HOBA was defeat-able in spear >> phishing related attacks using trojans installed on the client. >=20 > Yes, but that would not be a phishing attack. HOBA is, as the > abstract correctly states "not vulnerable to phishing attacks." See above, I disagree as the common usage includes the download of malware a= s part of a phishing attack.=20 >=20 >>=20 >> By simply stating the password theft, you are covering more attack >> types that steal passwords on the client side than just those used as >> part of phishing attacks and lower the complexity from using a full >> blown PKI. This is what I think you need to target HOBA's use toward. >>=20 >> Section 1 >> Curious as to how it scales since it seems private/public keys pairs >> would have to be stored, but I guess that's no different than >> passwords. Maybe it doesn't matter with that assumption. >=20 > Yep. Scaling isn't a differentiator, it's linear in the size of > the user population basically. I've used the same nosql DB as is > used on hoba.ie with millions of entries on a standard server > with no issues at all. Thanks. >=20 >>=20 >> In the third paragraph possible attacks on the server side are >> mentioned when passwords are used, you should also mention client side >> issues like password theft and re-use (on same site or others) will be >> prevented. >=20 > I'm not clear that that's worth adding but don't object. I > do think the password verifier DB theft issue is the main > distinction between HOBA and password based schemes though > so would prefer keep that front and centre. (And as you > say later, that issue is called out eventually.) It was a way to get away from the phishing comment to what it actually helps= prevent. >=20 >> You may or may not want to include this, but it does have >> traction/interest in industry to improve password authentication: >> Other mechanisms with Basic could combine with other factors to use >> 'risk-based' authentication systems (geo-location, system properties, >> etc.). HOBA could do this too. This may include browser information >> (make sure it's the same one each time or prompt with some other auth >> if it changes), IP layer information to get geo-location (can't travel >> somewhere in less than x hours - doesn't make sense). >=20 > I don't think it'd be a good idea to start to describe other > mechanisms here, nor to try cover multi-factor authentication. > There is a fine RFC to be written on that, but this ain't it:-) > If we tried that, we'd face potentially endless comment from > all sides which I don't think would be worthwhile. And it'd > also cause issues for other WG drafts too maybe if some do, and > some don't try describe multi-factor auth issues. It's used in industry to help prevent attacks that involve credentials, like= reuse of credentials stolen in phishing attacks ;-). I'm not sure there is= interest to standardize, but wanted to point this out since it's commonly u= sed (pretty ubiquitous in the financial sector). >=20 >> Section 5 >> If this is describing both HTTP HOBA and HOBA-js, it would be good to >> state that explicitly and differences that should be noted. The intro >> reads as if it is just for HTTP, if that's the case, then leave it >> alone. >=20 > Well, we only use the -http and -js when necessary (i.e. when > there's a difference) and leave it implicit when its obvious > or doesn't matter. Does it matter here? (I've no problem adding > that this covers both if that helps, but I'm not clear it does > help.) If you could just state what's intended for section 5 so it's clear to the r= eader, that will help. Thanks. >=20 >> Section 5.3 >> Second to last paragraph, first time you use the term join (I think), >> you should provide a reference or explain what it means as this will >> likely be asked in subsequent reviews. You describe it in section >> 6.1, I think it would be better to have the explanation in this >> section. >=20 > Good point. I think the following para of 5.3 addresses the > issue though. Probably good to not say "already joined" as > the first occurrence mind you. >=20 > I guess s/already-joined/another/ would be a good change, as > it's clarified in the next para. (Did that in our author's svn > copy.) Thanks. >=20 >>=20 >> Section 6 >> What do you mean by "All additional services MUST be performed in >> TLS-protected sessions"? If you are referring to HOBA and HOBA-js or >> the authentication process as the additional service, it would be >> better to state that explicitly. >=20 > All meaning all:-) We didn't see any point in being selective > so the all-TLS thing seems easier. You need TLS at least to > ensure there's no MITM handing off challenges or new public > keys being submitted etc. So I'm not sure what's not clear tbh. The use of the word additional is what raised the question for me. Can you r= emove it? >=20 >>=20 >> Section 8.2 >>=20 >> Second paragraph: current text: >> Again it's not clear that we are >> worse in this regard because the same attacker could get at browser >> password files, etc too. One possible mitigation is to encrypt the >> keystore with a password/pin the user supplies. This may sound >> counter intuitive, but the object here is to keep passwords off of >> servers to mitigate the multiplier effect of a large scale compromise >> ala LinkedIn because of shared passwords across sites. >>=20 >> Proposed update: >> Again it's not clear that we are >> worse in this regard because the same attacker could get at browser >> password files, stored PKI credentials (even via PKCS#11 interface), >> etc too. One possible mitigation is to encrypt the >> keystore with a password/pin the user supplies. This may sound >> counter intuitive, but the object here is to keep passwords off of >> servers to mitigate the multiplier effect of a large scale compromise >> ala LinkedIn because of shared passwords across sites. This >> recommendation does not help against possible client side attacks, >> which are inevitable with the use of phishing/spear phishing related >> malware and trojans. >>=20 >> Explanation: >> All forms of keys stored on a computer have been subject to attacks, >> including attacks that automate this theft of passwords and even PKI >> credentials in malware. The last sentence of paragraph 2 could be >> stronger to reflect this inevitability. Storing the credentials in an >> external secure container does help, but those have been successfully >> attacked too. >=20 > I agree with your last but the section here is specific to > HTPM5 localStorage as a private key store so pkcs#11 isn't > relevant at this point. Is just the point that this will be broken, it's pretty much inevitable. > And I think we've hit that difference > in our definitions of phishing again too:-) I'll get some links to show the common usage and use case descriptions of ph= ishing and spear phishing attacks tomorrow. >=20 > So I'd suggest no change there. >=20 >=20 >> I'm glad to see the password re-use problem mentioned in the last >> paragraph, so you don't need that in the intro, but I'll leave my >> comment there as it is part of the overview as to why it might be a >> good idea to use HOBA. You may want to emphasize the difficulty of >> PKI and the advantage of preventing server side password database >> attacks since the credentials can be stolen on the client side (or >> will be once deployed). This has a niche and we should be clear on >> that IMO. >=20 > Fair points but I think the audience for this are probably aware > of all that. I don't think we should try sell HOBA in the RFC, > but just define it - the sales pitch that is absolutely required > is for elsewhere/others. But maybe others think differently. I was just trying to get you away from the phishing angle as it won't work f= or long. Have a good night. Kathleen >=20 > Cheers, > S. >=20 >=20 >>=20 >>=20 From nobody Tue Dec 2 03:16:12 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC051A1AAC; Tue, 2 Dec 2014 03:16:10 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRaFLzjLDArT; Tue, 2 Dec 2014 03:16:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5461A1AA0; Tue, 2 Dec 2014 03:16:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> Date: Tue, 02 Dec 2014 03:16:08 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Op1Yfq79cJZ9HVqwmG0HNDWPxuQ Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 11:16:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : The 'Basic' HTTP Authentication Scheme Author : Julian F. Reschke Filename : draft-ietf-httpauth-basicauth-update-03.txt Pages : 14 Date : 2014-12-02 Abstract: This document defines the "Basic" Hypertext Transfer Protocol (HTTP) Authentication Scheme, which transmits credentials as userid/password pairs, obfuscated by the use of Base64 encoding. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-update-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 2 03:19:48 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3EE1A1A9F for ; Tue, 2 Dec 2014 03:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in_9DXlx4WlW for ; Tue, 2 Dec 2014 03:19:44 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C461A1A9B for ; Tue, 2 Dec 2014 03:19:44 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so16447484wgh.26 for ; Tue, 02 Dec 2014 03:19:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=LSKpUhugXy7KP87EkmRU6oBT9VCXWBDJtCPgpJpK+Yc=; b=D+Sol4EnM2RdzBEMIE+At2ouUyxPXp2M2Uzi7BVUWo75QEzac0ewX/yATkS+YGIArW lHoaP+RF109TWq5kUBV1aDScssaBem/RCk4OVnYdE691Z+MOOMgi6FM1rVtzq8a7OmND holLmcLEzWxRRFwi1Zd9sZ8mHaNYuJ/qQQ7ygp6bSCY03wlvQkL0yR04SD0b82uT4Lsd 30Gn1xSRylSU0r2eoJ6gabrHH8IGXF5x5WcQ1S4bYf7N75CFDSqX0Sg9fD5PAkitcWPM 1nJCAAUiPpzhLnoibHbyuRDedtOYJfG9huZSvSYkwR3SJo4ifXnMSwU6pdNs/+Wq0u+9 tKwA== X-Received: by 10.194.223.101 with SMTP id qt5mr30184301wjc.29.1417519183089; Tue, 02 Dec 2014 03:19:43 -0800 (PST) Received: from [172.24.251.68] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id mw7sm32338019wib.14.2014.12.02.03.19.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 03:19:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> Date: Tue, 2 Dec 2014 13:19:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> To: IETF HTTP Auth X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/CQHHsXwAPvhYcMUiW4nR5B3fipE Subject: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 11:19:46 -0000 Thank you, Julian This begins a 2-week WGLC for this document. Please take the time to read through and post any comments to the list. Cheers Matt & Yoav > On Dec 2, 2014, at 1:16 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Hypertext Transfer Protocol = Authentication Working Group of the IETF. >=20 > Title : The 'Basic' HTTP Authentication Scheme > Author : Julian F. Reschke > Filename : draft-ietf-httpauth-basicauth-update-03.txt > Pages : 14 > Date : 2014-12-02 >=20 > Abstract: > This document defines the "Basic" Hypertext Transfer Protocol (HTTP) > Authentication Scheme, which transmits credentials as = userid/password > pairs, obfuscated by the use of Base64 encoding. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-03 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-basicauth-update-03= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Tue Dec 2 04:51:39 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153281A1B3B for ; Tue, 2 Dec 2014 04:51:38 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTsDmaKf2y3o for ; Tue, 2 Dec 2014 04:51:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE9B1A1B2E for ; Tue, 2 Dec 2014 04:51:36 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M50aI-1Y69nv3x4I-00zFvV for ; Tue, 02 Dec 2014 13:51:34 +0100 Message-ID: <547DB5D1.5040909@gmx.de> Date: Tue, 02 Dec 2014 13:51:29 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "http-auth@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:eFgKvZoWEUJ4nbdAo/G01nUHPU15x7yJg4hKtELQANCKUqqq3oO P3DpWTN5FUoRYN58J1ROGNGfbsZCFelvvXSw+N11ziNYPEWV6DJVzFG+d1r1qRHZAk6KRRy ZpCD6gcDfntLk5ajEeL+9kNHlZZzZtDznaoSFmNgVZQwOoRKN9aUC3K2M75D3D2VWf7EupG VKJEovqtxUaqv1F2KXEAQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/rJZgi2Un-u16fV_PDgmBJDnfquU Subject: [http-auth] Authentication-Info X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 12:51:38 -0000 Hi there, this is a minor outstanding issue with the Digest and SCRAM drafts. It was discussed in both the WG sessions and in hallway conversations. This header field originally was defined in the "Digest" part of RFC 2617, and consequently, it was copied over into . currently uses it as well, but with with a slightly differing syntax. Given the fact that we have two authentication scheme definitions that have a use case for this header field -- shouldn't we define it in a way so that it becomes a generic (optional) feature for authentications schemes? Choices: 1) The cleanest approach seems to move the definition into a separate spec which later can be absorbed by a future RFC7235bis. I volunteer to write that spec (it'll be very short), but this would require changes to the Digest spec post-WGLC. 2) Alternatively, we could tune the Digest draft to introduce the header field in a more generic way, allowing other schemes to use it as well. That would avoid a dependency to a yet unwritten spec, but the complexity wouldn't really change. 3) We can tell Alexey to pick a different field name, which would shift all required changes to the SCRAM spec. Feedback appreciated, Julian From nobody Tue Dec 2 06:06:34 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC1C1A1B3D for ; Tue, 2 Dec 2014 06:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSZNCou92iav for ; Tue, 2 Dec 2014 06:06:16 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03231A1B99 for ; Tue, 2 Dec 2014 06:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417529175; x=2281442775; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=r7xLie2wAfb/VgXDfxH2H5q9l8b2OTRHCzFEOX1840I=; b=MwiUP/ByJ7fBDg53eR7UYKTv1oJ5pNj9sgrGNdsZlMi2jAUBMHJ220vUYcsi6YKO CrQGWHh4eMtx6NK1iHKWuNDQqAl0uRLLTNI2H3nmFgigGId8G7Zo6h4TtZHFqJRD d8rWR+wXMJCO6MwuS3RA8aFsRl0Dedcop2KwjXI8urynyT/7sumGLthSV+qxRLVm mhygO68qc7AlSHTBf72gUQZdjAXHLujMM+oErww7hU1rf59R0kGXSgbJIfDFG6K6 5oaiTISFXiLZDKvCvRucPbw0cLkWftHiLudnEcCaj2W1r0OyQevtyYyCxy3HQMn7 KkRbjf2IGDAJmrrQCkNoqw==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 22.E8.02334.757CD745; Tue, 2 Dec 2014 06:06:15 -0800 (PST) X-AuditID: 11973e13-f79ee6d00000091e-67-547dc7573a44 Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id F9.7D.05858.157CD745; Tue, 2 Dec 2014 06:06:09 -0800 (PST) Received: from [17.153.21.172] by cardamom.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NFY00GX2KIB9720@cardamom.apple.com> for http-auth@ietf.org; Tue, 02 Dec 2014 06:06:14 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-type: multipart/signed; boundary="Apple-Mail=_C35528BA-59FE-4DE4-B081-DF47D3BD4D3A"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <547DB5D1.5040909@gmx.de> Date: Tue, 02 Dec 2014 09:06:11 -0500 Message-id: <80CDF820-6493-46BD-BB36-2E4990B966DF@apple.com> References: <547DB5D1.5040909@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUi2FDorBt+vDbE4PV9FosP++cwOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4868TewF9z0qmrdPZmxgvOrcxcjJISFgIjF5+U8mCFtM4sK9 9WwgtpDAXkaJXy89uhg5wGo2vE/qYuQCCk9kkrjy8To7hPOHUWJRyzpWkAZhAR2Je8+Ogtm8 AnoSTU8eM4EUMQtMYZTYPn8G2FQ2ATWJ35P6wIo4gewDv6cxg9gsAqoS77dvYgGxmQV0JZae 7GaEGGQj8Xrzd2aIi1Ql5izYAFYjIqAlcfveXkaIq2Ul/l08ww5hb2CTWHIucQKj0Cwkd8xC dscssB3aEssWvmaeBfQdM9DhkxcyQoRNJZ683Q5VYi3xc84jqLiixJTuh+wLGNlXMQrlJmbm 6GbmmeolFhTkpOol5+duYgTFw3Q74R2Mp1dZHWIU4GBU4uE9cb4mRIg1say4MvcQozQHi5I4 7y792hAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjM2u7YzvFN+qHnxXdFvE4uIZXR67PynN rbvXik9iniBjFvH0Yo5xVLRfxqI12/n1Hr+UtXfyimSXCbv8IujRrMPTNxb/fX5718E4a6Pt 7w9NedIQHtdR5zRL/OIVoUj+s15l8zkSjtXxt4vNFNj4a2OCS8fTts/MZmKleffrf5sxxvM0 rd/Mp8RSnJFoqMVcVJwIAEYo8wFoAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUi2FAcpxt4vDbEYNllTosP++cwOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4868TewF9z0qmrdPZmxgvOrcxcjBISFgIrHhfVIXIyeQKSZx 4d56ti5GLg4hgYlMElc+XmeHcP4wSixqWccKUiUsoCNx79lRMJtXQE+i6cljJpAiZoEpjBLb 589gA0mwCahJ/J7UB1bECWQf+D2NGcRmEVCVeL99EwuIzSygK7H0ZDcjxCAbidebv4PVCAHV zFmwAaxGREBL4va9vYwQ58lK/Lt4hn0CI/8sJLtnIds9C2yutsSyha+ZZwF9xwx07OSFjBBh U4knb7dDlVhL/JzzCCquKDGl+yH7Akb2VYwCRak5iZVGeokFBTmpesn5uZsYwSFc6LyD8dgy q0OMAhyMSjy8J87XhAixJpYVV+YeYlQBGvFow+oLjFIsefl5qUoivL+Ma0OEeFMSK6tSi/Lj i0pzUosPMUpzsCiJ81Y9yg0REkhPLEnNTk0tSC2CyTJxcEo1MM4tTV+w3bMzJnn+50PzNvuX TFhydZ930c08xtrNn8QEnnsy9jx12NGZs39vxK9ypSurbyx7YPiFiWfXT+1rypH/DHKb/yl7 3356/pK8q1id2bKfMR5H1NZc1vzxb+Euu/CEZa+c/Q+8u7X6X2tI4aSz3fxzlGYffRbfmGK3 Yeu6rSr6r96EX9RQYinOSDTUYi4qTgQAAg+y+WkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/vg4yDcdGx5K0QGfQcOIN5QX4PAc Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Authentication-Info X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:06:23 -0000 --Apple-Mail=_C35528BA-59FE-4DE4-B081-DF47D3BD4D3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Julian, > On Dec 2, 2014, at 7:51 AM, Julian Reschke = wrote: >=20 > Hi there, >=20 > this is a minor outstanding issue with the Digest and SCRAM drafts. It = was discussed in both the WG sessions and in hallway conversations. >=20 > This header field originally was defined in the "Digest" part of RFC = 2617, and consequently, it was copied over into = . >=20 > = currently uses it as well, but with with a slightly differing syntax. >=20 > Given the fact that we have two authentication scheme definitions that = have a use case for this header field -- shouldn't we define it in a way = so that it becomes a generic (optional) feature for authentications = schemes? >=20 > Choices: >=20 > 1) The cleanest approach seems to move the definition into a separate = spec which later can be absorbed by a future RFC7235bis. I volunteer to = write that spec (it'll be very short), but this would require changes to = the Digest spec post-WGLC. >=20 > 2) Alternatively, we could tune the Digest draft to introduce the = header field in a more generic way, allowing other schemes to use it as = well. That would avoid a dependency to a yet unwritten spec, but the = complexity wouldn't really change. >=20 > 3) We can tell Alexey to pick a different field name, which would = shift all required changes to the SCRAM spec. In the interests of schedule, I would favor options 2 and 3. In the interests of reuse/generic use, option 2 would seem to be the way = to go. If we want to minimize changes to both specs, then extending the ABNF in = the digest spec to include an optional initial auth-scheme would take of = things. Alternately we can just define a standard "scheme" parameter = that contains the auth-scheme value, which has the added benefit of = allowing new Digest implementations to include it without breaking = existing ones. (and of course nothing prevents a 7235bis from adopting the definition = in the new Digest spec, you just avoid the delay of developing a = dependent spec now...) _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_C35528BA-59FE-4DE4-B081-DF47D3BD4D3A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO0jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUiMIIECqADAgECAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzEyMTcw MDAwMDBaFw0xNDEyMTcyMzU5NTlaMCExHzAdBgkqhkiG9w0BCQEWEG1zd2VldEBhcHBsZS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDXb0GGUQlc3NMCGLyDp/9D7+81MLiL2wHz P1txcnpqmcd33SsV+FsTdseTQt4YQRxq1FoqyR+65eiLddmxkOtbhwCuY7CYpFeZPpjmI2WijSCs Y9LmCJNzCkJrJjPLd53XauZqdpscFf1OwBT089X4IXZKk2/zZB2OXgPCqpLGnqsHzIKGohlXglIa bVp16LHGvDwJG/ovbuaxKJOc4GPkD9CLliyRDXwOKnRDLB/jgMDBjr/XzQoHHWqRZ43kmGo+9Juq lIquOOvvGtq4VLBFCkGsjjII55tm4FLjce6Tr7PyYMyJWaE8/5ZZhNR1kRBs0o0Zy1sEPfH7KX3m VgPvAgMBAAGjggHgMIIB3DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4E FgQU7SgSaBvZMWYrE6iYOPsK9dpeLLYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYD VR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAE PzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8u bmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHow UgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9k b2NhLmNvbTAbBgNVHREEFDASgRBtc3dlZXRAYXBwbGUuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAY OSi0CubvYBiO+bvr2B/4urjAypaUyCzv6/xaTdom6qcAAdpZ/aCrzyANf696PgwQvO06p5SQIj1u AAxR6UZqpaa29E7vaffJz/8JebQWYxD/HWOIh9Ewdwdq/SR8EcMCUNtAqiabgp/XZry9tebGUqry X5blZSHAEAi8ad2SjCAtqTSorbMHY4x3bmiro9kzHsa8zLa0RkbRRfaXDHJ7KhNkLSVKlz1e/zOF k9skVJiOE4T7fTvX5jx9pLudoXW+reKl78HUEpAx7caNyf1XP4w0dv33nnQ4UJhtFfY+rR7Lhum1 VYXBolp0pkqD34NdxZUMJcWU8hbYjGdoyC8qMYIDrjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMAkGBSsOAwIaBQCgggHZMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTIwMjE0MDYxMVowIwYJ KoZIhvcNAQkEMRYEFMHrPm4JUxT4QGFRzSp6i0ELxS5wMIG6BgkrBgEEAYI3EAQxgawwgakwgZMx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMIG8Bgsq hkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNV BAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUH t1fFyUsR52q4+8ZfwIYwDQYJKoZIhvcNAQEBBQAEggEALD1yQJbZa6fPEFjjzq2y4ydM3thMF73K WFEhaQ426tH0bdRWAT/C08pPdF0HHfqvVm7LKnh416PIXQdzktxFuHdgj8f3FnO9AHGqoxqbnBdb a4IjnlviVDlX7ypBPhDoiaTPa9nVTG/x0xZ9IIZrbOOgavC9zW1SqwQrfWc+2yGAPdFgczemO3Jl JEd32O3GkToFG8izhJtw49lVVCqlmKlinMvucCgDNtFv9BEcdxCaxbOAeQBYcD3PgqFKUncQKePY 1ctrGRX6xMIuWtnAY7tRo+/kBcxDLTGa/XqZ41bZ5RLSsfnW6ZSJHGbQkRZaQB6w6Qz6sRMveeVw jsKHYwAAAAAAAA== --Apple-Mail=_C35528BA-59FE-4DE4-B081-DF47D3BD4D3A-- From nobody Tue Dec 2 06:11:46 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77391A1B6D for ; Tue, 2 Dec 2014 06:11:40 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUV-KudjVfpC for ; Tue, 2 Dec 2014 06:11:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921DE1A1B68 for ; Tue, 2 Dec 2014 06:11:33 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lkwc9-1YTUxk3uuj-00ajIK; Tue, 02 Dec 2014 15:11:26 +0100 Message-ID: <547DC889.1070607@gmx.de> Date: Tue, 02 Dec 2014 15:11:21 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Sweet References: <547DB5D1.5040909@gmx.de> <80CDF820-6493-46BD-BB36-2E4990B966DF@apple.com> In-Reply-To: <80CDF820-6493-46BD-BB36-2E4990B966DF@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Hm2S28Yjr0lKrssCVItuCvHAdeG4czVFTAo4yVLoctBqDbogsxG wm+AQgdbHiNwn9fNPFRXw5c4V0CUqE7otlz4c/GF0wiKruPpwq57T4Kx4JX/C1iL/bZjuue QvEHqQrynv6/Ba+wCem4BYIhU1pwvak6UZpIIOOicDS2DiCzfSkL8SxM3r3RPGp18jou5jG cMskZdBQ5JECE2iYmvDqQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/dtJtCNVMCraToOmarXmHlgDZGyA Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Authentication-Info X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:11:41 -0000 On 2014-12-02 15:06, Michael Sweet wrote: > Julian, > >> On Dec 2, 2014, at 7:51 AM, Julian Reschke wrote: >> >> Hi there, >> >> this is a minor outstanding issue with the Digest and SCRAM drafts. It was discussed in both the WG sessions and in hallway conversations. >> >> This header field originally was defined in the "Digest" part of RFC 2617, and consequently, it was copied over into . >> >> currently uses it as well, but with with a slightly differing syntax. >> >> Given the fact that we have two authentication scheme definitions that have a use case for this header field -- shouldn't we define it in a way so that it becomes a generic (optional) feature for authentications schemes? >> >> Choices: >> >> 1) The cleanest approach seems to move the definition into a separate spec which later can be absorbed by a future RFC7235bis. I volunteer to write that spec (it'll be very short), but this would require changes to the Digest spec post-WGLC. >> >> 2) Alternatively, we could tune the Digest draft to introduce the header field in a more generic way, allowing other schemes to use it as well. That would avoid a dependency to a yet unwritten spec, but the complexity wouldn't really change. >> >> 3) We can tell Alexey to pick a different field name, which would shift all required changes to the SCRAM spec. > > In the interests of schedule, I would favor options 2 and 3. I believe we can get done 1) quickly enough. > In the interests of reuse/generic use, option 2 would seem to be the way to go. > > If we want to minimize changes to both specs, then extending the ABNF in the digest spec to include an optional initial auth-scheme would take of things. Alternately we can just define a standard "scheme" parameter that contains the auth-scheme value, which has the added benefit of allowing new Digest implementations to include it without breaking existing ones. Changing the syntax sounds like a breaking change to Digest to me. Adding a scheme *parameter* would work, but I wonder why that is needed anyway. Alexey? > (and of course nothing prevents a 7235bis from adopting the definition in the new Digest spec, you just avoid the delay of developing a dependent spec now...) > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > Best regards, Julian From nobody Tue Dec 2 06:25:11 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB08D1A1B6D for ; Tue, 2 Dec 2014 06:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ey9JtOie2wNg for ; Tue, 2 Dec 2014 06:25:07 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA781ACDFF for ; Tue, 2 Dec 2014 06:25:06 -0800 (PST) Received: from localhost.localdomain (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id sB2EP4Ov008034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Dec 2014 09:25:05 -0500 Message-ID: <547DCBC0.4090202@andrew.cmu.edu> Date: Tue, 02 Dec 2014 09:25:04 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: http-auth@ietf.org References: <547DB5D1.5040909@gmx.de> In-Reply-To: <547DB5D1.5040909@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.2.141532 X-SMTP-Spam-Clean: 33% ( SXL_IP_DYNAMIC 3, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1700_1799 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 33% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.204 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/iAuVRtiPORXLBphSsaf-wDSTQIk Subject: Re: [http-auth] Authentication-Info X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:25:09 -0000 On 12/02/2014 07:51 AM, Julian Reschke wrote: > Hi there, > > this is a minor outstanding issue with the Digest and SCRAM drafts. It > was discussed in both the WG sessions and in hallway conversations. > > This header field originally was defined in the "Digest" part of RFC > 2617, and consequently, it was copied over into > . > > > currently uses it as well, but with with a slightly differing syntax. > > Given the fact that we have two authentication scheme definitions that > have a use case for this header field -- shouldn't we define it in a > way so that it becomes a generic (optional) feature for > authentications schemes? > > Choices: > > 1) The cleanest approach seems to move the definition into a separate > spec which later can be absorbed by a future RFC7235bis. I volunteer > to write that spec (it'll be very short), but this would require > changes to the Digest spec post-WGLC. I'm in favor of this approach. > > 2) Alternatively, we could tune the Digest draft to introduce the > header field in a more generic way, allowing other schemes to use it > as well. That would avoid a dependency to a yet unwritten spec, but > the complexity wouldn't really change. This would be my second choice. > > 3) We can tell Alexey to pick a different field name, which would > shift all required changes to the SCRAM spec. This is a non-starter as far as I'm concerned. Two separate response header fields to return auth success data seems clumsy. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Tue Dec 2 06:25:32 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E021ACDFF for ; Tue, 2 Dec 2014 06:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUGq2hBrpZOs for ; Tue, 2 Dec 2014 06:25:28 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB20E1ACE0A for ; Tue, 2 Dec 2014 06:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417530321; x=2281443921; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Zhj7OKxh7H4T9gpTDLg2YhlWd/9AkDEDOBy9XFjAJK4=; b=JaycsvTd0iVY/qjvLcl1ZjlE1i2tTf6TxQvOr4huG1fyGkEmeACn4ywEGSE9vZ5d 6HFSKnLrIO3JAaRQAG/KKhhxHO/4E9sFT2IitfeOpLATZaHGoIvpVrdhhbPLGHuB n33hFD5oHC9A0BmRjyi1YUPgIZJDa5oU5Ypc2RFoBJKN8qk2b0nIKgwk/VJYjsuT YLEDKYUQF7amP0MEGiCjJ/oBp299HwH7GlMpfvnLZ3IiOEMo0jy0yHk0+7ko/iGG iBZ0p0l2eppH2B75rlvl9xvjFWCpobF+Ccuq05YHUmH1Thpn8nKKyMLtKtC458Jj OAP0n5icvLFOwarmIAo0sA==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id B0.0D.12968.1DBCD745; Tue, 2 Dec 2014 06:25:21 -0800 (PST) X-AuditID: 11973e12-f79306d0000032a8-c8-547dcbd1c02b Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 1A.E6.06091.2BBCD745; Tue, 2 Dec 2014 06:24:50 -0800 (PST) Received: from [17.153.21.172] by cardamom.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NFY00GEXLE69730@cardamom.apple.com> for http-auth@ietf.org; Tue, 02 Dec 2014 06:25:20 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-type: multipart/signed; boundary="Apple-Mail=_6E2499BD-56B4-4ACF-9615-D67956418C44"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <547DC889.1070607@gmx.de> Date: Tue, 02 Dec 2014 09:25:17 -0500 Message-id: <029A2653-2F50-4A75-BEC3-051C3D1CE93F@apple.com> References: <547DB5D1.5040909@gmx.de> <80CDF820-6493-46BD-BB36-2E4990B966DF@apple.com> <547DC889.1070607@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUi2FCYqnvxdG2Iwa0XrBYf9s9hcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs/ud0wFvywqtv35wdLA+Nmsi5GTQ0LAROLAlg1MELaYxIV7 69m6GLk4hAT2MUpM397LDFPUM+06K0RiIpPEku5jLBDOH0aJhrebWUCqhAV0JO49O8oKYvMK 6Ek0PXnMBFLELDCFUWLnoXuMIAk2ATWJ35P6wIo4gezHH46zg9gsAqoSx49OAbOZBXQllp7s ZoQYZCNxb2Mj2H1CAkUSJ/5uYQOxRQS0JG7f28sIcZ6sxL+LZ9hBlkkIrGGT+HzwI8sERqFZ SA6ZheyQWWBLtCWWLXzNDGEbSDztfMUKYZtKPHm7nQ3Ctpb4OecRVL2ixJTuh+wLGNlXMQrl Jmbm6GbmmeglFhTkpOol5+duYgTFxXQ7oR2Mp1ZZHWIU4GBU4uE9cb4mRIg1say4MvcQozQH i5I470792hAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjPUrFyzxc/B90Hg/6OqNhkW9c031 JnDMmPhjzXqBto3/9ad3J60XuOxh3H5DXGF5oYzm516RdTXb77GrnfyyeNcVRt29k5dMk3Wd 2aPktLpms3FTiVrL1VBffZeb+1qUupcW2csbqy5yVPh93KVNR9yT9VLhxoCpp3kSlMxSYgLf WB+6bGdyTImlOCPRUIu5qDgRAPRZ/GNsAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUi2FAcp7vpdG2IwdHnMhYf9s9hcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs/ud0wFvywqtv35wdLA+Nmsi5GTQ0LARKJn2nVWCFtM4sK9 9WxdjFwcQgITmSSWdB9jgXD+MEo0vN3MAlIlLKAjce/ZUbAOXgE9iaYnj5lAipgFpjBK7Dx0 jxEkwSagJvF7Uh9YESeQ/fjDcXYQm0VAVeL40SlgNrOArsTSk92MEINsJO5tbGQCsYUEiiRO /N3CBmKLCGhJ3L63lxHiPFmJfxfPsE9g5J+FZPcsZLtngc3Vlli28DUzhG0g8bTzFSuEbSrx 5O12NgjbWuLnnEdQ9YoSU7ofsi9gZF/FKFCUmpNYaa6XWFCQk6qXnJ+7iREcxoWpOxgbl1sd YhTgYFTi4T1xviZEiDWxrLgy9xCjCtCIRxtWX2CUYsnLz0tVEuH9ZVwbIsSbklhZlVqUH19U mpNafIhRmoNFSZw35VFuiJBAemJJanZqakFqEUyWiYNTqoGxznnSza9vVsjYBlhop8Y+qvvW HX0vlkP7e7eK07XUGemKy+ZvyKsXMJqSsPqrnXqe7qKuKOUvno43Db6wGNzTNN69cwdf7nXG lt+drgdY8tZJHZjJ/eOvDfPkX/Eu05/uOaizbisTp0GF2jyfEOb5xYvq1og/3H7hBtPuSu5K VmeLf3u/Lw5WYinOSDTUYi4qTgQAT1fbzGsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/MWthua8PXcCy2eqHShDQ_pqkPio Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Authentication-Info X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:25:30 -0000 --Apple-Mail=_6E2499BD-56B4-4ACF-9615-D67956418C44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > ... > Changing the syntax sounds like a breaking change to Digest to me. If optional, it wouldn't break Digest but would not provide a way for = new implementations to adopt it. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_6E2499BD-56B4-4ACF-9615-D67956418C44 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO0jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUiMIIECqADAgECAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzEyMTcw MDAwMDBaFw0xNDEyMTcyMzU5NTlaMCExHzAdBgkqhkiG9w0BCQEWEG1zd2VldEBhcHBsZS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDXb0GGUQlc3NMCGLyDp/9D7+81MLiL2wHz P1txcnpqmcd33SsV+FsTdseTQt4YQRxq1FoqyR+65eiLddmxkOtbhwCuY7CYpFeZPpjmI2WijSCs Y9LmCJNzCkJrJjPLd53XauZqdpscFf1OwBT089X4IXZKk2/zZB2OXgPCqpLGnqsHzIKGohlXglIa bVp16LHGvDwJG/ovbuaxKJOc4GPkD9CLliyRDXwOKnRDLB/jgMDBjr/XzQoHHWqRZ43kmGo+9Juq lIquOOvvGtq4VLBFCkGsjjII55tm4FLjce6Tr7PyYMyJWaE8/5ZZhNR1kRBs0o0Zy1sEPfH7KX3m VgPvAgMBAAGjggHgMIIB3DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4E FgQU7SgSaBvZMWYrE6iYOPsK9dpeLLYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYD VR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAE PzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8u bmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHow UgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9k b2NhLmNvbTAbBgNVHREEFDASgRBtc3dlZXRAYXBwbGUuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAY OSi0CubvYBiO+bvr2B/4urjAypaUyCzv6/xaTdom6qcAAdpZ/aCrzyANf696PgwQvO06p5SQIj1u AAxR6UZqpaa29E7vaffJz/8JebQWYxD/HWOIh9Ewdwdq/SR8EcMCUNtAqiabgp/XZry9tebGUqry X5blZSHAEAi8ad2SjCAtqTSorbMHY4x3bmiro9kzHsa8zLa0RkbRRfaXDHJ7KhNkLSVKlz1e/zOF k9skVJiOE4T7fTvX5jx9pLudoXW+reKl78HUEpAx7caNyf1XP4w0dv33nnQ4UJhtFfY+rR7Lhum1 VYXBolp0pkqD34NdxZUMJcWU8hbYjGdoyC8qMYIDrjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMAkGBSsOAwIaBQCgggHZMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTIwMjE0MjUxOFowIwYJ KoZIhvcNAQkEMRYEFI7qjGDSCCTufWCMQSlBdbk84WZ/MIG6BgkrBgEEAYI3EAQxgawwgakwgZMx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMIG8Bgsq hkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNV BAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUH t1fFyUsR52q4+8ZfwIYwDQYJKoZIhvcNAQEBBQAEggEAPkadlIMAcR+bkRwaz1pRdf9I8NU3DGb5 5EwV+yXRllbN8Sm4mFpUz5welleEk5GgOPTcvtnVKHZ/q4AAntIIDFZdInX/Wxh13UVRCLN+7zbd P8jYMb3HM+hZY0XzlwrDGfBUPVTaZijhxoX7gR2Js7m8mwLy+llkNqkkoNNgFCOKubWy+qdE5x5V ZqzdcvsHO1MHvifkv68OJONDFnRDnlPZuLo4smOxAp4M9H6Ticzy/9I9QHAJm0J559DllUSjKmN5 zfadbMYnJH8cVwDDtUTELQooyiAcO2ne3fqrIddk6yNM9r+AGkt2x8HWFOmvDFxcvOK/fOFTj+gp C27CgwAAAAAAAA== --Apple-Mail=_6E2499BD-56B4-4ACF-9615-D67956418C44-- From nobody Tue Dec 2 06:34:45 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4097E1A1BAF for ; Tue, 2 Dec 2014 06:34:39 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfExNA-kqysU for ; Tue, 2 Dec 2014 06:34:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB881A1B93 for ; Tue, 2 Dec 2014 06:34:32 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M7pku-1Y8p6a3coq-00vR91; Tue, 02 Dec 2014 15:34:28 +0100 Message-ID: <547DCDEF.30701@gmx.de> Date: Tue, 02 Dec 2014 15:34:23 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Sweet References: <547DB5D1.5040909@gmx.de> <80CDF820-6493-46BD-BB36-2E4990B966DF@apple.com> <547DC889.1070607@gmx.de> <029A2653-2F50-4A75-BEC3-051C3D1CE93F@apple.com> In-Reply-To: <029A2653-2F50-4A75-BEC3-051C3D1CE93F@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:8iYF/+xAMPjgdOCuYs22oIdkWp4dZRtICWUEt5gnWuVzKprkWck imJFn3PWp5q0XwinzWmq72X3Gqq20BcP2cmbK6e/zZSUiS1w4GRr0G0j8sqzORGDUDCcKSr 6QfCgEm7Q3uOawU6rmTcA8+QQ8FEjfqq3myYw+m/CfdNDiLxMRGDMPVVsRbtFEgBpw6VbPn iGKJbJujlzoL3VDJ85y6g== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/KlcG3RbVRIGBKY-NA8dqSYxxq50 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Authentication-Info X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:34:39 -0000 On 2014-12-02 15:25, Michael Sweet wrote: > >> ... >> Changing the syntax sounds like a breaking change to Digest to me. > > If optional, it wouldn't break Digest but would not provide a way for new implementations to adopt it. Let's find out what the syntax variation is about before we start planning how to support it :-) Best regards, Julian From nobody Tue Dec 2 08:28:50 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847361A1E10 for ; Tue, 2 Dec 2014 08:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_a1QofKzLee for ; Tue, 2 Dec 2014 08:28:44 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E181A1C06 for ; Tue, 2 Dec 2014 08:28:40 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id z12so10571330lbi.4 for ; Tue, 02 Dec 2014 08:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zQ1M/rFIBCDXEDiIIfJBLL3uFr5308dpulHpyZcnnac=; b=c+4QwAngzXzeaIX3s2gCHgZW8hqGTvFd4ToFSqnRiIWpudsuE9zgTI/xxb1OZXQ9f3 WlDrVCECLH+VIrwLb0Lr0gPj07DRtOOz2laT5Rppa5pSfP4pj89GfB5ZQXRoKEYhrOEE xtThApRaAtanUzIx08J/e3rlefYPVrUvl6fpsYJeAYd7uFgF/2YWhYPwOxeTCvYgi4n5 rvDBRlzuZg3mbrUmr8AVMy1HFwG4cKqhYDbygrvCIuBqGZDbJOf8MYyz3HnDItzXPBML PVe57jYDmeY3zDoOUZ91YXGhjAjcncRsWtEcRPVstuU5dG/srTrqFBrdrbaBn4/lIwy+ MM6A== MIME-Version: 1.0 X-Received: by 10.152.238.1 with SMTP id vg1mr2677lac.83.1417537718763; Tue, 02 Dec 2014 08:28:38 -0800 (PST) Received: by 10.112.49.52 with HTTP; Tue, 2 Dec 2014 08:28:38 -0800 (PST) In-Reply-To: <78620582-D88B-4B58-9E98-15941A96809C@gmail.com> References: <547D0D59.5070104@cs.tcd.ie> <78620582-D88B-4B58-9E98-15941A96809C@gmail.com> Date: Tue, 2 Dec 2014 11:28:38 -0500 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/EHTqyRrssaUfGDEPAVklUpXs0QQ Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Review of draft-ietf-httpauth-hoba-05 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 16:28:48 -0000 Hello, As promised, I put together some additional information on phishing attacks and feel strongly that their mention should not be included. I'll answer a few other questions in line as well to clarify things where I can. Stephen is tied up in meetings today, so we may or may not get a response until later in the day. On Mon, Dec 1, 2014 at 8:24 PM, Kathleen Moriarty wrote: > Hi, > > Sent from my iPhone > >> On Dec 1, 2014, at 7:52 PM, Stephen Farrell = wrote: >> >> >> Hiya, >> >>> On 01/12/14 22:42, Kathleen Moriarty wrote: >>> Hi Stephen, Paul, & Michael, >>> >>> I reviewed the latest version of the HOBA draft and it is much >>> improved from earlier versions, thanks for your work on this draft. >>> Hopefully it will help mitigate threats to end users with reduced use >>> of passwords and associated attacks. >>> >>> Here are comments for you to consider: >> >> Cool. Thanks for the reivew. I'm not clear if you regard >> these as things that need fixing before IETF LC or as >> things to handle during/after IETF LC. I'm guessing the >> latter but not sure but it'll be clear as we argue or >> you start the IETF LC I guess:-) > > Either is fine. Nothing is too drastic in my review. It's simple enough to update with a few fixes and publish, so an -06 is appreciated prior to triggering last call. It's better to avoid the same discussions if possible and save some time. >> >> (So far, I made one change below in my local copy that'd go >> into a -06 whenever needed.) >> >>> >>> Abstract - >>> I'd remove the bit about phishing attacks and just state that it >>> prevents password theft since there are no passwords to steal, which >>> is covered nicely in the introduction. Phishing is a bit more >>> complicated, involves several steps that include social engineering to >>> get users to click on links, down;pad of malware/trojans, which are >>> difficult to defeat and may or may not be targeting credentials. >>> Spear phishing attacks that install trojans have been around for >> >> Not all trojan installs are phishing though. > No, but they are commonly part of the phishing and spear phishing attacks= that has the financial sector worried. I think you should just say what y= ou mean instead if lumping in phishing unnecessarily. > >> >>> several years and are able to steal all types of credentials including >>> PKI X.509 stored in PKCS#11 containers (Sykipot, Zeus, etc.). >>> http://it.slashdot.org/story/12/01/13/2216218/sykipot-trojan-variant-st= ealing-dod-smartcard-credentials >>> http://www.secureworks.com/cyber-threat-intelligence/threats/zeus/ >> >> Hm. I don't consider theft of a private key via trojan to be a >> phish. It is an attack of course, and with similar impact but >> not a phish according to my definition. Happy to be corrected >> but I believe my definition is ok tbh. I put together some information to help with an understanding on current definitions of phishing that include really any method of stealing credentials including crimeware, malware, and trojans. As such, my strong preference would be to remove mention of phishing and directly state the attack description that HOBA protects a user from and include what attacks to which it may be vulnerable. It adds unnecessary confusion and is not in line with current terminology to keep the term phishing. Attacks against HOBA are inevitable and will be used in the phishing world (whatever those attacks are - XXS, etc.), but in general, HOBA does provide improved protection against password theft and reuse. Stating that instead would be clearer to the reader and accurate. Phishing attacks are broad and cover lots of ground. They all start with a social engineering aspect, tricking a user to click on a link. The link may be a simple attack (not really the case anymore) or a complex web site pretending to be your financial institution in order to gather your credentials. While HOBA may help in that instance, the more common phishing attacks today include malware/Trojan (or crimeware that includes malware, trojans, etc., per the APWG) installs from the link the user is tricked into clicking on. The link could just as easily include a XXS attack. Phishing attacks will evolve to encompass attacks against HOBA. Even PKI stored via a PKSC#11 interface is vulnerable to phishing attacks - just not the same attack that steals your password, a variation that uses a trojan. As promised, I went through several sites to get updated definitions to help clear this up: Definitions in RFCs: The definition of phishing from RFC4949 captures the basic concept of phishing as a social engineering attack, but doesn't get into variations that have evolved over time. The first paragraph of the introduction in RFC5901 (2010 - but was really from 2007) explains the variations better n that malware can be part of the phishing attack. There's nothing to prevent Cross site scripting from being part of a phishing attack either. Wikipedia: https://en.wikipedia.org/wiki/Phishing The third sentence of wikipedia's definition includes mention of malware as well: "Phishing emails may contain links to websites that are infected with malwa= re." It case it helps to see examples of phishing attacks that are common today, here are a few more links: APWG: The APWG posts a Phishing Attack Trend report regularly so you can see the evolution: http://apwg.org/resources/apwg-reports/ They include an updated definition in the latest report that basically says techniques continue to evolve to steal credentials and include malware and other attack vectors. See the description of 'crimeware' (used in their definition) on page 9 as it includes multiple types. (My opinion - HOBA would only work against phishing attacks for a short period of time): http://docs.apwg.org/reports/apwg_trends_report_q2_2014.pdf RSA: Anatomy of an attack (phishing is a typical first step with malware installed to gain access) https://blogs.rsa.com/anatomy-of-an-attack/ >> > You may not, but the incident response world does. I can get you some li= nks to show why I think this is a problem. I've been deeply embedded in th= e incident response world for several years and the folks that work on phis= hing attacks include the download of malware/Trojans that result when a use= r clicks on a link in a phishing email as part of a phishing attack. The m= alware/Trojans frequently steal credentials among other data of interest. = The APWG helps with the takedown of malware distribution servers as part of= their response to the phishing use case they support (they do a few other = attack types now too). >>> >>> There would just be a short window until HOBA was defeat-able in spear >>> phishing related attacks using trojans installed on the client. >> >> Yes, but that would not be a phishing attack. HOBA is, as the >> abstract correctly states "not vulnerable to phishing attacks." > > See above, I disagree as the common usage includes the download of malwar= e as part of a phishing attack. See above updated definitions from good sources. >> >>> >>> By simply stating the password theft, you are covering more attack >>> types that steal passwords on the client side than just those used as >>> part of phishing attacks and lower the complexity from using a full >>> blown PKI. This is what I think you need to target HOBA's use toward. >>> >>> Section 1 >>> Curious as to how it scales since it seems private/public keys pairs >>> would have to be stored, but I guess that's no different than >>> passwords. Maybe it doesn't matter with that assumption. >> >> Yep. Scaling isn't a differentiator, it's linear in the size of >> the user population basically. I've used the same nosql DB as is >> used on hoba.ie with millions of entries on a standard server >> with no issues at all. > > Thanks. >> >>> >>> In the third paragraph possible attacks on the server side are >>> mentioned when passwords are used, you should also mention client side >>> issues like password theft and re-use (on same site or others) will be >>> prevented. >> >> I'm not clear that that's worth adding but don't object. I >> do think the password verifier DB theft issue is the main >> distinction between HOBA and password based schemes though >> so would prefer keep that front and centre. (And as you >> say later, that issue is called out eventually.) > > It was a way to get away from the phishing comment to what it actually he= lps prevent. > >> >>> You may or may not want to include this, but it does have >>> traction/interest in industry to improve password authentication: >>> Other mechanisms with Basic could combine with other factors to use >>> 'risk-based' authentication systems (geo-location, system properties, >>> etc.). HOBA could do this too. This may include browser information >>> (make sure it's the same one each time or prompt with some other auth >>> if it changes), IP layer information to get geo-location (can't travel >>> somewhere in less than x hours - doesn't make sense). >> >> I don't think it'd be a good idea to start to describe other >> mechanisms here, nor to try cover multi-factor authentication. >> There is a fine RFC to be written on that, but this ain't it:-) >> If we tried that, we'd face potentially endless comment from >> all sides which I don't think would be worthwhile. And it'd >> also cause issues for other WG drafts too maybe if some do, and >> some don't try describe multi-factor auth issues. > > It's used in industry to help prevent attacks that involve credentials, l= ike reuse of credentials stolen in phishing attacks ;-). I'm not sure ther= e is interest to standardize, but wanted to point this out since it's commo= nly used (pretty ubiquitous in the financial sector). >> >>> Section 5 >>> If this is describing both HTTP HOBA and HOBA-js, it would be good to >>> state that explicitly and differences that should be noted. The intro >>> reads as if it is just for HTTP, if that's the case, then leave it >>> alone. >> >> Well, we only use the -http and -js when necessary (i.e. when >> there's a difference) and leave it implicit when its obvious >> or doesn't matter. Does it matter here? (I've no problem adding >> that this covers both if that helps, but I'm not clear it does >> help.) > > If you could just state what's intended for section 5 so it's clear to th= e reader, that will help. Thanks. This one is left as a request, just calling it out so it doesn't get lost. Thanks. > >> >>> Section 5.3 >>> Second to last paragraph, first time you use the term join (I think), >>> you should provide a reference or explain what it means as this will >>> likely be asked in subsequent reviews. You describe it in section >>> 6.1, I think it would be better to have the explanation in this >>> section. >> >> Good point. I think the following para of 5.3 addresses the >> issue though. Probably good to not say "already joined" as >> the first occurrence mind you. >> >> I guess s/already-joined/another/ would be a good change, as >> it's clarified in the next para. (Did that in our author's svn >> copy.) > > Thanks. >> >>> >>> Section 6 >>> What do you mean by "All additional services MUST be performed in >>> TLS-protected sessions"? If you are referring to HOBA and HOBA-js or >>> the authentication process as the additional service, it would be >>> better to state that explicitly. >> >> All meaning all:-) We didn't see any point in being selective >> so the all-TLS thing seems easier. You need TLS at least to >> ensure there's no MITM handing off challenges or new public >> keys being submitted etc. So I'm not sure what's not clear tbh. > > The use of the word additional is what raised the question for me. Can y= ou remove it? This one too - just trying to not get it lost in a reply to myself :-) > >> >>> >>> Section 8.2 >>> >>> Second paragraph: current text: >>> Again it's not clear that we are >>> worse in this regard because the same attacker could get at browser >>> password files, etc too. One possible mitigation is to encrypt the >>> keystore with a password/pin the user supplies. This may sound >>> counter intuitive, but the object here is to keep passwords off of >>> servers to mitigate the multiplier effect of a large scale compromise >>> ala LinkedIn because of shared passwords across sites. >>> >>> Proposed update: >>> Again it's not clear that we are >>> worse in this regard because the same attacker could get at browser >>> password files, stored PKI credentials (even via PKCS#11 interface), >>> etc too. One possible mitigation is to encrypt the >>> keystore with a password/pin the user supplies. This may sound >>> counter intuitive, but the object here is to keep passwords off of >>> servers to mitigate the multiplier effect of a large scale compromise >>> ala LinkedIn because of shared passwords across sites. This >>> recommendation does not help against possible client side attacks, >>> which are inevitable with the use of phishing/spear phishing related >>> malware and trojans. >>> >>> Explanation: >>> All forms of keys stored on a computer have been subject to attacks, >>> including attacks that automate this theft of passwords and even PKI >>> credentials in malware. The last sentence of paragraph 2 could be >>> stronger to reflect this inevitability. Storing the credentials in an >>> external secure container does help, but those have been successfully >>> attacked too. >> >> I agree with your last but the section here is specific to >> HTPM5 localStorage as a private key store so pkcs#11 isn't >> relevant at this point. > > Is just the point that this will be broken, it's pretty much inevitable. Here and the Abstract are the places that may need some adjustment once agr= eed. > >> And I think we've hit that difference >> in our definitions of phishing again too:-) > > I'll get some links to show the common usage and use case descriptions of= phishing and spear phishing attacks tomorrow. >> >> So I'd suggest no change there. >> >> >>> I'm glad to see the password re-use problem mentioned in the last >>> paragraph, so you don't need that in the intro, but I'll leave my >>> comment there as it is part of the overview as to why it might be a >>> good idea to use HOBA. You may want to emphasize the difficulty of >>> PKI and the advantage of preventing server side password database >>> attacks since the credentials can be stolen on the client side (or >>> will be once deployed). This has a niche and we should be clear on >>> that IMO. >> >> Fair points but I think the audience for this are probably aware >> of all that. I don't think we should try sell HOBA in the RFC, >> but just define it - the sales pitch that is absolutely required >> is for elsewhere/others. But maybe others think differently. > > I was just trying to get you away from the phishing angle as it won't wor= k for long. Thanks, Kathleen > > Have a good night. > Kathleen >> >> Cheers, >> S. >> >> >>> >>> --=20 Best regards, Kathleen From ric.azevedo@gmail.com Wed Dec 3 07:34:41 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59CF1A1B56 for ; Wed, 3 Dec 2014 07:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYe1-K2DMa81 for ; Wed, 3 Dec 2014 07:34:39 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94FC81A1B91 for ; Wed, 3 Dec 2014 07:34:37 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so33554095wib.5 for ; Wed, 03 Dec 2014 07:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=v0icV1G+E9Q9avzR5SZztQvKaB6YGx9fclVHz+R80UM=; b=IkkdFNbnm7K5Fgnru7roeJWwKLbwZeNvGTFS3fba+06agKzYvlct/12IYhp5pp8lLx 0+pShAkZQ2RVH+nuXwLbzc6oag8/PqMppuXdWfpdOwHWOcCV0oFSTAgVW1KHEZiGt24w bPNu89jEhGx9sa+bhCiBgYf2hFPpe8bQhoYphJ1XRLssT4pzh81qrO+vsJte6xkYqS/t 2eRB1qewLtHVj+ec38GcSwMyR6Kh5BCRXO/tdbIsUgeMOvReQIYkXmLhz/IUeUjUs3FD OWoQAOGh0T0tv0sfJPGBNK/Bu9GxY3AkiDgbSDeA6F8KHSv8wk3JznHTEQn7+XEwC9qh RW3g== X-Received: by 10.180.108.167 with SMTP id hl7mr14122060wib.68.1417620876299; Wed, 03 Dec 2014 07:34:36 -0800 (PST) MIME-Version: 1.0 From: Ricardo Azevedo Date: Wed, 03 Dec 2014 15:34:35 +0000 Message-ID: To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=e89a8f3ba343c213ec05095194bb Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/w2w6nBUnUgFvt24cAkkzdM8lM1U X-Mailman-Approved-At: Wed, 03 Dec 2014 07:38:48 -0800 Cc: =?UTF-8?Q?Fabio_Gon=C3=A7alves?= Subject: [http-auth] HOBA implementation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 15:36:01 -0000 --e89a8f3ba343c213ec05095194bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, We would like to tell you all we released an implementation of the =E2=80= =9CHTTP Origin-Bound Authentication (HOBA) draft-ietf-httpauth-hoba-05=E2=80=9D. Please find it on GitHub (https://github.com/razevedo/hoba-authentication) under a MIT license. Your comments are welcomed. best, ricardo azevedo --e89a8f3ba343c213ec05095194bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

<= /div>
We would l= ike to tell you all we released an im= plementation of the =E2=80=9CHTTP Origin-Bound Authentication (HOBA) draft-ietf-httpauth-hoba-05=E2=80=9D.

Please find it on GitHub (https://github.com/raz= evedo/hoba-authentication) under a MIT license.

Your comm= ents are welcomed.

best,

ri= cardo azevedo

--e89a8f3ba343c213ec05095194bb-- From nobody Wed Dec 3 07:47:22 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5421B1A1B3E for ; Wed, 3 Dec 2014 07:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FLQQb9E92vZ for ; Wed, 3 Dec 2014 07:47:19 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029411A1B6E for ; Wed, 3 Dec 2014 07:47:18 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id sB3FlIN5002123 for ; Wed, 3 Dec 2014 07:47:18 -0800 Message-ID: <547F3086.9000104@mtcc.com> Date: Wed, 03 Dec 2014 07:47:18 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: http-auth@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070708080305020205050601" Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/hJImkLZADwmdQnlvczG-7P33HcM Subject: Re: [http-auth] HOBA implementation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 15:47:20 -0000 This is a multi-part message in MIME format. --------------070708080305020205050601 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 12/03/2014 07:34 AM, Ricardo Azevedo wrote: > Hi, > > We would like to tell you allwe released an implementation of the > “HTTP Origin-Bound Authentication (HOBA) draft-ietf-httpauth-hoba-05”. > > Please find it on GitHub > (https://github.com/razevedo/hoba-authentication) under a MIT license. > > Your comments are welcomed. > > Wow! Can't wait to take a look! Mike --------------070708080305020205050601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 12/03/2014 07:34 AM, Ricardo Azevedo wrote:
Hi,

We would like to tell you all we released an implementation of the “HTTP Origin-Bound Authentication (HOBA) draft-ietf-httpauth-hoba-05”.

Please find it on GitHub (https://github.com/razevedo/hoba-authentication) under a MIT license.

Your comments are welcomed.



Wow! Can't wait to take a look!

Mike
--------------070708080305020205050601-- From nobody Wed Dec 3 07:49:40 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30A91A1B95 for ; Wed, 3 Dec 2014 07:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHwX4dtIhGn4 for ; Wed, 3 Dec 2014 07:49:27 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 485D21A1BAC for ; Wed, 3 Dec 2014 07:49:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2432BBE04; Wed, 3 Dec 2014 15:49:20 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj_GKMe_imCb; Wed, 3 Dec 2014 15:49:17 +0000 (GMT) Received: from [10.128.160.222] (unknown [212.76.224.120]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2F66BBEF1; Wed, 3 Dec 2014 15:49:17 +0000 (GMT) Message-ID: <547F30FC.2090309@cs.tcd.ie> Date: Wed, 03 Dec 2014 15:49:16 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Thomas , http-auth@ietf.org References: <547F3086.9000104@mtcc.com> In-Reply-To: <547F3086.9000104@mtcc.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/qODhDwQ5-EDE-yjd90bu0J4qgBA Subject: Re: [http-auth] HOBA implementation X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 15:49:37 -0000 On 03/12/14 15:47, Michael Thomas wrote: > On 12/03/2014 07:34 AM, Ricardo Azevedo wrote: >> Hi, >> >> We would like to tell you allwe released an implementation of the >> “HTTP Origin-Bound Authentication (HOBA) draft-ietf-httpauth-hoba-05â€. >> >> Please find it on GitHub >> (https://github.com/razevedo/hoba-authentication) under a MIT license. >> >> Your comments are welcomed. >> > > Wow! Can't wait to take a look! Yeah, cool. S. > > Mike > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From nobody Wed Dec 3 08:15:38 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A641A1B9B for ; Wed, 3 Dec 2014 08:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h46RAHng4j_W for ; Wed, 3 Dec 2014 08:15:11 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658E91A1BF0 for ; Wed, 3 Dec 2014 08:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417623301; x=2281536901; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5ob4FAsi05Q3AqVaDAg8lJmaANV1u4RW+lEIaUqR9JQ=; b=EbI2h+TOnC/WA/LTRKTJPS3bsAg42ELl/D//hwb78Jw7oYOGGCYIlxX5XZ+1pDBG VgEKuTQkSoUjOA123IqzNbyWhMUqAcq9z1ZWwx5Xw3iKpgbC/9nkWdK8QdC1eTVu CXer6U+iDN4vrLJesFqYVBxWuQxgKcLpOOGUiPbbmTDkgbLotVYYLbkR9JV/WI/I 9AoAFNZ8Ovgm7CA7yt9CsBFAgwNe9Q37sUuxwFT2jqOfnK/Bd1EnnfsttpEUl3fg uQ/QdEOoAQEA1SVAQ753ig/I3ZwAkTs2kD2tMBb+FaEqx34tdwEulk9DFOi0XRel 9bTBnjsi9Yn5KESAI/PULQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 1A.5C.12968.5073F745; Wed, 3 Dec 2014 08:15:01 -0800 (PST) X-AuditID: 11973e12-f79306d0000032a8-5d-547f37055104 Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 25.DE.05439.B073F745; Wed, 3 Dec 2014 08:15:07 -0800 (PST) Received: from [17.153.21.172] by cardamom.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG0000T8L4YCN40@cardamom.apple.com> for http-auth@ietf.org; Wed, 03 Dec 2014 08:15:01 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-type: multipart/signed; boundary="Apple-Mail=_BFF5C39D-A4EE-4ABD-A435-7F087E4298F8"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> Date: Wed, 03 Dec 2014 11:14:58 -0500 Message-id: <61D95DD7-42F3-4483-8C72-E29C16180C56@apple.com> References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUi2FAYrMtqXh9iMGmKtsWH/XOYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcehaYMHTgIqL3a3MDYzTvLoYOTkkBEwkJq7dzwphi0lcuLee rYuRi0NIYC+jxPe23YwwRWv2vmKCSExkkpja/pMFwvnDKPGmYx8zSJWwQJLE+RkXwWxeAT2J piePwTqYBaYwSkx/tJIdJMEmoCbxe1If2D5OAVuJ5/t/g9ksAqoSKx7MAGtmFlCXWD7lBdQg G4lHr64xgdhCAiUSc9b9BjtJREBJ4vCVr8wQ58lK/Lt4hh1kmYTACjaJW28eM01gFJqF5JBZ yA6ZBbZEW2LZwtfMsxg5gGwdickLGSHCphJP3m5ng7CtJX7OeQQVV5SY0v2QfQEj+ypGodzE zBzdzDwTvcSCgpxUveT83E2MoJiYbie0g/HUKqtDjAIcjEo8vA+i60KEWBPLiitzDzFKc7Ao ifPuVwQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYFR+/uF1sM2LZ68Cv317fzybIVD6bNB9 S1aR977SxZ/OZjg2n7KWeRLq6+ptmn07N3zqOY/gd4wloRc+im1mzvBd+m/urSrD3IA9VUcL dXjfSlkvvN94c1NK2Z1tE/XEP6lG+r+Lbt30dfmT0loD27V1JtJxazTYD3zqMJK+8Dil+HIl 32y9YCWW4oxEQy3mouJEAJTmcAhqAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUi2FAcp8ttXh9isOe0rMWH/XOYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcehaYMHTgIqL3a3MDYzTvLoYOTkkBEwk1ux9xQRhi0lcuLee rYuRi0NIYCKTxNT2nywQzh9GiTcd+5hBqoQFkiTOz7gIZvMK6Ek0PXnMBFLELDCFUWL6o5Xs IAk2ATWJ35P6WEFsTgFbief7f4PZLAKqEisezABrZhZQl1g+5QXUIBuJR6+ugZ0hJFAiMWfd b0YQW0RASeLwla/MEOfJSvy7eIZ9AiP/LCS7ZyHbPQtsrrbEsoWvmWcxcgDZOhKTFzJChE0l nrzdzgZhW0v8nPMIKq4oMaX7IfsCRvZVjAJFqTmJlcZ6iQUFOal6yfm5mxjBIVwYvIPxzzKr Q4wCHIxKPLwPoutChFgTy4orcw8xqgCNeLRh9QVGKZa8/LxUJRHeZ9+A0rwpiZVVqUX58UWl OanFhxilOViUxHknqgClBNITS1KzU1MLUotgskwcnFINjKrMM9wWH3kyXYTdbdLTFedSZffc WuGrbPPu0E5bnYvhKkbph7z1hW5Z9q6pu6F3obJG/UWHw4lTYnyl1q3HUyPNX9re7eRT4/Zd /u7/fv/N3bVVfhpL5m1td5FfFz07IbBW4OU1+4sFWfxHEn67eCmbuR6+dTLA2PTz1l6+AK2N GoJyrXeqlViKMxINtZiLihMBwpOMumkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/fJaFTOlXqzFWODo-P_qFw01WZcI Cc: IETF HTTP Auth Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 16:15:26 -0000 --Apple-Mail=_BFF5C39D-A4EE-4ABD-A435-7F087E4298F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My comments: - Section 2 makes the "charset" parameter OPTIONAL. I'm wondering if = this should be RECOMMENDED in order to encourage adoption of UTF-8 = usernames and passwords since that solves common deployment and interop = issues. - Section 2.1 uses "can" (servers can use the "charset" authentication = parameter...) If "charset" is OPTIONAL in section 2, I think this should = be "MAY" (servers MAY use ...), and if RECOMMENDED this should be = "SHOULD" (servers SHOULD use ...), although then you'd want to clarify = that it is a SHOULD when using UTF-8... - Section 4 doesn't talk about using TLS/HTTPS, which is a common method = for providing some level of protection for the cleartext password in = transit. It might be sufficient to simply expand on "enhancements", = e.g.: Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used (without enhancements such as HTTPS = [RFC2818]) to protect sensitive or valuable information. with a corresponding informative reference to RFC 2818 in section 7.2. = That at least provides a pointer without endorsing Basic + HTTPS as a = "secure" combination... > On Dec 2, 2014, at 6:19 AM, Yoav Nir wrote: >=20 > Thank you, Julian >=20 > This begins a 2-week WGLC for this document. >=20 > Please take the time to read through and post any comments to the = list. >=20 > Cheers >=20 > Matt & Yoav >=20 >> On Dec 2, 2014, at 1:16 PM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Hypertext Transfer Protocol = Authentication Working Group of the IETF. >>=20 >> Title : The 'Basic' HTTP Authentication Scheme >> Author : Julian F. Reschke >> Filename : draft-ietf-httpauth-basicauth-update-03.txt >> Pages : 14 >> Date : 2014-12-02 >>=20 >> Abstract: >> This document defines the "Basic" Hypertext Transfer Protocol (HTTP) >> Authentication Scheme, which transmits credentials as = userid/password >> pairs, obfuscated by the use of Base64 encoding. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-03 >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-basicauth-update-03= >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_BFF5C39D-A4EE-4ABD-A435-7F087E4298F8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO0jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUiMIIECqADAgECAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzEyMTcw MDAwMDBaFw0xNDEyMTcyMzU5NTlaMCExHzAdBgkqhkiG9w0BCQEWEG1zd2VldEBhcHBsZS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDXb0GGUQlc3NMCGLyDp/9D7+81MLiL2wHz P1txcnpqmcd33SsV+FsTdseTQt4YQRxq1FoqyR+65eiLddmxkOtbhwCuY7CYpFeZPpjmI2WijSCs Y9LmCJNzCkJrJjPLd53XauZqdpscFf1OwBT089X4IXZKk2/zZB2OXgPCqpLGnqsHzIKGohlXglIa bVp16LHGvDwJG/ovbuaxKJOc4GPkD9CLliyRDXwOKnRDLB/jgMDBjr/XzQoHHWqRZ43kmGo+9Juq lIquOOvvGtq4VLBFCkGsjjII55tm4FLjce6Tr7PyYMyJWaE8/5ZZhNR1kRBs0o0Zy1sEPfH7KX3m VgPvAgMBAAGjggHgMIIB3DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4E FgQU7SgSaBvZMWYrE6iYOPsK9dpeLLYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYD VR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAE PzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8u bmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHow UgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9k b2NhLmNvbTAbBgNVHREEFDASgRBtc3dlZXRAYXBwbGUuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAY OSi0CubvYBiO+bvr2B/4urjAypaUyCzv6/xaTdom6qcAAdpZ/aCrzyANf696PgwQvO06p5SQIj1u AAxR6UZqpaa29E7vaffJz/8JebQWYxD/HWOIh9Ewdwdq/SR8EcMCUNtAqiabgp/XZry9tebGUqry X5blZSHAEAi8ad2SjCAtqTSorbMHY4x3bmiro9kzHsa8zLa0RkbRRfaXDHJ7KhNkLSVKlz1e/zOF k9skVJiOE4T7fTvX5jx9pLudoXW+reKl78HUEpAx7caNyf1XP4w0dv33nnQ4UJhtFfY+rR7Lhum1 VYXBolp0pkqD34NdxZUMJcWU8hbYjGdoyC8qMYIDrjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMAkGBSsOAwIaBQCgggHZMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTIwMzE2MTQ1OFowIwYJ KoZIhvcNAQkEMRYEFNiGoS8K6r1G0HjKUeaMkBpogqXvMIG6BgkrBgEEAYI3EAQxgawwgakwgZMx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMIG8Bgsq hkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNV BAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUH t1fFyUsR52q4+8ZfwIYwDQYJKoZIhvcNAQEBBQAEggEAuS3pbeYP0VwaaXdqy7IJX7kXgmolLdMs JznGH9ymcX2NMFMFm2BbwgvGo0KpJ6AUej5nL9aiV09VMAsHwWri/w0mMM4iNSqtDqUylTCzl1Dg 0hUQAqFbPdLBMHUqQ71dW6ZNd7JxJgXNFD/rXzRSApBUEdyaHkQmia9+JKKpLGvLor2tFwDGMK75 axBZxxhKCOGDed6h2f1B6i65yAqmfDLVU/0IUWHyDWG91ggSPiXP8mmSAVm90o1xzDxSiX3gx1Rk uFZb93jOsIgPGuDz65aJRDPNoen/2SmtFlQZC2o5OM4dDntNUbZJJgLqWa1PleY0+l7Ra0pM1V4q aW15cAAAAAAAAA== --Apple-Mail=_BFF5C39D-A4EE-4ABD-A435-7F087E4298F8-- From nobody Wed Dec 3 08:27:32 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E491A700A for ; Wed, 3 Dec 2014 08:27:13 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAank2XkxVZq for ; Wed, 3 Dec 2014 08:27:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7901A876F for ; Wed, 3 Dec 2014 08:25:06 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MbOoG-1XdZvC0ECa-00Ij6e; Wed, 03 Dec 2014 17:24:58 +0100 Message-ID: <547F3958.4020005@gmx.de> Date: Wed, 03 Dec 2014 17:24:56 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Michael Sweet , Yoav Nir References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> <61D95DD7-42F3-4483-8C72-E29C16180C56@apple.com> In-Reply-To: <61D95DD7-42F3-4483-8C72-E29C16180C56@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:5rJzzUM8ZE7yLMGPssqFAxZNCfpHbUZp4J8L9KEXjjtSo+G9io6 4PisaeBylXIJSMhjSh/ILEHj46ErxC3iolaVOJFhxv8UO2aN+fDIfByPOQ3+EgsnF8oc+y/ 4ui8RPlCA6zmr/wiBtYWeHHlisVQH+HM3Kk6Y8+reMtllZ0KNolyBNTnnwbpr1b6yNWEPdk 5Jn4OWbr8Og+Kol/Rb8yw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/QD18MI2dxG87UGEpDCCVcbro_zo Cc: IETF HTTP Auth Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 16:27:13 -0000 On 2014-12-03 17:14, Michael Sweet wrote: > My comments: > > - Section 2 makes the "charset" parameter OPTIONAL. I'm wondering if this should be RECOMMENDED in order to encourage adoption of UTF-8 usernames and passwords since that solves common deployment and interop issues. This being an optional feature has been the intention since we started. If a server has a use for non-ASCII characters, it has sufficient motivation to use it. In the other case, no amount of spec language will affect what it does. > - Section 2.1 uses "can" (servers can use the "charset" authentication parameter...) If "charset" is OPTIONAL in section 2, I think this should be "MAY" (servers MAY use ...), and if RECOMMENDED this should be "SHOULD" (servers SHOULD use ...), although then you'd want to clarify that it is a SHOULD when using UTF-8... How is "MAY" better than "can"? This is a statement of fact, not an interoperability requirement. > - Section 4 doesn't talk about using TLS/HTTPS, which is a common method for providing some level of protection for the cleartext password in transit. It might be sufficient to simply expand on "enhancements", e.g.: > > Because Basic authentication involves the cleartext transmission of > passwords it SHOULD NOT be used (without enhancements such as HTTPS [RFC2818]) > to protect sensitive or valuable information. > > with a corresponding informative reference to RFC 2818 in section 7.2. That at least provides a pointer without endorsing Basic + HTTPS as a "secure" combination... > That sounds like a good addition. Best regards, Julian From nobody Wed Dec 3 09:12:58 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F20D1A700A for ; Wed, 3 Dec 2014 09:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyiBFxyiI8-2 for ; Wed, 3 Dec 2014 09:12:51 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189FE1A6F87 for ; Wed, 3 Dec 2014 09:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417626766; x=2281540366; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kVu6NzH4YYjqHJIiexbIt9j9RB0AIlMoLD0Ts+noa80=; b=AhvUpBtKmVMkNH0ifhKPO7De9BvvjcSElH79dgPMICxP7XPltC/pvB9us5kpzx44 keij5Hr6sQjVJQaWTiGu8pzCW/V1pZFqur1Whu+P6byT4rbIufzdblECb429gvLX YLNE6RkAn+ct4gXSmT7m1hFTyijjfHdoCtb+FrPR5CV0uUHUSCASkpyBeETb+cC+ kcdAtP+2UKgSOpIsnd/5yfz6te1GUfq7sDuwniRVVfVPjQjSPEsbFtzLsBsnOST6 1RuroxEyvyLO6ctX7G9PRP0gu5lkFSgunzDuATR20yq2MYPndvn78d0dVoZqDom/ nPbPqj5nJPGajdB1Fm9QIQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 7D.CA.18976.E844F745; Wed, 3 Dec 2014 09:12:46 -0800 (PST) X-AuditID: 11973e11-f79a66d000004a20-cc-547f448e12e3 Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 0E.7D.05775.A744F745; Wed, 3 Dec 2014 09:12:26 -0800 (PST) Received: from [17.153.21.172] by cardamom.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG00003WNSXCN70@cardamom.apple.com> for http-auth@ietf.org; Wed, 03 Dec 2014 09:12:46 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-type: multipart/signed; boundary="Apple-Mail=_F26AEC32-E6CB-4E2C-BD0A-0FADE3BD74EB"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <547F3958.4020005@gmx.de> Date: Wed, 03 Dec 2014 12:12:31 -0500 Message-id: <1EB23215-FEFE-48D1-B634-04E6485A899F@apple.com> References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> <61D95DD7-42F3-4483-8C72-E29C16180C56@apple.com> <547F3958.4020005@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUi2FAYpdvnUh9isPubpsWH/XOYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsev3MpaCL6EVp5ueMDUw9vh1MXJwSAiYSDzpCO5i5AQyxSQu 3FvP1sXIxSEksJdR4umKFnaIhInEiQPTmCESE5kkHnW8YoVw/jBKvPl6mRmkSlggSeL8jItg Nq+AnkTTk8dMIEXMAlMYJd6eXgyWYBNQk/g9qY8VxOYEsS9+ArNZBFQlLi+5zghiMwu4Syxt uMgCMchG4udXiEFCAgcZJeZvnQyWEBHQkrh9by8jxH2yEv8unmEHKZIQWMIm8XfdA7YJjEKz kFwyC9kls8C2aEssW/gayjaQeNr5ihXCNpV48nY7G4RtLfFzziNGCFtRYkr3Q/YFjOyrGIVy EzNzdDPzjPQSCwpyUvWS83M3MYLiYrqd4A7G46usDjEKcDAq8fA+iK4LEWJNLCuuzD3EKM3B oiTOu18RKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxWfNUaf0p/d+Rq7qX9u3tLeoNmWx0 P+DqkarausCDPbvthb4bTOqa53v5aq5crel97XUnzDY6zv80p7DG9n6JM1vA4y+X9n/lCd8w TeYIw9PV9qr2K1hTpm6tC8ica52SUaQSsFVAUH53wFOnY609niyzJiw8oK/wgPHhthsNBpv1 X2jE6e5TYinOSDTUYi4qTgQAvXeOvGwCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUi2FAcp1vlUh9i8OYBh8WH/XOYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsev3MpaCL6EVp5ueMDUw9vh1MXJySAiYSJw4MI0ZwhaTuHBv PVsXIxeHkMBEJolHHa9YIZw/jBJvvl4GqxIWSJI4P+MimM0roCfR9OQxE0gRs8AURom3pxeD JdgE1CR+T+pjBbE5QeyLn8BsFgFVictLrjOC2MwC7hJLGy6yQAyykfj5FWKQkMBBRon5WyeD JUQEtCRu39vLCHGfrMS/i2fYJzDyz0KyfBay5bPABmtLLFv4Gso2kHja+YoVwjaVePJ2OxuE bS3xc84jRghbUWJK90P2BYzsqxgFilJzEivN9BILCnJS9ZLzczcxggO5MGoHY8Nyq0OMAhyM Sjy8D6LrQoRYE8uKK3MPMaoAjXi0YfUFRimWvPy8VCURXnHH+hAh3pTEyqrUovz4otKc1OJD jNIcLErivGUqQJ0C6YklqdmpqQWpRTBZJg5OqQZGxl8G960q3p/jd8nRPbWw54/sy7b331TW TWO9/dmKxYzzWdojd3Zd4VU9H31T7jfPrLnk9OWzoBDX++tKM24X7Jsya06suoefjsID/Tc/ Oip/GymmPmq2/FzQGaz8dKn9lp38Z9ecPRbDam38fLP3gke6e2tXPiv8dc7upFaGbljnfAur yK8qSizFGYmGWsxFxYkAHZwd92wCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/wuVA7SguF0mcB-YqRbJRGe6ijqQ Cc: IETF HTTP Auth Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 17:12:55 -0000 --Apple-Mail=_F26AEC32-E6CB-4E2C-BD0A-0FADE3BD74EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Julian, > On Dec 3, 2014, at 11:24 AM, Julian Reschke = wrote: >=20 > On 2014-12-03 17:14, Michael Sweet wrote: >> My comments: >>=20 >> - Section 2 makes the "charset" parameter OPTIONAL. I'm wondering if = this should be RECOMMENDED in order to encourage adoption of UTF-8 = usernames and passwords since that solves common deployment and interop = issues. >=20 > This being an optional feature has been the intention since we = started. >=20 > If a server has a use for non-ASCII characters, it has sufficient = motivation to use it. In the other case, no amount of spec language will = affect what it does. OK, I was under the impression that one of the motivations for updating = RFC 2617 was to address I18N issues. >> - Section 2.1 uses "can" (servers can use the "charset" = authentication parameter...) If "charset" is OPTIONAL in section 2, I = think this should be "MAY" (servers MAY use ...), and if RECOMMENDED = this should be "SHOULD" (servers SHOULD use ...), although then you'd = want to clarify that it is a SHOULD when using UTF-8... >=20 > How is "MAY" better than "can"? This is a statement of fact, not an = interoperability requirement. Typically MAY is used in conjunction with OPTIONAL; from RFC 2119: 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) Since the purpose is to indicate that servers will include the "charset" = parameter to tell the client about the expected character encoding, = something that is present specifically for interoperability with Unicode = user IDs and passwords, I think that "MAY" is the right word to use here = instead of its non-conformance synonym "can". Alternately just drop "can" with no replacement, e.g.: In challenges, servers use the "charset" authentication parameter to indicate the character encoding scheme they expect the user agent to use when generating "user-pass" (a sequence of octets). This information is purely advisory. That avoids the whole consistency issues and makes it clear that the = "charset" parameter is the one and only way of specifying the character = encoding of the userid and password. (I realize I'm being anal about this, but having spent the better part = of 20 years writing/editing/reviewing technical documents and standards, = I have seen a number of truly shocking misinterpretations of otherwise = clear text... "Weasel words" like "can" are often problematic...) >> - Section 4 doesn't talk about using TLS/HTTPS, which is a common = method for providing some level of protection for the cleartext password = in transit. It might be sufficient to simply expand on "enhancements", = e.g.: >>=20 >> Because Basic authentication involves the cleartext transmission = of >> passwords it SHOULD NOT be used (without enhancements such as = HTTPS [RFC2818]) >> to protect sensitive or valuable information. >>=20 >> with a corresponding informative reference to RFC 2818 in section = 7.2. That at least provides a pointer without endorsing Basic + HTTPS = as a "secure" combination... >>=20 >=20 > That sounds like a good addition. >=20 > Best regards, Julian _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_F26AEC32-E6CB-4E2C-BD0A-0FADE3BD74EB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO0jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUiMIIECqADAgECAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzEyMTcw MDAwMDBaFw0xNDEyMTcyMzU5NTlaMCExHzAdBgkqhkiG9w0BCQEWEG1zd2VldEBhcHBsZS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDXb0GGUQlc3NMCGLyDp/9D7+81MLiL2wHz P1txcnpqmcd33SsV+FsTdseTQt4YQRxq1FoqyR+65eiLddmxkOtbhwCuY7CYpFeZPpjmI2WijSCs Y9LmCJNzCkJrJjPLd53XauZqdpscFf1OwBT089X4IXZKk2/zZB2OXgPCqpLGnqsHzIKGohlXglIa bVp16LHGvDwJG/ovbuaxKJOc4GPkD9CLliyRDXwOKnRDLB/jgMDBjr/XzQoHHWqRZ43kmGo+9Juq lIquOOvvGtq4VLBFCkGsjjII55tm4FLjce6Tr7PyYMyJWaE8/5ZZhNR1kRBs0o0Zy1sEPfH7KX3m VgPvAgMBAAGjggHgMIIB3DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4E FgQU7SgSaBvZMWYrE6iYOPsK9dpeLLYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYD VR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAE PzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8u bmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHow UgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9k b2NhLmNvbTAbBgNVHREEFDASgRBtc3dlZXRAYXBwbGUuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAY OSi0CubvYBiO+bvr2B/4urjAypaUyCzv6/xaTdom6qcAAdpZ/aCrzyANf696PgwQvO06p5SQIj1u AAxR6UZqpaa29E7vaffJz/8JebQWYxD/HWOIh9Ewdwdq/SR8EcMCUNtAqiabgp/XZry9tebGUqry X5blZSHAEAi8ad2SjCAtqTSorbMHY4x3bmiro9kzHsa8zLa0RkbRRfaXDHJ7KhNkLSVKlz1e/zOF k9skVJiOE4T7fTvX5jx9pLudoXW+reKl78HUEpAx7caNyf1XP4w0dv33nnQ4UJhtFfY+rR7Lhum1 VYXBolp0pkqD34NdxZUMJcWU8hbYjGdoyC8qMYIDrjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMAkGBSsOAwIaBQCgggHZMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTIwMzE3MTIzMlowIwYJ KoZIhvcNAQkEMRYEFJ8xy2eP7pfQwZRPRk7HX1IciHFAMIG6BgkrBgEEAYI3EAQxgawwgakwgZMx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMIG8Bgsq hkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNV BAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUH t1fFyUsR52q4+8ZfwIYwDQYJKoZIhvcNAQEBBQAEggEAFo+nanakRjhFMHwgw9bI7IEKnxn8rH1+ uPcxSgGasRra7kybuEwcuOwBc5u3xo7q0mI7MEG7ZrVp0+zT+877TaGDNZGDbsju31AOBN13dZcx KmkbQHh8cenM7USr2b85CfhztOkUnMmJ6ESwL69gMJbmdIEQ0WyNrpt98nZQk7tR7VCyE8lXrDO9 TpEA4AoVGZ2PVHYRWWE1iPAmJtWf60Kar8p/52Rd/Shrl2O4sWCy4GyqlwYkY3I2RTfNST6GwsfT pQL4MvBqzE/kLlzLYq8rN/3k+7Vz90uNRsr4y8PzZ331S0VkJyRah0vNEKg4FNDDPKb5b6WFrad9 o+bbXQAAAAAAAA== --Apple-Mail=_F26AEC32-E6CB-4E2C-BD0A-0FADE3BD74EB-- From nobody Wed Dec 3 09:21:44 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ADD1A1BD9 for ; Wed, 3 Dec 2014 09:21:40 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGL3cYAYM5Oc for ; Wed, 3 Dec 2014 09:21:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9091A1B32 for ; Wed, 3 Dec 2014 09:21:22 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LfjlS-1YFf8Q3TQI-00pMFd; Wed, 03 Dec 2014 18:21:16 +0100 Message-ID: <547F468A.2000209@gmx.de> Date: Wed, 03 Dec 2014 18:21:14 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Michael Sweet References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> <61D95DD7-42F3-4483-8C72-E29C16180C56@apple.com> <547F3958.4020005@gmx.de> <1EB23215-FEFE-48D1-B634-04E6485A899F@apple.com> In-Reply-To: <1EB23215-FEFE-48D1-B634-04E6485A899F@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DmbQDWMf6eYvy7z8awMNGu73+HuXYEyXxUHU8dDHebN/y1S1vQ4 tVTbQ2vlLcO8v3Ldefzg//YJDjXbH0i2Bin2XRdb6NrgI9g0eeL1fHEYNhRsswfrvw1HxGl jMStqBII7wC/Q8KuKP6u8Wd9R26U4fvVq+Lk64ZzEl7ge1gGQFytD2Y29Vra6VY/apLSIWu S02qkD6ULZh+K8Uf6VXQQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/CWik2HrcAOVaTeRE8xTrd681eI0 Cc: IETF HTTP Auth Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 17:21:40 -0000 On 2014-12-03 18:12, Michael Sweet wrote: > Julian, > >> On Dec 3, 2014, at 11:24 AM, Julian Reschke wrote: >> >> On 2014-12-03 17:14, Michael Sweet wrote: >>> My comments: >>> >>> - Section 2 makes the "charset" parameter OPTIONAL. I'm wondering if this should be RECOMMENDED in order to encourage adoption of UTF-8 usernames and passwords since that solves common deployment and interop issues. >> >> This being an optional feature has been the intention since we started. >> >> If a server has a use for non-ASCII characters, it has sufficient motivation to use it. In the other case, no amount of spec language will affect what it does. > > OK, I was under the impression that one of the motivations for updating RFC 2617 was to address I18N issues. It is. But we can't make new normative requirements that will break existing implementations. >>> - Section 2.1 uses "can" (servers can use the "charset" authentication parameter...) If "charset" is OPTIONAL in section 2, I think this should be "MAY" (servers MAY use ...), and if RECOMMENDED this should be "SHOULD" (servers SHOULD use ...), although then you'd want to clarify that it is a SHOULD when using UTF-8... >> >> How is "MAY" better than "can"? This is a statement of fact, not an interoperability requirement. > > Typically MAY is used in conjunction with OPTIONAL; from RFC 2119: > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > > Since the purpose is to indicate that servers will include the "charset" parameter to tell the client about the expected character encoding, something that is present specifically for interoperability with Unicode user IDs and passwords, I think that "MAY" is the right word to use here instead of its non-conformance synonym "can". I disagree. > Alternately just drop "can" with no replacement, e.g.: > > In challenges, servers use the "charset" authentication parameter > to indicate the character encoding scheme they expect the user agent > to use when generating "user-pass" (a sequence of octets). This > information is purely advisory. > > That avoids the whole consistency issues and makes it clear that the "charset" parameter is the one and only way of specifying the character encoding of the userid and password. But that makes it sound as if servers have to use the parameter, which is not true. > ... Best regards, Julian From nobody Wed Dec 3 11:05:26 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886F21A1AA0 for ; Wed, 3 Dec 2014 11:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hfasRqCvjDX for ; Wed, 3 Dec 2014 11:05:22 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05D91A90AE for ; Wed, 3 Dec 2014 11:05:21 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so6030206wid.11 for ; Wed, 03 Dec 2014 11:05:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5XVMD8bLWK1E2MEVl4YQtTGSalciRZq3JmY/LZaB0Ng=; b=FY5iyOVcWvA1DfHSVh0rbd8BlG8EcYYc8vbJhODDctFmUjYIjshsuHr0AQVf+/bfbe o82SPO7u7iw/PZSExlzZ93gPUq8eyybVaZ3RVzSGNa7+fiTAZuN3l5bbl6HDuFJnTB+Q 8Ly2QYdJzkiYfPP+cplR16YzowuLXlbGTocjzxthLq6C8Zw7FFIBkFPyQPxdomkn31Zk 2bowkb18mtsw7JGYFHDJ2wT8NZM2V/TIFZEcHQ7ogpAoMNLCrrq27jLTDlT3IbSpfYkn tsCrOLKhTpPACY257zJPnE1ths2F7VnuQXrDkDX4YMA+SIegNX588Y6PDuJYP/k56Pad GTXw== X-Received: by 10.194.161.202 with SMTP id xu10mr10030665wjb.4.1417633520708; Wed, 03 Dec 2014 11:05:20 -0800 (PST) Received: from [192.168.1.104] (IGLD-84-229-24-231.inter.net.il. [84.229.24.231]) by mx.google.com with ESMTPSA id r10sm38275624wiy.19.2014.12.03.11.05.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 11:05:20 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <547F468A.2000209@gmx.de> Date: Wed, 3 Dec 2014 21:05:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <85038266-014D-4528-A7AF-2201AB146835@gmail.com> References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> <61D95DD7-42F3-4483-8C72-E29C16180C56@apple.com> <547F3958.4020005@gmx.de> <1EB23215-FEFE-48D1-B634-04E6485A899F@apple.com> <547F468A.2000209@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/TMoRBc7Tr6JmKHpmB_aQUQz4Z8Y Cc: IETF HTTP Auth Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 19:05:25 -0000 > On Dec 3, 2014, at 7:21 PM, Julian Reschke = wrote: >=20 > On 2014-12-03 18:12, Michael Sweet wrote: >> Julian, >>=20 >>> On Dec 3, 2014, at 11:24 AM, Julian Reschke = wrote: >>>=20 >>> On 2014-12-03 17:14, Michael Sweet wrote: >>>> My comments: >>>>=20 >>>> - Section 2 makes the "charset" parameter OPTIONAL. I'm wondering = if this should be RECOMMENDED in order to encourage adoption of UTF-8 = usernames and passwords since that solves common deployment and interop = issues. >>>=20 >>> This being an optional feature has been the intention since we = started. >>>=20 >>> If a server has a use for non-ASCII characters, it has sufficient = motivation to use it. In the other case, no amount of spec language will = affect what it does. >>=20 >> OK, I was under the impression that one of the motivations for = updating RFC 2617 was to address I18N issues. >=20 > It is. But we can't make new normative requirements that will break = existing implementations. [no hats] Sure we can. This is a new specification. Some implementations will keep = implementing the old, obsolete spec. This is no different from clients = and servers continuing to use TLS 1.0 and 1.1 now that 1.2 has obsoleted = them. The charset parameter can be an indicator that the server is = implementing the new spec rather than the old. Why not go all the way to = MUST? Yoav= From nobody Wed Dec 3 11:17:24 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A450D1A1BB7 for ; Wed, 3 Dec 2014 11:17:20 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AcuxwvOa6rv for ; Wed, 3 Dec 2014 11:17:19 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064501A1BF5 for ; Wed, 3 Dec 2014 11:17:19 -0800 (PST) Received: from [192.168.2.160] ([93.217.101.31]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LyEJp-1XzKKG0uGr-015WwR; Wed, 03 Dec 2014 20:17:09 +0100 Message-ID: <547F61B3.5020206@gmx.de> Date: Wed, 03 Dec 2014 20:17:07 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Yoav Nir References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> <61D95DD7-42F3-4483-8C72-E29C16180C56@apple.com> <547F3958.4020005@gmx.de> <1EB23215-FEFE-48D1-B634-04E6485A899F@apple.com> <547F468A.2000209@gmx.de> <85038266-014D-4528-A7AF-2201AB146835@gmail.com> In-Reply-To: <85038266-014D-4528-A7AF-2201AB146835@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:AFQRiLE2Sbe16fnl5WC717WiDtAcCcH4VUcYBpX0kCN13ZpFv+M 1gDCQ1qIlWapHbjwRDEuteitnJDDiGN+gnFcuxsMquM1c/reYvZMrenN2UEuPzkHEDucsh5 Aa71rCq1qwIufAfIqvjm/FccI1xRM/RAjuH11u18duYjQJrFK/wcpeC8QaET8wXwyiMd+bU cTi+kR3gBuwBEpQzUcNFw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/unaq3dDoqxZ0nNvoUmqy-flrskg Cc: IETF HTTP Auth Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 19:17:20 -0000 On 2014-12-03 20:05, Yoav Nir wrote: > [no hats] > > Sure we can. This is a new specification. Some implementations will keep implementing the old, obsolete spec. This is no different from clients and servers continuing to use TLS 1.0 and 1.1 now that 1.2 has obsoleted them. It's certainly very different from the way httpbis has revised RFC 2616, and my assumption was that we're doing the same thing here. > The charset parameter can be an indicator that the server is implementing the new spec rather than the old. Why not go all the way to MUST? Because it doesn't make any sense and will not be implemented? Can we please stick to a realistic plan instead of coming up with something people will ignore? Do you remember RFC 2965? Best regards, Julian From nobody Wed Dec 3 11:43:21 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599881A8A59 for ; Wed, 3 Dec 2014 11:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6IFQOJCSTCW for ; Wed, 3 Dec 2014 11:43:17 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E171A90D8 for ; Wed, 3 Dec 2014 11:43:15 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so20601287wgh.23 for ; Wed, 03 Dec 2014 11:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E4E4FkW9X1TWZtPAfpYNUO4pyoGGCbOFnaGy3k9z/8g=; b=NYyeEV21ipQCY2oqRephw+MBdpbh8Tb4txa0Lw9gYoBAZXoInCGa+lbs2evieNzod1 NbKDSfWEIBcL0IVzgiq5fiIAhhwoLuufzPQChhrC6QeVBJROn/TmU7YZdCFXyp96Ja04 nAkcXRlVrJP/weEAIOv7fE455tKaC2my6k9YfoXmrjm6E4pzzcOy0EpkeiO5R8GzRqCq pmtXmqcRZ+9yQkIyuOiz+XVNo9GHlIyiTknVtmci/7buxOZ6H15RaLs2UIntp0Y9fzmW od448QVyGJY8eOiWiaZqjuI69qb4afVylFLjB1NA4XPk/UQP5DMGYPGDUrLfUOf6Gfbd QYXQ== X-Received: by 10.180.73.108 with SMTP id k12mr6691533wiv.24.1417635794121; Wed, 03 Dec 2014 11:43:14 -0800 (PST) Received: from [192.168.1.104] (IGLD-84-229-24-231.inter.net.il. [84.229.24.231]) by mx.google.com with ESMTPSA id j9sm5511184wjb.38.2014.12.03.11.43.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 11:43:13 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <547F61B3.5020206@gmx.de> Date: Wed, 3 Dec 2014 21:43:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0506394F-FF36-4A8B-BD32-7F75718A3F35@gmail.com> References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> <61D95DD7-42F3-4483-8C72-E29C16180C56@apple.com> <547F3958.4020005@gmx.de> <1EB23215-FEFE-48D1-B634-04E6485A899F@apple.com> <547F468A.2000209@gmx.de> <85038266-014D-4528-A7AF-2201AB146835@gmail.com> <547F61B3.5020206@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/A-H2khUOq71McYADqXUYTksOZ7U Cc: IETF HTTP Auth Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 19:43:18 -0000 > On Dec 3, 2014, at 9:17 PM, Julian Reschke = wrote: >=20 > On 2014-12-03 20:05, Yoav Nir wrote: >> [no hats] >>=20 >> Sure we can. This is a new specification. Some implementations will = keep implementing the old, obsolete spec. This is no different from = clients and servers continuing to use TLS 1.0 and 1.1 now that 1.2 has = obsoleted them. >=20 > It's certainly very different from the way httpbis has revised RFC = 2616, and my assumption was that we're doing the same thing here. So for those servers that don=92t send the charset parameter, what is = changed from RFC 2616?= From nobody Wed Dec 3 12:40:59 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057421A1E0E for ; Wed, 3 Dec 2014 12:40:57 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5xzWT8J-1D9 for ; Wed, 3 Dec 2014 12:40:55 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7361A86EE for ; Wed, 3 Dec 2014 12:40:55 -0800 (PST) Received: from [192.168.2.160] ([93.217.101.31]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LzskF-1XzrWX3yXT-014ygB; Wed, 03 Dec 2014 21:40:47 +0100 Message-ID: <547F754D.4070303@gmx.de> Date: Wed, 03 Dec 2014 21:40:45 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Yoav Nir References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> <61D95DD7-42F3-4483-8C72-E29C16180C56@apple.com> <547F3958.4020005@gmx.de> <1EB23215-FEFE-48D1-B634-04E6485A899F@apple.com> <547F468A.2000209@gmx.de> <85038266-014D-4528-A7AF-2201AB146835@gmail.com> <547F61B3.5020206@gmx.de> <0506394F-FF36-4A8B-BD32-7F75718A3F35@gmail.com> In-Reply-To: <0506394F-FF36-4A8B-BD32-7F75718A3F35@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:iwuAS2toTKUzglIqRMVHtB7EqXZ94DyPcF5ubo0XTwFF8RuHB9Y 7cjPJ5HxWbtvP1yIScA0nUR0FhdrrNmsakB4RehokGEK7EDtX6vTdjAFx1/j5n2D0m5aIIz Yk9YvgBBgJZQLL1V6aSnJElsZQYDBChLVDxHrhoZ0FeZ5EDdTLhKSI4HmWIVdon5xggtRrA /sQEuwPkVo6IFinAHA9TQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/3fooQnyioYr42YQFwX97vPG-RRQ Cc: IETF HTTP Auth Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 20:40:57 -0000 On 2014-12-03 20:43, Yoav Nir wrote: > >> On Dec 3, 2014, at 9:17 PM, Julian Reschke wrote: >> >> On 2014-12-03 20:05, Yoav Nir wrote: >>> [no hats] >>> >>> Sure we can. This is a new specification. Some implementations will keep implementing the old, obsolete spec. This is no different from clients and servers continuing to use TLS 1.0 and 1.1 now that 1.2 has obsoleted them. >> >> It's certainly very different from the way httpbis has revised RFC 2616, and my assumption was that we're doing the same thing here. > > So for those servers that don’t send the charset parameter, what is changed from RFC 2616? Nothing. But I heard you say to require to send the charset parameter. Best regards, Julian From khurtta@welho.com Tue Dec 2 11:20:47 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B491A6F3A for ; Tue, 2 Dec 2014 11:20:47 -0800 (PST) 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=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEt4pM8O114U for ; Tue, 2 Dec 2014 11:20:39 -0800 (PST) Received: from filtteri6.pp.htv.fi (filtteri6.pp.htv.fi [213.243.153.189]) by ietfa.amsl.com (Postfix) with ESMTP id C46F81A6FDD for ; Tue, 2 Dec 2014 11:20:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri6.pp.htv.fi (Postfix) with ESMTP id D4C7C56F734; Tue, 2 Dec 2014 21:20:16 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri6.pp.htv.fi [213.243.153.189]) (amavisd-new, port 10024) with ESMTP id oH6ptakaPT5I; Tue, 2 Dec 2014 21:20:12 +0200 (EET) Received: from hurtta09lk.keh.iki.fi (cs78144032.pp.htv.fi [62.78.144.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPS id D98CC5BC018; Tue, 2 Dec 2014 21:20:12 +0200 (EET) To: HTTPAuth working group mailing list Date: Tue, 2 Dec 2014 21:20:17 +0200 (EET) Sender: hurtta@hurtta09lk.keh.iki.fi From: Kari Hurtta X-Mailer: ELM [version ME+ 2.5 PLalpha36+] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141202192012.D98CC5BC018@smtp4.welho.com> Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/lEl0377idSnxC9TUR6D97OoYHEk X-Mailman-Approved-At: Thu, 04 Dec 2014 08:07:11 -0800 Cc: Kari Hurtta Subject: [http-auth] draft-ietf-httpauth-basicauth-update-03, 2. The 'Basic' Authentication Scheme X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 17:06:09 -0000 The 'Basic' HTTP Authentication Scheme draft-ietf-httpauth-basicauth-update-03 2. The 'Basic' Authentication Scheme http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-03#section-2 | For credentials, the "token-68" syntax defined in Section 2.2 of | [RFC7235] is used. The value is computed based on user-id and | password as defined below. "token68" seems to have defined in Section 2.1. of RFC7235 ( not in 2.2 ) Here: 2.1. Challenge and Response http://tools.ietf.org/html/rfc7235#section-2.1 | token68 = 1*( ALPHA / DIGIT / | "-" / "." / "_" / "~" / "+" / "/" ) *"=" / Kari Hurtta From nobody Thu Dec 4 09:33:16 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC831A1B89 for ; Thu, 4 Dec 2014 09:33:13 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpAplj_tvYZE for ; Thu, 4 Dec 2014 09:33:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7871A0393 for ; Thu, 4 Dec 2014 09:33:10 -0800 (PST) Received: from [192.168.2.160] ([93.217.65.247]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Luajs-1XnkXL2dM0-00zqRA; Thu, 04 Dec 2014 18:33:07 +0100 Message-ID: <54809ACC.50208@gmx.de> Date: Thu, 04 Dec 2014 18:33:00 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kari Hurtta , HTTPAuth working group mailing list References: <20141202192012.D98CC5BC018@smtp4.welho.com> In-Reply-To: <20141202192012.D98CC5BC018@smtp4.welho.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:2DwDs6nsmZe+M/4XvXis9B7fKd9NrtXYhY34PJNMWy1N4i5JnrH +3nDVI0r63ndywpJxVG93tQjeujQhSd32iJ7qp9FVGNtauEWybwEGFXcE6wdaPOwGkwevm5 K+dXdFvI8pFj/LvZmEelaZ9+eREC0GfogzoVYeoFX/XeqBlarZ2UmYvljYWYCaZEnBPCZWt d3aD93qgiYRsUbN2OfBPQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/4mmLD4pyj5bkPfrc85ZwFbuAJg0 Subject: Re: [http-auth] draft-ietf-httpauth-basicauth-update-03, 2. The 'Basic' Authentication Scheme X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 17:33:14 -0000 On 2014-12-02 20:20, Kari Hurtta wrote: > > The 'Basic' HTTP Authentication Scheme > draft-ietf-httpauth-basicauth-update-03 > > 2. The 'Basic' Authentication Scheme > http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-03#section-2 > > > | For credentials, the "token-68" syntax defined in Section 2.2 of > | [RFC7235] is used. The value is computed based on user-id and > | password as defined below. > > > "token68" seems to have defined in Section 2.1. of RFC7235 > > ( not in 2.2 ) > > Here: > > 2.1. Challenge and Response > http://tools.ietf.org/html/rfc7235#section-2.1 > > | token68 = 1*( ALPHA / DIGIT / > | "-" / "." / "_" / "~" / "+" / "/" ) *"=" > > / Kari Hurtta Good catch! -> Best regards, Julian From nobody Fri Dec 5 08:25:31 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFDB1ACF1D; Fri, 5 Dec 2014 08:25:30 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJKYQ-gFDgKD; Fri, 5 Dec 2014 08:25:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 483651ACEC5; Fri, 5 Dec 2014 08:25:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205162529.27026.12350.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 08:25:29 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/2es7d8XiwCoaX0_K9zCjTIFz3VY Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-hoba-06.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 16:25:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : HTTP Origin-Bound Authentication (HOBA) Authors : Stephen Farrell Paul Hoffman Michael Thomas Filename : draft-ietf-httpauth-hoba-06.txt Pages : 24 Date : 2014-12-05 Abstract: HTTP Origin-Bound Authentication (HOBA) is a digital signature based design for an HTTP authentication method. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-hoba-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 5 08:27:12 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375471ACF1B for ; Fri, 5 Dec 2014 08:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C864-_tIDlbw for ; Fri, 5 Dec 2014 08:27:05 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 315E91ACEBF for ; Fri, 5 Dec 2014 08:26:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1C64ABF06; Fri, 5 Dec 2014 16:26:50 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFrtDk3UEcCJ; Fri, 5 Dec 2014 16:26:49 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D641EBDFB; Fri, 5 Dec 2014 16:26:49 +0000 (GMT) Message-ID: <5481DCCA.3080308@cs.tcd.ie> Date: Fri, 05 Dec 2014 16:26:50 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <547D0D59.5070104@cs.tcd.ie> <78620582-D88B-4B58-9E98-15941A96809C@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/2z2Ys2bb-DFT8KHYdi519y6tPzk Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Review of draft-ietf-httpauth-hoba-05 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 16:27:11 -0000 Sorry for being slow, travel and all that... On 02/12/14 16:28, Kathleen Moriarty wrote: > Hello, > > As promised, I put together some additional information on phishing > attacks and feel strongly that their mention should not be included. > I'll answer a few other questions in line as well to clarify things > where I can. Stephen is tied up in meetings today, so we may or may > not get a response until later in the day. > > On Mon, Dec 1, 2014 at 8:24 PM, Kathleen Moriarty > wrote: >> Hi, >> >> Sent from my iPhone >> >>> On Dec 1, 2014, at 7:52 PM, Stephen Farrell >>> wrote: >>> >>> >>> Hiya, >>> >>>> On 01/12/14 22:42, Kathleen Moriarty wrote: Hi Stephen, Paul, & >>>> Michael, >>>> >>>> I reviewed the latest version of the HOBA draft and it is much >>>> improved from earlier versions, thanks for your work on this >>>> draft. Hopefully it will help mitigate threats to end users >>>> with reduced use of passwords and associated attacks. >>>> >>>> Here are comments for you to consider: >>> >>> Cool. Thanks for the reivew. I'm not clear if you regard these as >>> things that need fixing before IETF LC or as things to handle >>> during/after IETF LC. I'm guessing the latter but not sure but >>> it'll be clear as we argue or you start the IETF LC I guess:-) >> >> Either is fine. Nothing is too drastic in my review. > > It's simple enough to update with a few fixes and publish, so an -06 > is appreciated prior to triggering last call. It's better to avoid > the same discussions if possible and save some time. Okey dokey. I've put out a -06 with the changes described below. > >>> >>> (So far, I made one change below in my local copy that'd go into >>> a -06 whenever needed.) >>> >>>> >>>> Abstract - I'd remove the bit about phishing attacks and just >>>> state that it prevents password theft since there are no >>>> passwords to steal, which is covered nicely in the >>>> introduction. Phishing is a bit more complicated, involves >>>> several steps that include social engineering to get users to >>>> click on links, down;pad of malware/trojans, which are >>>> difficult to defeat and may or may not be targeting >>>> credentials. Spear phishing attacks that install trojans have >>>> been around for >>> >>> Not all trojan installs are phishing though. >> No, but they are commonly part of the phishing and spear phishing >> attacks that has the financial sector worried. I think you should >> just say what you mean instead if lumping in phishing >> unnecessarily. "lumping in" is purely rhetorical. >>> >>>> several years and are able to steal all types of credentials >>>> including PKI X.509 stored in PKCS#11 containers (Sykipot, >>>> Zeus, etc.). >>>> http://it.slashdot.org/story/12/01/13/2216218/sykipot-trojan-variant-stealing-dod-smartcard-credentials >>>> >>>> http://www.secureworks.com/cyber-threat-intelligence/threats/zeus/ >>> >>> Hm. I don't consider theft of a private key via trojan to be a >>> phish. It is an attack of course, and with similar impact but not >>> a phish according to my definition. Happy to be corrected but I >>> believe my definition is ok tbh. > > I put together some information to help with an understanding on > current definitions of phishing that include really any method of > stealing credentials including crimeware, malware, and trojans. As > such, my strong preference would be to remove mention of phishing > and directly state the attack description that HOBA protects a user > from and include what attacks to which it may be vulnerable. It > adds unnecessary confusion and is not in line with current Fully disagree. I find nothing whatsoever confusing about the abstract and its mention of phishing. > terminology to keep the term phishing. Attacks against HOBA are > inevitable and will be used in the phishing world (whatever those > attacks are - XXS, etc.), but in general, HOBA does provide improved > protection against password theft and reuse. Stating that instead > would be clearer to the reader and accurate. > > Phishing attacks are broad and cover lots of ground. They all start > with a social engineering aspect, tricking a user to click on a > link. The link may be a simple attack (not really the case anymore) > or a complex web site pretending to be your financial institution in > order to gather your credentials. While HOBA may help in that > instance, the more common phishing attacks today include > malware/Trojan (or crimeware that includes malware, trojans, etc., > per the APWG) installs from the link the user is tricked into > clicking on. The link could just as easily include a XXS attack. > Phishing attacks will evolve to encompass attacks against HOBA. Even > PKI stored via a PKSC#11 interface is vulnerable to phishing attacks > - just not the same attack that steals your password, a variation > that uses a trojan. > > As promised, I went through several sites to get updated definitions > to help clear this up: Thanks. So let's see, since this is the source of our different opinions. > > Definitions in RFCs: The definition of phishing from RFC4949 captures That one is certainly a bit odd, but isn't of much use. It does only mention credentials a user can type though. > the basic concept of phishing as a social engineering attack, but > doesn't get into variations that have evolved over time. The first > paragraph of the introduction in RFC5901 (2010 - but was really from > 2007) explains the variations better n that malware can be part of > the phishing attack. Right, that says: " The terms "phishing" and "fraud" are used interchangeably in this document..." which is odd as clearly not all fraud is phishing. However that also goes on to only talk about user-entered credentials saying: The terms "phishing" and "fraud" are used interchangeably in this document to characterize broadly-launched social engineering attacks in which an electronic identity is misrepresented in an attempt to trick individuals into revealing their personal credentials (e.g., passwords, account numbers, personal information, ATM PINs, etc.). A successful phishing attack on an individual allows the phisher (i.e., the attacker) to exploit the individual's credentials for financial or other gain. Phishing attacks have morphed from directed email messages from alleged financial institutions to more sophisticated lures that may also include malware. So far, only human-entered credentials are mentioned. > There's nothing to prevent Cross site scripting > from being part of a phishing attack either. Well, one could extend a definition to include elephants too but that'd also not be very useful:-) > Wikipedia: https://en.wikipedia.org/wiki/Phishing The third sentence > of wikipedia's definition includes mention of malware as well: > "Phishing emails may contain links to websites that are infected with > malware." That also says "...directs users to enter details at a fake website whose look and feel are almost identical to the legitimate one" which matches my idea of phishing. > > It case it helps to see examples of phishing attacks that are common > today, here are a few more links: > > APWG: The APWG posts a Phishing Attack Trend report regularly so you > can see the evolution: http://apwg.org/resources/apwg-reports/ They > include an updated definition in the latest report that basically > says techniques continue to evolve to steal credentials and include > malware and other attack vectors. See the description of > 'crimeware' (used in their definition) on page 9 as it includes > multiple types. (My opinion - HOBA would only work against phishing > attacks for a short period of time): You are assuming your definition of phishing there, not mine. It is of course correct to say that implementations of HOBA can be attacked. That clearly does not mean all attacks are called phishing though. > http://docs.apwg.org/reports/apwg_trends_report_q2_2014.pdf And that says: "trick recipients into divulging financial data such as usernames and passwords" However, I grant you that it then goes on to say that any malware is covered too which is pretty meaningless IMO and makes for a quite odd definition. (However, one might easily expect something called the APWG to extend that definition more and more over time of course:-) > RSA: Anatomy of an attack (phishing is a typical first step with > malware installed to gain access) > https://blogs.rsa.com/anatomy-of-an-attack/ That seems to use the term to mean anything delivered via an email that's crafted to look like something else. Again a uselessly broad (non-)definition IMO. >> You may not, but the incident response world does. I can get you >> some links to show why I think this is a problem. I've been deeply >> embedded in the incident response world for several years and the >> folks that work on phishing attacks include the download of >> malware/Trojans that result when a user clicks on a link in a >> phishing email as part of a phishing attack. The malware/Trojans >> frequently steal credentials among other data of interest. The >> APWG helps with the takedown of malware distribution servers as >> part of their response to the phishing use case they support (they >> do a few other attack types now too). >>>> >>>> There would just be a short window until HOBA was defeat-able >>>> in spear phishing related attacks using trojans installed on >>>> the client. >>> >>> Yes, but that would not be a phishing attack. HOBA is, as the >>> abstract correctly states "not vulnerable to phishing attacks." >> >> See above, I disagree as the common usage includes the download of >> malware as part of a phishing attack. > > See above updated definitions from good sources. Again, we disagree - I think those are not good definitions at all. However, this is boring and disputing a non-normative word or two is a really bad use of our time so I've changed the abstract to say: HTTP Origin-Bound Authentication (HOBA) is a digital signature based design for an HTTP authentication method. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. >>>> By simply stating the password theft, you are covering more >>>> attack types that steal passwords on the client side than just >>>> those used as part of phishing attacks and lower the complexity >>>> from using a full blown PKI. This is what I think you need to >>>> target HOBA's use toward. >>>> >>>> Section 1 Curious as to how it scales since it seems >>>> private/public keys pairs would have to be stored, but I guess >>>> that's no different than passwords. Maybe it doesn't matter >>>> with that assumption. >>> >>> Yep. Scaling isn't a differentiator, it's linear in the size of >>> the user population basically. I've used the same nosql DB as is >>> used on hoba.ie with millions of entries on a standard server >>> with no issues at all. >> >> Thanks. >>> >>>> >>>> In the third paragraph possible attacks on the server side are >>>> mentioned when passwords are used, you should also mention >>>> client side issues like password theft and re-use (on same site >>>> or others) will be prevented. >>> >>> I'm not clear that that's worth adding but don't object. I do >>> think the password verifier DB theft issue is the main >>> distinction between HOBA and password based schemes though so >>> would prefer keep that front and centre. (And as you say later, >>> that issue is called out eventually.) >> >> It was a way to get away from the phishing comment to what it >> actually helps prevent. >> >>> >>>> You may or may not want to include this, but it does have >>>> traction/interest in industry to improve password >>>> authentication: Other mechanisms with Basic could combine with >>>> other factors to use 'risk-based' authentication systems >>>> (geo-location, system properties, etc.). HOBA could do this >>>> too. This may include browser information (make sure it's the >>>> same one each time or prompt with some other auth if it >>>> changes), IP layer information to get geo-location (can't >>>> travel somewhere in less than x hours - doesn't make sense). >>> >>> I don't think it'd be a good idea to start to describe other >>> mechanisms here, nor to try cover multi-factor authentication. >>> There is a fine RFC to be written on that, but this ain't it:-) >>> If we tried that, we'd face potentially endless comment from all >>> sides which I don't think would be worthwhile. And it'd also >>> cause issues for other WG drafts too maybe if some do, and some >>> don't try describe multi-factor auth issues. >> >> It's used in industry to help prevent attacks that involve >> credentials, like reuse of credentials stolen in phishing attacks >> ;-). I'm not sure there is interest to standardize, but wanted to >> point this out since it's commonly used (pretty ubiquitous in the >> financial sector). >>> >>>> Section 5 If this is describing both HTTP HOBA and HOBA-js, it >>>> would be good to state that explicitly and differences that >>>> should be noted. The intro reads as if it is just for HTTP, if >>>> that's the case, then leave it alone. >>> >>> Well, we only use the -http and -js when necessary (i.e. when >>> there's a difference) and leave it implicit when its obvious or >>> doesn't matter. Does it matter here? (I've no problem adding that >>> this covers both if that helps, but I'm not clear it does help.) >> >> If you could just state what's intended for section 5 so it's clear >> to the reader, that will help. Thanks. > > This one is left as a request, just calling it out so it doesn't get > lost. Thanks. > >> >>> >>>> Section 5.3 Second to last paragraph, first time you use the >>>> term join (I think), you should provide a reference or explain >>>> what it means as this will likely be asked in subsequent >>>> reviews. You describe it in section 6.1, I think it would be >>>> better to have the explanation in this section. >>> >>> Good point. I think the following para of 5.3 addresses the issue >>> though. Probably good to not say "already joined" as the first >>> occurrence mind you. >>> >>> I guess s/already-joined/another/ would be a good change, as it's >>> clarified in the next para. (Did that in our author's svn copy.) >> >> Thanks. >>> >>>> >>>> Section 6 What do you mean by "All additional services MUST be >>>> performed in TLS-protected sessions"? If you are referring to >>>> HOBA and HOBA-js or the authentication process as the >>>> additional service, it would be better to state that >>>> explicitly. >>> >>> All meaning all:-) We didn't see any point in being selective so >>> the all-TLS thing seems easier. You need TLS at least to ensure >>> there's no MITM handing off challenges or new public keys being >>> submitted etc. So I'm not sure what's not clear tbh. >> >> The use of the word additional is what raised the question for me. >> Can you remove it? > > This one too - just trying to not get it lost in a reply to myself > :-) Actually before I did this I decided that that's not the right change. We only RECOMMEND TLS for the actual authentication step which is correct as HOBA ought be usable to replace any old cleartext uses of basic or digest, even if it's ridiculous that such things still exist. Since the other bits are all new, it's ok to have a MUST for TLS for section 6 I reckon. So I got rid of "additional" and replaced it with a ref to section 5. Please take a look at the just-posted -06 and then hopefully press that "request ietf LC" button:-) Ta, S. PS: I didn't check these changes with Paul or Mike as they're basically tweaks so it's slightly possible I might have mucked up a little but I'm fairly sure they could let us know during IETF LC and that'd be fine. > >> >>> >>>> >>>> Section 8.2 >>>> >>>> Second paragraph: current text: Again it's not clear that we >>>> are worse in this regard because the same attacker could get at >>>> browser password files, etc too. One possible mitigation is to >>>> encrypt the keystore with a password/pin the user supplies. >>>> This may sound counter intuitive, but the object here is to >>>> keep passwords off of servers to mitigate the multiplier effect >>>> of a large scale compromise ala LinkedIn because of shared >>>> passwords across sites. >>>> >>>> Proposed update: Again it's not clear that we are worse in this >>>> regard because the same attacker could get at browser password >>>> files, stored PKI credentials (even via PKCS#11 interface), etc >>>> too. One possible mitigation is to encrypt the keystore with a >>>> password/pin the user supplies. This may sound counter >>>> intuitive, but the object here is to keep passwords off of >>>> servers to mitigate the multiplier effect of a large scale >>>> compromise ala LinkedIn because of shared passwords across >>>> sites. This recommendation does not help against possible >>>> client side attacks, which are inevitable with the use of >>>> phishing/spear phishing related malware and trojans. >>>> >>>> Explanation: All forms of keys stored on a computer have been >>>> subject to attacks, including attacks that automate this theft >>>> of passwords and even PKI credentials in malware. The last >>>> sentence of paragraph 2 could be stronger to reflect this >>>> inevitability. Storing the credentials in an external secure >>>> container does help, but those have been successfully attacked >>>> too. >>> >>> I agree with your last but the section here is specific to HTPM5 >>> localStorage as a private key store so pkcs#11 isn't relevant at >>> this point. >> >> Is just the point that this will be broken, it's pretty much >> inevitable. > > Here and the Abstract are the places that may need some adjustment > once agreed. > >> >>> And I think we've hit that difference in our definitions of >>> phishing again too:-) >> >> I'll get some links to show the common usage and use case >> descriptions of phishing and spear phishing attacks tomorrow. >>> >>> So I'd suggest no change there. >>> >>> >>>> I'm glad to see the password re-use problem mentioned in the >>>> last paragraph, so you don't need that in the intro, but I'll >>>> leave my comment there as it is part of the overview as to why >>>> it might be a good idea to use HOBA. You may want to emphasize >>>> the difficulty of PKI and the advantage of preventing server >>>> side password database attacks since the credentials can be >>>> stolen on the client side (or will be once deployed). This has >>>> a niche and we should be clear on that IMO. >>> >>> Fair points but I think the audience for this are probably aware >>> of all that. I don't think we should try sell HOBA in the RFC, >>> but just define it - the sales pitch that is absolutely required >>> is for elsewhere/others. But maybe others think differently. >> >> I was just trying to get you away from the phishing angle as it >> won't work for long. > > Thanks, Kathleen > >> >> Have a good night. Kathleen >>> >>> Cheers, S. >>> >>> >>>> >>>> > > > From nobody Fri Dec 5 08:43:42 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BFD1AD041; Fri, 5 Dec 2014 08:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beeU6Es0wsNS; Fri, 5 Dec 2014 08:43:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2DC1A1B7D; Fri, 5 Dec 2014 08:43:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3C969BF0A; Fri, 5 Dec 2014 16:43:19 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmXYFvKbK2O3; Fri, 5 Dec 2014 16:43:19 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1819FBF06; Fri, 5 Dec 2014 16:43:19 +0000 (GMT) Message-ID: <5481E0A7.2090604@cs.tcd.ie> Date: Fri, 05 Dec 2014 16:43:19 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "saag@ietf.org" , websec , "uta@ietf.org" , "ietf-http-wg@w3.org Group" , "http-auth@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/zQ2M6x7LGTL4Cu7QCVvRzD891Ko Subject: [http-auth] unbearable - new mailing list to discuss better than bearer tokens... X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Stephen Farrell List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 16:43:33 -0000 Hiya, Following up on the presentation at IETF-91 on this topic, [1] we've created a new list [2] for moving that along. The list description is: "This list is for discussion of proposals for doing better than bearer tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks." If you're interested please join in. Thanks to Vinod and Andrei for agreeing to admin the list. We'll kick off discussion in a few days when folks have had a chance to subscribe. Cheers, S. PS: Please don't reply-all to this, join the new list, wait a few days and then say what you need to say:-) [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf [2] https://www.ietf.org/mailman/listinfo/unbearable From nobody Fri Dec 5 09:22:08 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C301A0235 for ; Fri, 5 Dec 2014 09:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwLz_GKeJmGE for ; Fri, 5 Dec 2014 09:22:06 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0CA1AD424 for ; Fri, 5 Dec 2014 09:22:00 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-fe-5481e9b72ede Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id CB.B7.03354.7B9E1845; Fri, 5 Dec 2014 12:21:59 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id sB5HLx7N002493 for ; Fri, 5 Dec 2014 12:21:59 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB5HLvI5017615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 5 Dec 2014 12:21:59 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB5HLvSo009944; Fri, 5 Dec 2014 12:21:57 -0500 (EST) Date: Fri, 5 Dec 2014 12:21:57 -0500 (EST) From: Benjamin Kaduk To: IETF HTTP Auth In-Reply-To: <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> Message-ID: References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUixCmqrLv9ZWOIwdKXVhYf9s9hcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr+uk+wFewQrJs2cy9zA+J+3i5GTQ0LAROLz+TPMELaYxIV7 69m6GLk4hAQWM0msur6ICcI5ySgx5eBydgjnFpPEmy832UBahATqJU72LWQFsVkEtCT+nTvC BGKzCahIzHyzEaxGREBd4tW6fewgtrBAksT5GRfB1nEK2Ep0/TsJ1ssr4CjRcOQsI8TMIomj m5aC2aICOhKr909hgagRlDg58wmYzQy0a/n0bSwTGAVmIUnNQpJawMi0ilE2JbdKNzcxM6c4 NVm3ODkxLy+1SNdELzezRC81pXQTIzj8JPl3MH47qHSIUYCDUYmHd4VEY4gQa2JZcWXuIUZJ DiYlUd6rT4BCfEn5KZUZicUZ8UWlOanFhxglOJiVRHiTZwPleFMSK6tSi/JhUtIcLErivJt+ 8IUICaQnlqRmp6YWpBbBZGU4OJQkeHe/AGoULEpNT61Iy8wpQUgzcXCCDOcBGv4EpIa3uCAx tzgzHSJ/ilFRSpx3CUhCACSRUZoH1wtLD68YxYFeEeblBCYLIR5gaoHrfgU0mAlo8N1isMEl iQgpqQZGlv4E9cUmJdN++ubalH9dfi7gRcOFm0vslt0Uu9qSc//hLKMytWn/vbdNz7M7ovMs M3lD0Y8kTRlOl8MG266IHP7z0veh4qycVR8uf/41ie+8zM+FK3Ld7vw5yHFkivin/fP75tQv Mi5RumM3s2bJPOl7KSu12v9pSTXtEF7y4k30rdBFrnsOliixFGckGmoxFxUnAgDZaLLw6gIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/ZiOBP7xk3zsdJwhBTh0pZNRoezo Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 17:22:07 -0000 On Tue, 2 Dec 2014, Yoav Nir wrote: > Thank you, Julian > > This begins a 2-week WGLC for this document. > > Please take the time to read through and post any comments to the list. My apologies if this has already been covered, but the abstract includes the phrase "obfuscated by the use of Base64 encoding" (the introduction includes similar content). It looks like this was introduced in the -01, and the on-list discussion of the -00 didn't really talk about it -- there was a note from Bjoern that the abstract "could use another sentence stating what the `Basic` scheme is", but the word "obfuscate" did not appear. As such, I thought I would mention it now -- it's not really clear that Base64 encoding counts as obfuscation in this context, where the HTTP headers make it very clear that the userid/password are being conveyed. I think the submission checklist wants the abstract (and introduction?) to explicitly mention when an RFC is being updated or obsoleted. Relatedly, the first clause of the introduction says that this document defines "basic", but the citation to RFC 7235 could be read as if it is a citation for "basic" (as opposed to HTTP Authentication); perhaps this is better: % This document defines "Basic" as a Hypertext Transfer Protocol (HTTP) % Authentication Scheme ([RFC7235]), which transmits credentials as % Base64-encoded userid/password pairs. Section 3 says that "Senders can use the new 'charset' parameter", but it seems that only servers can do so. Was this intended to say "Servers" instead of "Senders"? Section for says that the transmission of the password is "essentially cleartext", whereas section 1 just says that it is "cleartext". Which is it? Grammar nits: In section 2: % 1. obtains userid and password from the user, I would add the definite article "the" before "userid" to match the other items. In the paragraph following that list, I would s/compatible to/compatible with/. In the paragraph following that paragraph, you could add "The" at the beginning to avoid starting the sentence with the identifier "userid" (and the ensuing debate about whether to capitalize the initial letter). -Ben From nobody Fri Dec 5 09:25:37 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEAC1AD457 for ; Fri, 5 Dec 2014 09:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4bxExx9Tcsy for ; Fri, 5 Dec 2014 09:25:34 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD391AD44E for ; Fri, 5 Dec 2014 09:25:34 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so1152014iga.14 for ; Fri, 05 Dec 2014 09:25:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xaOGxCpv73gC1LmW4zecJrVhp+gkoOR7dNSpxsTG558=; b=GeJ7J1fctx2ZOs7Pxgwmyc0J8Kr2fGiwb/Omhz7WzYL8rIAnY7c+r9mtApuRacpIqm /KttDtNNNUPfya9GjtqPGn5F2z2LLVMQm6/U7/jUT1Ue3XSkEVdj1LHoSZRyJFKYm4gI tfQhV9IxOCA0DiktEvRLayVk+DC6uhoX5mc1J9M24VICa4YWokwEgoRt3Uzj2Y3kyKeQ YaexUu5j0Kv9RLABq5v81EdPhlRjdNutcGqCs1eRF80KHmycsK8asFfAqWLp/fR3aUVa m6XV0ZrP+yOGhUtOg8vf6ZJS5SVSzvVAGI3MFfex0ixwZrPCS/gaIg/3z1s3fpc0tF1c +qWQ== X-Gm-Message-State: ALoCoQnq8K5mJyzNGGprm29afP4+eMS9czq2ltbosULM5kgz5H00Y8Beuiljx+7N4RpJyMTPs2O4 X-Received: by 10.42.212.10 with SMTP id gq10mr16511765icb.79.1417800334122; Fri, 05 Dec 2014 09:25:34 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id qj6sm1100077igc.1.2014.12.05.09.25.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Dec 2014 09:25:33 -0800 (PST) Message-ID: <5481EA8C.4030202@andyet.net> Date: Fri, 05 Dec 2014 10:25:32 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Benjamin Kaduk , IETF HTTP Auth References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/8AayHkqZTDtpSYl2ev2fav5Un3U Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 17:25:36 -0000 On 12/5/14, 10:21 AM, Benjamin Kaduk wrote: > On Tue, 2 Dec 2014, Yoav Nir wrote: > >> Thank you, Julian >> >> This begins a 2-week WGLC for this document. >> >> Please take the time to read through and post any comments to the list. > > My apologies if this has already been covered, but the abstract includes > the phrase "obfuscated by the use of Base64 encoding" (the introduction > includes similar content). It looks like this was introduced in the -01, > and the on-list discussion of the -00 didn't really talk about it -- there > was a note from Bjoern that the abstract "could use another sentence > stating what the `Basic` scheme is", but the word "obfuscate" did not > appear. As such, I thought I would mention it now -- it's not really > clear that Base64 encoding counts as obfuscation in this context, where > the HTTP headers make it very clear that the userid/password are being > conveyed. That struck me as odd, too. I'd suggest "encoded in Base 64" instead. Peter From nobody Fri Dec 5 10:49:38 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5281AD55F for ; Fri, 5 Dec 2014 10:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRr-mKo0Deu1 for ; Fri, 5 Dec 2014 10:49:34 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8457C1AD55E for ; Fri, 5 Dec 2014 10:49:34 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so1004592lbi.24 for ; Fri, 05 Dec 2014 10:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=W+LqXACEUFhKzcqVgCKxuCf9rfqlSJrE49Gkgn6iMLY=; b=EhuxZKhHfy/3cw9GAFs0VfqxOJY3RKebwB8J6p4xhBvWtaAwyQrHb3UUYRoXApbNDv ucF0lIHxOXPoOCIBRQkotNE6Jf5URtUZ+b5oI5sIgE7y2lgCWC0nhm/DriawWSULoIFf huJJkSbTxQxtEpE6HL82YRHdUHV47kj7ybsnQkbKCM7WiaXw9ImuWDRN2VSU5iAjrP74 5fmOXN9L51Jxzbg3tGrah+ZgSC4k5SIkw+h0pvfeYAzWOr5SENQYI8Y6+dALvM6EqFUx pVdvyZPBbZkAXvCEkBhQ9CUpeZUVulL0ktGU6ocYYlavf1PDfkb2vzmuROF0OkqfCjEG Es2w== MIME-Version: 1.0 X-Received: by 10.112.219.227 with SMTP id pr3mr4204185lbc.63.1417805372975; Fri, 05 Dec 2014 10:49:32 -0800 (PST) Received: by 10.25.24.144 with HTTP; Fri, 5 Dec 2014 10:49:32 -0800 (PST) Date: Fri, 5 Dec 2014 13:49:32 -0500 Message-ID: From: Matthew Lepinski To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=001a11c334129df16c05097c8914 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/xm7-5rgVST0swr1EayrKY_C3I1I Subject: [http-auth] Draft Minutes for IETF 91 HTTP-Auth Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 18:49:37 -0000 --001a11c334129df16c05097c8914 Content-Type: text/plain; charset=UTF-8 Draft minutes have been posted for the HTTP-Auth session at IETF 91. http://www.ietf.org/proceedings/91/minutes/minutes-91-httpauth If you have any comments/corrections for the minutes, please let us know. Thanks, - Matt and Yoav --001a11c334129df16c05097c8914 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Draft minutes have been posted for the HTTP-Auth session a= t IETF 91.


If you have any comments= /corrections for the minutes, please let us know.

= Thanks,
- Matt and Yoav
--001a11c334129df16c05097c8914-- From nobody Fri Dec 5 10:52:39 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDC81A1B4E for ; Fri, 5 Dec 2014 10:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzedwhM9tr66 for ; Fri, 5 Dec 2014 10:52:35 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB671AD55F for ; Fri, 5 Dec 2014 10:52:34 -0800 (PST) Received: from [192.168.2.160] ([93.217.106.159]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M03qC-1XiRo82cwu-00uJmi; Fri, 05 Dec 2014 19:52:30 +0100 Message-ID: <5481FEE1.8070403@gmx.de> Date: Fri, 05 Dec 2014 19:52:17 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Benjamin Kaduk , IETF HTTP Auth References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:I6I0i5k8WtTGkWu+mhr6hIC4t8ZAKksyqck7xICug5ayfFhJ3vn LtNREVideR6v6thnsCFyfUc7JcqxhIhDa7r0wqJ8dNiSHxHFsqQB40mswfUmurHKEqK/k/G 7GUeJagQPJTs1VJb5B4YxcttbXXO+dpbayQ7rJY1NCyCU0fdzmTc1aKvKYI3/qmK7zgGbNW AHKWRcGQtI9KwMy2NtP4Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/tCnc4DPAkTF-Bdhy5m75gEy5FCg Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 18:52:37 -0000 On 2014-12-05 18:21, Benjamin Kaduk wrote: > On Tue, 2 Dec 2014, Yoav Nir wrote: > >> Thank you, Julian >> >> This begins a 2-week WGLC for this document. >> >> Please take the time to read through and post any comments to the list. > > My apologies if this has already been covered, but the abstract includes > the phrase "obfuscated by the use of Base64 encoding" (the introduction > includes similar content). It looks like this was introduced in the -01, > and the on-list discussion of the -00 didn't really talk about it -- there > was a note from Bjoern that the abstract "could use another sentence > stating what the `Basic` scheme is", but the word "obfuscate" did not > appear. As such, I thought I would mention it now -- it's not really > clear that Base64 encoding counts as obfuscation in this context, where > the HTTP headers make it very clear that the userid/password are being > conveyed. I think that "obfuscate" pretty much nails it. > I think the submission checklist wants the abstract (and introduction?) to > explicitly mention when an RFC is being updated or obsoleted. Relatedly, I've heart that before, but I also heard the opposite at some other point. I'll wait for the IESG feedback on this. > the first clause of the introduction says that this document defines > "basic", but the citation to RFC 7235 could be read as if it is a citation > for "basic" (as opposed to HTTP Authentication); perhaps this is better: > > % This document defines "Basic" as a Hypertext Transfer Protocol (HTTP) > % Authentication Scheme ([RFC7235]), which transmits credentials as > % Base64-encoded userid/password pairs. Concern understood, but now the "which" applies to the wrong term. I'll try to address this differently. > Section 3 says that "Senders can use the new 'charset' parameter", but it > seems that only servers can do so. Was this intended to say "Servers" > instead of "Senders"? I believe my intent was to include proxies, but then, "server" includes proxies too. > Section for says that the transmission of the password is "essentially > cleartext", whereas section 1 just says that it is "cleartext". Which is > it? I'll remove the "essentially" from the Security Considerations. > Grammar nits: > > > In section 2: > > % 1. obtains userid and password from the user, > > I would add the definite article "the" before "userid" to match the other > items. ack. > In the paragraph following that list, I would s/compatible to/compatible > with/. ack. > In the paragraph following that paragraph, you could add "The" at the > beginning to avoid starting the sentence with the identifier "userid" (and > the ensuing debate about whether to capitalize the initial letter). Thanks a lot for the feedback! -> Best regards, Julian From nobody Fri Dec 5 10:55:53 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170661AD56F for ; Fri, 5 Dec 2014 10:55:44 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJsTvqDLMChM for ; Fri, 5 Dec 2014 10:55:37 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233D51AD579 for ; Fri, 5 Dec 2014 10:55:34 -0800 (PST) Received: from [192.168.2.160] ([93.217.106.159]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M1jKo-1Xhtvd4BRq-00thqD; Fri, 05 Dec 2014 19:55:32 +0100 Message-ID: <5481FFA0.9070006@gmx.de> Date: Fri, 05 Dec 2014 19:55:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , Benjamin Kaduk , IETF HTTP Auth References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> <5481EA8C.4030202@andyet.net> In-Reply-To: <5481EA8C.4030202@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:xO8JsRNolxmK9zdIifW03plr89fSIKylfYa2XFlGqCDeLf0BEBC Zdumoyv+zAW2vyNfb5nAFBqGbdKdICiB45Cc8Jsr593I4X6F7xKSyYU0xqY6I6hmc9c1Q6i SS04Qz4aSvsWgxhp5eoXldblOImHC4OcLedBMv3n46MLkxzfadb72qjaghA21hWf8hKcUCm cHTHHJJ+0I3srF8N2U2Nw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/4oDHkqjE8VQ6bJQT_4AUygx2fx0 Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 18:55:44 -0000 On 2014-12-05 18:25, Peter Saint-Andre - &yet wrote: > On 12/5/14, 10:21 AM, Benjamin Kaduk wrote: >> On Tue, 2 Dec 2014, Yoav Nir wrote: >> >>> Thank you, Julian >>> >>> This begins a 2-week WGLC for this document. >>> >>> Please take the time to read through and post any comments to the list. >> >> My apologies if this has already been covered, but the abstract includes >> the phrase "obfuscated by the use of Base64 encoding" (the introduction >> includes similar content). It looks like this was introduced in the -01, >> and the on-list discussion of the -00 didn't really talk about it -- >> there >> was a note from Bjoern that the abstract "could use another sentence >> stating what the `Basic` scheme is", but the word "obfuscate" did not >> appear. As such, I thought I would mention it now -- it's not really >> clear that Base64 encoding counts as obfuscation in this context, where >> the HTTP headers make it very clear that the userid/password are being >> conveyed. > > That struck me as odd, too. I'd suggest "encoded in Base 64" instead. > > Peter What do others think? Would saying "slightly obfuscated" make things more bearable? (If we change it in the abstract we'll need to change the 2nd occurence as well, no) Best regards, Julian From nobody Fri Dec 5 11:18:51 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074701AD5F6 for ; Fri, 5 Dec 2014 11:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTlM6zmRns1f for ; Fri, 5 Dec 2014 11:18:45 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B08E1AD5F9 for ; Fri, 5 Dec 2014 11:18:45 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so1230034lab.34 for ; Fri, 05 Dec 2014 11:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NEP8tzlfe4hQ9PmxgZ2PmNEAtmbTO/Em75yrve/VSCo=; b=WU89//XlMSBEi8ttRNXKfwO8sYqr4Qils+L+Pr9ldtw2cHKt8z/QQz2M6YkPAEDTrH dY95JJU/bDc9likk4THzHsHO4csvmEtyyR9ab6L6oiZYdQf73r8iWozM7qLQ68Utmssv xKvncj3ZhlpCSiDnL/ooq/JVH93wpK7+YIzRBWR9LN2UKzscT+rm0+vF1HuBfIkXpAdf rhFgQ9/+gr+a3vkoSSEWhfkgfmt4fH6Cq69+xNL5j2mEHgpx0B6AdDpJY1Si8+0P42+U ndfa05faV54FQ6nS2xdYzi8YgR8gXZbiEL4AGMEIA1RLAALejUOcX/1WF2c7OZXNcpj6 2L+A== MIME-Version: 1.0 X-Received: by 10.112.73.102 with SMTP id k6mr4402915lbv.75.1417807123375; Fri, 05 Dec 2014 11:18:43 -0800 (PST) Received: by 10.112.49.52 with HTTP; Fri, 5 Dec 2014 11:18:43 -0800 (PST) In-Reply-To: <5481DCCA.3080308@cs.tcd.ie> References: <547D0D59.5070104@cs.tcd.ie> <78620582-D88B-4B58-9E98-15941A96809C@gmail.com> <5481DCCA.3080308@cs.tcd.ie> Date: Fri, 5 Dec 2014 14:18:43 -0500 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Q329rGruOn9xYg3fjN4DU-_M-Zo Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Review of draft-ietf-httpauth-hoba-05 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 19:18:50 -0000 Hi, On Fri, Dec 5, 2014 at 11:26 AM, Stephen Farrell wrote: > > Sorry for being slow, travel and all that... No worries. > > On 02/12/14 16:28, Kathleen Moriarty wrote: >> Hello, >> >> As promised, I put together some additional information on phishing >> attacks and feel strongly that their mention should not be included. >> I'll answer a few other questions in line as well to clarify things >> where I can. Stephen is tied up in meetings today, so we may or may >> not get a response until later in the day. >> >> On Mon, Dec 1, 2014 at 8:24 PM, Kathleen Moriarty >> wrote: >>> Hi, >>> >>> Sent from my iPhone >>> >>>> On Dec 1, 2014, at 7:52 PM, Stephen Farrell >>>> wrote: >>>> >>>> >>>> Hiya, >>>> >>>>> On 01/12/14 22:42, Kathleen Moriarty wrote: Hi Stephen, Paul, & >>>>> Michael, >>>>> >>>>> I reviewed the latest version of the HOBA draft and it is much >>>>> improved from earlier versions, thanks for your work on this >>>>> draft. Hopefully it will help mitigate threats to end users >>>>> with reduced use of passwords and associated attacks. >>>>> >>>>> Here are comments for you to consider: >>>> >>>> Cool. Thanks for the reivew. I'm not clear if you regard these as >>>> things that need fixing before IETF LC or as things to handle >>>> during/after IETF LC. I'm guessing the latter but not sure but >>>> it'll be clear as we argue or you start the IETF LC I guess:-) >>> >>> Either is fine. Nothing is too drastic in my review. >> >> It's simple enough to update with a few fixes and publish, so an -06 >> is appreciated prior to triggering last call. It's better to avoid >> the same discussions if possible and save some time. > > Okey dokey. I've put out a -06 with the changes described > below. Thank you. > >> >>>> >>>> (So far, I made one change below in my local copy that'd go into >>>> a -06 whenever needed.) >>>> >>>>> >>>>> Abstract - I'd remove the bit about phishing attacks and just >>>>> state that it prevents password theft since there are no >>>>> passwords to steal, which is covered nicely in the >>>>> introduction. Phishing is a bit more complicated, involves >>>>> several steps that include social engineering to get users to >>>>> click on links, down;pad of malware/trojans, which are >>>>> difficult to defeat and may or may not be targeting >>>>> credentials. Spear phishing attacks that install trojans have >>>>> been around for >>>> >>>> Not all trojan installs are phishing though. >>> No, but they are commonly part of the phishing and spear phishing >>> attacks that has the financial sector worried. I think you should >>> just say what you mean instead if lumping in phishing >>> unnecessarily. > > "lumping in" is purely rhetorical. > >>>> >>>>> several years and are able to steal all types of credentials >>>>> including PKI X.509 stored in PKCS#11 containers (Sykipot, >>>>> Zeus, etc.). >>>>> http://it.slashdot.org/story/12/01/13/2216218/sykipot-trojan-variant-stealing-dod-smartcard-credentials >>>>> >>>>> > http://www.secureworks.com/cyber-threat-intelligence/threats/zeus/ >>>> >>>> Hm. I don't consider theft of a private key via trojan to be a >>>> phish. It is an attack of course, and with similar impact but not >>>> a phish according to my definition. Happy to be corrected but I >>>> believe my definition is ok tbh. >> >> I put together some information to help with an understanding on >> current definitions of phishing that include really any method of >> stealing credentials including crimeware, malware, and trojans. As >> such, my strong preference would be to remove mention of phishing >> and directly state the attack description that HOBA protects a user >> from and include what attacks to which it may be vulnerable. It >> adds unnecessary confusion and is not in line with current > > Fully disagree. I find nothing whatsoever confusing about the > abstract and its mention of phishing. > >> terminology to keep the term phishing. Attacks against HOBA are >> inevitable and will be used in the phishing world (whatever those >> attacks are - XXS, etc.), but in general, HOBA does provide improved >> protection against password theft and reuse. Stating that instead >> would be clearer to the reader and accurate. >> >> Phishing attacks are broad and cover lots of ground. They all start >> with a social engineering aspect, tricking a user to click on a >> link. The link may be a simple attack (not really the case anymore) >> or a complex web site pretending to be your financial institution in >> order to gather your credentials. While HOBA may help in that >> instance, the more common phishing attacks today include >> malware/Trojan (or crimeware that includes malware, trojans, etc., >> per the APWG) installs from the link the user is tricked into >> clicking on. The link could just as easily include a XXS attack. >> Phishing attacks will evolve to encompass attacks against HOBA. Even >> PKI stored via a PKSC#11 interface is vulnerable to phishing attacks >> - just not the same attack that steals your password, a variation >> that uses a trojan. >> >> As promised, I went through several sites to get updated definitions >> to help clear this up: > > Thanks. So let's see, since this is the source of our different > opinions. > >> >> Definitions in RFCs: The definition of phishing from RFC4949 captures > > That one is certainly a bit odd, but isn't of much use. It does > only mention credentials a user can type though. > >> the basic concept of phishing as a social engineering attack, but >> doesn't get into variations that have evolved over time. The first >> paragraph of the introduction in RFC5901 (2010 - but was really from >> 2007) explains the variations better n that malware can be part of >> the phishing attack. > > Right, that says: " The terms "phishing" and "fraud" are used > interchangeably in this document..." which is odd as clearly not > all fraud is phishing. However that also goes on to only talk > about user-entered credentials saying: > > The terms "phishing" and > "fraud" are used interchangeably in this document to characterize > broadly-launched social engineering attacks in which an electronic > identity is misrepresented in an attempt to trick individuals into > revealing their personal credentials (e.g., passwords, account > numbers, personal information, ATM PINs, etc.). A successful > phishing attack on an individual allows the phisher (i.e., the > attacker) to exploit the individual's credentials for financial or > other gain. Phishing attacks have morphed from directed email > messages from alleged financial institutions to more sophisticated > lures that may also include malware. > > So far, only human-entered credentials are mentioned. > >> There's nothing to prevent Cross site scripting >> from being part of a phishing attack either. > > Well, one could extend a definition to include elephants > too but that'd also not be very useful:-) > >> Wikipedia: https://en.wikipedia.org/wiki/Phishing The third sentence >> of wikipedia's definition includes mention of malware as well: >> "Phishing emails may contain links to websites that are infected with >> malware." > > That also says "...directs users to enter details at a fake website > whose look and feel are almost identical to the legitimate one" which > matches my idea of phishing. > >> >> It case it helps to see examples of phishing attacks that are common >> today, here are a few more links: >> >> APWG: The APWG posts a Phishing Attack Trend report regularly so you >> can see the evolution: http://apwg.org/resources/apwg-reports/ They >> include an updated definition in the latest report that basically >> says techniques continue to evolve to steal credentials and include >> malware and other attack vectors. See the description of >> 'crimeware' (used in their definition) on page 9 as it includes >> multiple types. (My opinion - HOBA would only work against phishing >> attacks for a short period of time): > > You are assuming your definition of phishing there, not mine. > It is of course correct to say that implementations of HOBA > can be attacked. That clearly does not mean all attacks are > called phishing though. > >> http://docs.apwg.org/reports/apwg_trends_report_q2_2014.pdf > > And that says: > > "trick recipients into divulging financial data such as > usernames and passwords" > > However, I grant you that it then goes on to say that any malware > is covered too which is pretty meaningless IMO and makes for a > quite odd definition. (However, one might easily expect something > called the APWG to extend that definition more and more over time > of course:-) You might not like it, but this is how the term is used today. I've been on 3 conference committees this year around incident handling. The term is a moving target with the only part that is universal is the social engineering to get a user to click on a link. > >> RSA: Anatomy of an attack (phishing is a typical first step with >> malware installed to gain access) >> https://blogs.rsa.com/anatomy-of-an-attack/ > > That seems to use the term to mean anything delivered via > an email that's crafted to look like something else. Again > a uselessly broad (non-)definition IMO. That's why I didn't think you should use phishing in the draft. ;-) > >>> You may not, but the incident response world does. I can get you >>> some links to show why I think this is a problem. I've been deeply >>> embedded in the incident response world for several years and the >>> folks that work on phishing attacks include the download of >>> malware/Trojans that result when a user clicks on a link in a >>> phishing email as part of a phishing attack. The malware/Trojans >>> frequently steal credentials among other data of interest. The >>> APWG helps with the takedown of malware distribution servers as >>> part of their response to the phishing use case they support (they >>> do a few other attack types now too). >>>>> >>>>> There would just be a short window until HOBA was defeat-able >>>>> in spear phishing related attacks using trojans installed on >>>>> the client. >>>> >>>> Yes, but that would not be a phishing attack. HOBA is, as the >>>> abstract correctly states "not vulnerable to phishing attacks." >>> >>> See above, I disagree as the common usage includes the download of >>> malware as part of a phishing attack. >> >> See above updated definitions from good sources. > > Again, we disagree - I think those are not good definitions > at all. > > However, this is boring and disputing a non-normative word or > two is a really bad use of our time so I've changed the abstract > to say: > > HTTP Origin-Bound Authentication (HOBA) is a digital signature based > design for an HTTP authentication method. The design can also be > used in Javascript-based authentication embedded in HTML. HOBA is an > alternative to HTTP authentication schemes that require passwords and > therefore avoids all problems related to passwords, such as leakage > of server-side password databases. Thanks for that, I do think this is much more clear. > >>>>> By simply stating the password theft, you are covering more >>>>> attack types that steal passwords on the client side than just >>>>> those used as part of phishing attacks and lower the complexity >>>>> from using a full blown PKI. This is what I think you need to >>>>> target HOBA's use toward. >>>>> >>>>> Section 1 Curious as to how it scales since it seems >>>>> private/public keys pairs would have to be stored, but I guess >>>>> that's no different than passwords. Maybe it doesn't matter >>>>> with that assumption. >>>> >>>> Yep. Scaling isn't a differentiator, it's linear in the size of >>>> the user population basically. I've used the same nosql DB as is >>>> used on hoba.ie with millions of entries on a standard server >>>> with no issues at all. >>> >>> Thanks. >>>> >>>>> >>>>> In the third paragraph possible attacks on the server side are >>>>> mentioned when passwords are used, you should also mention >>>>> client side issues like password theft and re-use (on same site >>>>> or others) will be prevented. >>>> >>>> I'm not clear that that's worth adding but don't object. I do >>>> think the password verifier DB theft issue is the main >>>> distinction between HOBA and password based schemes though so >>>> would prefer keep that front and centre. (And as you say later, >>>> that issue is called out eventually.) >>> >>> It was a way to get away from the phishing comment to what it >>> actually helps prevent. >>> >>>> >>>>> You may or may not want to include this, but it does have >>>>> traction/interest in industry to improve password >>>>> authentication: Other mechanisms with Basic could combine with >>>>> other factors to use 'risk-based' authentication systems >>>>> (geo-location, system properties, etc.). HOBA could do this >>>>> too. This may include browser information (make sure it's the >>>>> same one each time or prompt with some other auth if it >>>>> changes), IP layer information to get geo-location (can't >>>>> travel somewhere in less than x hours - doesn't make sense). >>>> >>>> I don't think it'd be a good idea to start to describe other >>>> mechanisms here, nor to try cover multi-factor authentication. >>>> There is a fine RFC to be written on that, but this ain't it:-) >>>> If we tried that, we'd face potentially endless comment from all >>>> sides which I don't think would be worthwhile. And it'd also >>>> cause issues for other WG drafts too maybe if some do, and some >>>> don't try describe multi-factor auth issues. >>> >>> It's used in industry to help prevent attacks that involve >>> credentials, like reuse of credentials stolen in phishing attacks >>> ;-). I'm not sure there is interest to standardize, but wanted to >>> point this out since it's commonly used (pretty ubiquitous in the >>> financial sector). >>>> >>>>> Section 5 If this is describing both HTTP HOBA and HOBA-js, it >>>>> would be good to state that explicitly and differences that >>>>> should be noted. The intro reads as if it is just for HTTP, if >>>>> that's the case, then leave it alone. >>>> >>>> Well, we only use the -http and -js when necessary (i.e. when >>>> there's a difference) and leave it implicit when its obvious or >>>> doesn't matter. Does it matter here? (I've no problem adding that >>>> this covers both if that helps, but I'm not clear it does help.) >>> >>> If you could just state what's intended for section 5 so it's clear >>> to the reader, that will help. Thanks. >> >> This one is left as a request, just calling it out so it doesn't get >> lost. Thanks. >> >>> >>>> >>>>> Section 5.3 Second to last paragraph, first time you use the >>>>> term join (I think), you should provide a reference or explain >>>>> what it means as this will likely be asked in subsequent >>>>> reviews. You describe it in section 6.1, I think it would be >>>>> better to have the explanation in this section. >>>> >>>> Good point. I think the following para of 5.3 addresses the issue >>>> though. Probably good to not say "already joined" as the first >>>> occurrence mind you. >>>> >>>> I guess s/already-joined/another/ would be a good change, as it's >>>> clarified in the next para. (Did that in our author's svn copy.) >>> >>> Thanks. >>>> >>>>> >>>>> Section 6 What do you mean by "All additional services MUST be >>>>> performed in TLS-protected sessions"? If you are referring to >>>>> HOBA and HOBA-js or the authentication process as the >>>>> additional service, it would be better to state that >>>>> explicitly. >>>> >>>> All meaning all:-) We didn't see any point in being selective so >>>> the all-TLS thing seems easier. You need TLS at least to ensure >>>> there's no MITM handing off challenges or new public keys being >>>> submitted etc. So I'm not sure what's not clear tbh. >>> >>> The use of the word additional is what raised the question for me. >>> Can you remove it? >> >> This one too - just trying to not get it lost in a reply to myself >> :-) > > Actually before I did this I decided that that's not the right > change. We only RECOMMEND TLS for the actual authentication > step which is correct as HOBA ought be usable to replace any > old cleartext uses of basic or digest, even if it's ridiculous > that such things still exist. Since the other bits are all new, > it's ok to have a MUST for TLS for section 6 I reckon. So I > got rid of "additional" and replaced it with a ref to section > 5. Thank you. > > Please take a look at the just-posted -06 and then hopefully > press that "request ietf LC" button:-) > Thanks for posting a new version & sure, but it will need a shepherd report first. I clicked through a bunch of the buttons, but the draft shepherd will need to write the report and the chairs can kick it over to me when ready. Thank you, Kathleen > Ta, > S. > > PS: I didn't check these changes with Paul or Mike as they're > basically tweaks so it's slightly possible I might have mucked > up a little but I'm fairly sure they could let us know during > IETF LC and that'd be fine. > > > > >> >>> >>>> >>>>> >>>>> Section 8.2 >>>>> >>>>> Second paragraph: current text: Again it's not clear that we >>>>> are worse in this regard because the same attacker could get at >>>>> browser password files, etc too. One possible mitigation is to >>>>> encrypt the keystore with a password/pin the user supplies. >>>>> This may sound counter intuitive, but the object here is to >>>>> keep passwords off of servers to mitigate the multiplier effect >>>>> of a large scale compromise ala LinkedIn because of shared >>>>> passwords across sites. >>>>> >>>>> Proposed update: Again it's not clear that we are worse in this >>>>> regard because the same attacker could get at browser password >>>>> files, stored PKI credentials (even via PKCS#11 interface), etc >>>>> too. One possible mitigation is to encrypt the keystore with a >>>>> password/pin the user supplies. This may sound counter >>>>> intuitive, but the object here is to keep passwords off of >>>>> servers to mitigate the multiplier effect of a large scale >>>>> compromise ala LinkedIn because of shared passwords across >>>>> sites. This recommendation does not help against possible >>>>> client side attacks, which are inevitable with the use of >>>>> phishing/spear phishing related malware and trojans. >>>>> >>>>> Explanation: All forms of keys stored on a computer have been >>>>> subject to attacks, including attacks that automate this theft >>>>> of passwords and even PKI credentials in malware. The last >>>>> sentence of paragraph 2 could be stronger to reflect this >>>>> inevitability. Storing the credentials in an external secure >>>>> container does help, but those have been successfully attacked >>>>> too. >>>> >>>> I agree with your last but the section here is specific to HTPM5 >>>> localStorage as a private key store so pkcs#11 isn't relevant at >>>> this point. >>> >>> Is just the point that this will be broken, it's pretty much >>> inevitable. >> >> Here and the Abstract are the places that may need some adjustment >> once agreed. >> >>> >>>> And I think we've hit that difference in our definitions of >>>> phishing again too:-) >>> >>> I'll get some links to show the common usage and use case >>> descriptions of phishing and spear phishing attacks tomorrow. >>>> >>>> So I'd suggest no change there. >>>> >>>> >>>>> I'm glad to see the password re-use problem mentioned in the >>>>> last paragraph, so you don't need that in the intro, but I'll >>>>> leave my comment there as it is part of the overview as to why >>>>> it might be a good idea to use HOBA. You may want to emphasize >>>>> the difficulty of PKI and the advantage of preventing server >>>>> side password database attacks since the credentials can be >>>>> stolen on the client side (or will be once deployed). This has >>>>> a niche and we should be clear on that IMO. >>>> >>>> Fair points but I think the audience for this are probably aware >>>> of all that. I don't think we should try sell HOBA in the RFC, >>>> but just define it - the sales pitch that is absolutely required >>>> is for elsewhere/others. But maybe others think differently. >>> >>> I was just trying to get you away from the phishing angle as it >>> won't work for long. >> >> Thanks, Kathleen >> >>> >>> Have a good night. Kathleen >>>> >>>> Cheers, S. >>>> >>>> >>>>> >>>>> >> >> >> -- Best regards, Kathleen From nobody Fri Dec 5 14:08:53 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1261A6F3E for ; Fri, 5 Dec 2014 14:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NW12YnkbZAk for ; Fri, 5 Dec 2014 14:08:49 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4901A6F3B for ; Fri, 5 Dec 2014 14:08:41 -0800 (PST) X-AuditID: 1209190d-f79006d000000cfe-fd-54822ce85438 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 1A.27.03326.8EC22845; Fri, 5 Dec 2014 17:08:40 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id sB5M8do5016288; Fri, 5 Dec 2014 17:08:40 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB5M8b4u008867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Dec 2014 17:08:39 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB5M8bNd017275; Fri, 5 Dec 2014 17:08:37 -0500 (EST) Date: Fri, 5 Dec 2014 17:08:37 -0500 (EST) From: Benjamin Kaduk To: Julian Reschke In-Reply-To: <5481FEE1.8070403@gmx.de> Message-ID: References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> <5481FEE1.8070403@gmx.de> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrPtCpynEYNInVYsP++cwWWx++IbV gcnjw8c4jyVLfjIFMEVx2aSk5mSWpRbp2yVwZdy9OZe94CJ/xbJfs1gbGDfxdDFyckgImEjc /bSaHcIWk7hwbz1bFyMXh5DAYiaJju4WFghnA6PE4VUvGSGcg0wSd89sYgFpERKol9g1dxUb iM0ioCWxZe4FZhCbTUBFYuabjWBxEaD47Xt7GUFsZgF1ieWvLoPZwgJJEudnXASr5xRQk5jz 4wmYzSvgKHHs92GoMw4xSjx9sBZskKiAjsTq/VNYIIoEJU7OfMICMVRLYvn0bSwTGAVnIUnN QpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdILzezRC81pXQTIzhUJXl3ML47qHSIUYCD UYmHd4VEY4gQa2JZcWXuIUZJDiYlUV5JxaYQIb6k/JTKjMTijPii0pzUYqArOZiVRHiTZwOV 86YkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8HZpAw0VLEpNT61Iy8wp QUgzcXCCDOcBGj4XpIa3uCAxtzgzHSJ/ilFRSpw3GiQhAJLIKM2D64WlkleM4kCvCPP+A6ni AaYhuO5XQIOZgAbfLQa5urgkESEl1cDIKBmRMGuC6pWDb7/Wb7Ow9PZ9pprtOI9PnevsrsgV SaqRCS+bTZw+LLb6NIOheZfWip/JCZeZryU03JpSt/8Ea52zxPEPXt5qDseEP6Txc/+XTpKf t9hIul1ay2TOz1mHzKROv9uRoHt3+hTHa+uK+z/fatlQMts2gnGZ06S8Bdzfbgle7XiixFKc kWioxVxUnAgA/PrnEQADAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/SXCNazw3-q7C2-29Uyvb6hrv2yI Cc: IETF HTTP Auth Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 22:08:51 -0000 On Fri, 5 Dec 2014, Julian Reschke wrote: > > My apologies if this has already been covered, but the abstract includes > > the phrase "obfuscated by the use of Base64 encoding" (the introduction > > includes similar content). It looks like this was introduced in the -01, > > and the on-list discussion of the -00 didn't really talk about it -- there > > was a note from Bjoern that the abstract "could use another sentence > > stating what the `Basic` scheme is", but the word "obfuscate" did not > > appear. As such, I thought I would mention it now -- it's not really > > clear that Base64 encoding counts as obfuscation in this context, where > > the HTTP headers make it very clear that the userid/password are being > > conveyed. > > I think that "obfuscate" pretty much nails it. I would hope you think so, given that you wrote it :) I do not have strong feelings, myself, but it does seem like something that should at least be discussed on the list, since there is some reason to believe that people with strong opinions do exist. > > I think the submission checklist wants the abstract (and introduction?) to > > explicitly mention when an RFC is being updated or obsoleted. Relatedly, > > I've heart that before, but I also heard the opposite at some other point. > I'll wait for the IESG feedback on this. Sure, no particular hurry. > > the first clause of the introduction says that this document defines > > "basic", but the citation to RFC 7235 could be read as if it is a citation > > for "basic" (as opposed to HTTP Authentication); perhaps this is better: > > > > % This document defines "Basic" as a Hypertext Transfer Protocol (HTTP) > > % Authentication Scheme ([RFC7235]), which transmits credentials as > > % Base64-encoded userid/password pairs. > > Concern understood, but now the "which" applies to the wrong term. > > I'll try to address this differently. Thanks -- I was not super-happy with my new text, either. -Ben From nobody Fri Dec 5 16:53:07 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F401A1A7D for ; Fri, 5 Dec 2014 16:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssGlcNV2o3v1 for ; Fri, 5 Dec 2014 16:53:04 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16191A1BCD for ; Fri, 5 Dec 2014 16:53:03 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id hs14so1562687lab.36 for ; Fri, 05 Dec 2014 16:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7wP6G/L88HmMMOIY4NVr6CJrPXpYFfQRSAos1In9S/0=; b=cP0P7AACmRkaCm2ocKfBcJcNlO+yrGssgn2KAexH0CVfGs3ocf+ZtYEqExt/XwJY1/ c2u2zyzYCJRLBx0aCfs9QiujZ/9WOpdBB9go9GTfAq4GF0s76VICwJ5QHPIXcYC2LQHD 2navgNRQec12CJGUroj8kGzNtL3j1otU300qlK+Bq7cOyb5EJ2Py1igObV+ZJfbjATad fOS5TtyXH6bHltZrNTsIl2DwnBTyCBPVFjxRAqyJFfkgpLpSmuGbn9EVFIBZrjmlt1p7 aV8csszKbo+U+3kK5IxIUgSVYlgMqc2/18mit2mbYonTwAbl0Rfba2HH1lpZ9jDnfIOT rP8Q== MIME-Version: 1.0 X-Received: by 10.112.199.233 with SMTP id jn9mr5464200lbc.18.1417827182069; Fri, 05 Dec 2014 16:53:02 -0800 (PST) Received: by 10.114.99.36 with HTTP; Fri, 5 Dec 2014 16:53:02 -0800 (PST) In-Reply-To: <547DB5D1.5040909@gmx.de> References: <547DB5D1.5040909@gmx.de> Date: Fri, 5 Dec 2014 19:53:02 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=001a11c38b9c8a4e620509819dea Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/TOb5tElJvU48QXeEZ5raIIsPis0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Authentication-Info X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 00:53:06 -0000 --001a11c38b9c8a4e620509819dea Content-Type: text/plain; charset=ISO-8859-1 Hi Julian, The Digest draft based the definition of the Authentication-Info header on the auth-param defined in RFC7235, and it registers the header with the Message Header Field Registry. What else do you think we need to do to make it generic? Regards, Rifaat On Tue, Dec 2, 2014 at 7:51 AM, Julian Reschke wrote: > Hi there, > > this is a minor outstanding issue with the Digest and SCRAM drafts. It was > discussed in both the WG sessions and in hallway conversations. > > This header field originally was defined in the "Digest" part of RFC 2617, > and consequently, it was copied over into draft-ietf-httpauth-digest-08#section-3.5>. > > currently > uses it as well, but with with a slightly differing syntax. > > Given the fact that we have two authentication scheme definitions that > have a use case for this header field -- shouldn't we define it in a way so > that it becomes a generic (optional) feature for authentications schemes? > > Choices: > > 1) The cleanest approach seems to move the definition into a separate spec > which later can be absorbed by a future RFC7235bis. I volunteer to write > that spec (it'll be very short), but this would require changes to the > Digest spec post-WGLC. > > 2) Alternatively, we could tune the Digest draft to introduce the header > field in a more generic way, allowing other schemes to use it as well. That > would avoid a dependency to a yet unwritten spec, but the complexity > wouldn't really change. > > 3) We can tell Alexey to pick a different field name, which would shift > all required changes to the SCRAM spec. > > Feedback appreciated, > > Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a11c38b9c8a4e620509819dea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Julian,

The Digest draft based the d= efinition of the Authentication-Info header on the auth-param defined in RF= C7235, and it registers the header with the Message Header Field Registry.<= br>

What else do you think we need to do to make i= t generic?

Regards,
=A0Rifaat
= =A0

On Tue, = Dec 2, 2014 at 7:51 AM, Julian Reschke <julian.reschke@gmx.de><= /span> wrote:
Hi there,

this is a minor outstanding issue with the Digest and SCRAM drafts. It was = discussed in both the WG sessions and in hallway conversations.

This header field originally was defined in the "Digest" part of = RFC 2617, and consequently, it was copied over into <http://tools.ietf.org/html/draft-ietf-httpauth-digest-08#section-3.5>.

<http://tools.ietf.org/html/draft-ietf-httpauth-s= cram-auth-04> currently uses it as well, but with with a slig= htly differing syntax.

Given the fact that we have two authentication scheme definitions that have= a use case for this header field -- shouldn't we define it in a way so= that it becomes a generic (optional) feature for authentications schemes?<= br>
Choices:

1) The cleanest approach seems to move the definition into a separate spec = which later can be absorbed by a future RFC7235bis. I volunteer to write th= at spec (it'll be very short), but this would require changes to the Di= gest spec post-WGLC.

2) Alternatively, we could tune the Digest draft to introduce the header fi= eld in a more generic way, allowing other schemes to use it as well. That w= ould avoid a dependency to a yet unwritten spec, but the complexity wouldn&= #39;t really change.

3) We can tell Alexey to pick a different field name, which would shift all= required changes to the SCRAM spec.

Feedback appreciated,

Julian

_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth

--001a11c38b9c8a4e620509819dea-- From nobody Fri Dec 5 20:36:31 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7480D1A8835 for ; Fri, 5 Dec 2014 20:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i4oCZqmqkIC for ; Fri, 5 Dec 2014 20:36:28 -0800 (PST) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C891A87B0 for ; Fri, 5 Dec 2014 20:36:28 -0800 (PST) Received: from mail-la0-f45.google.com ([209.85.215.45]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKVIKHy+3G6J2nifgU68WGd7htLRj6UxnF@postini.com; Fri, 05 Dec 2014 20:36:28 PST Received: by mail-la0-f45.google.com with SMTP id gq15so1671666lab.4 for ; Fri, 05 Dec 2014 20:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=18uq1ubxDfRHs3qzk3f/zLJg83CwZzEV4srOr1GReCM=; b=dTioKbFtAzXQJDX93cGzyZfde3MCD02lC0B1yET1KdEX5EmBGp+BxBKoMTrlj/iXN+ Lib3M9fGhAiz2iwTFZp5/O5rNR47SA87uUzkVyMpQJQ11jvxx6ACuGX3ifX7f743cElc BDSl0AfkwO1bfBtS5e+q6znsh3dezEVMPCR0w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=18uq1ubxDfRHs3qzk3f/zLJg83CwZzEV4srOr1GReCM=; b=i78zpARgsoE0Reo4bADBByoIMWgfBIeL2VolrSwrhDLOLkAIulFQOLbauTxyj6g7WV AkKxjlnuetu9BwwC0+ZPq5OMIhWkwfFml9AywLWFO/yVOyPbl3y2LcPSi9AFENbDTjms +BQyS+hKsRYkr6uDeD3E+fGqT6agn7l8qelPkTYiVT1uB6hBIWHgHkNDAnlLU9abPPse Vi2xfOPkIp0MbjqYImhzunTYZtVeMySq/+QFPxwuBamIJLMujP4JP4TAaeo6s9tAgKUg YnTIamC869/tnwyewFnTGvxBUtDRf1BZqExt37bjdJvJoSgiHK/xXaMYqoB4r01AfNoL 9g1Q== X-Gm-Message-State: ALoCoQkQU5leAbRim9on9AP8IcNlbuyN+V4BIgnmaIzCBHJ0w2mm5Mrc4uTrHXg7PNGXc2+K5ae6LWSsG2VKY3hDBwNAjvDxwS/vyATFqtgrClmaYNEzS4AfY+TvqgP5KS9c8CtZpHGzpzqae29VgFlYZSPbfBmi5Q== X-Received: by 10.152.234.140 with SMTP id ue12mr5884045lac.78.1417840586527; Fri, 05 Dec 2014 20:36:26 -0800 (PST) X-Received: by 10.152.234.140 with SMTP id ue12mr5884037lac.78.1417840586425; Fri, 05 Dec 2014 20:36:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.83.203 with HTTP; Fri, 5 Dec 2014 20:36:06 -0800 (PST) In-Reply-To: <547DB5D1.5040909@gmx.de> References: <547DB5D1.5040909@gmx.de> From: Yutaka OIWA Date: Sat, 6 Dec 2014 13:36:06 +0900 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/reTLUJu_nv7f2yTvWHKqQDmvJmk Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Authentication-Info X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 04:36:30 -0000 Dear Julian, I prefer 1) (and 2 as an alternative if 1 is not feasible). We should not have a separate header for common functionalities (server-to-client authentication data vehicle) between auth. schemes as far as possible. The header is also a definitive part of Mutual spec (because it mandates mutual authentication on that header), and I'd like to harmonize use of the header with other schemes. When syntax differences between other drafts are resolved, I'll harmonize the syntax in my drafts as well. -- Yutaka OIWA, Ph.D. Senior Researcher, Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] 2014-12-02 21:51 GMT+09:00 Julian Reschke : > Hi there, > > this is a minor outstanding issue with the Digest and SCRAM drafts. It was > discussed in both the WG sessions and in hallway conversations. > > This header field originally was defined in the "Digest" part of RFC 2617, > and consequently, it was copied over into > . > > currently > uses it as well, but with with a slightly differing syntax. > > Given the fact that we have two authentication scheme definitions that have > a use case for this header field -- shouldn't we define it in a way so that > it becomes a generic (optional) feature for authentications schemes? > > Choices: > > 1) The cleanest approach seems to move the definition into a separate spec > which later can be absorbed by a future RFC7235bis. I volunteer to write > that spec (it'll be very short), but this would require changes to the > Digest spec post-WGLC. > > 2) Alternatively, we could tune the Digest draft to introduce the header > field in a more generic way, allowing other schemes to use it as well. That > would avoid a dependency to a yet unwritten spec, but the complexity > wouldn't really change. > > 3) We can tell Alexey to pick a different field name, which would shift all > required changes to the SCRAM spec. > > Feedback appreciated, > > Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Sat Dec 6 00:08:07 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1FA1A86EE for ; Sat, 6 Dec 2014 00:08:04 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEFgcV80aDXd for ; Sat, 6 Dec 2014 00:08:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283AF1A87DE for ; Sat, 6 Dec 2014 00:08:02 -0800 (PST) Received: from [192.168.2.160] ([84.187.42.179]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MUZKF-1YNKF52rdj-00RIkc; Sat, 06 Dec 2014 09:07:59 +0100 Message-ID: <5482B951.7000007@gmx.de> Date: Sat, 06 Dec 2014 09:07:45 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <547DB5D1.5040909@gmx.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:oGTOYAcVg0b2qzu/bAYPgE0IutX68lK0tSzUnjpKO3iFwX6Fq1z 3cr3tE/rEUZdsobc5vevg3ZrrRDY0pIZtdXzlbcbh/a0BbbHbsBis2pt670OtawyT3gS07b DmvfJVGelEXfmbBxzevIuByCRldpKa2NFGRVcYfeiFA0Zkvj1oTzWsiJ3LfJ1rk4714RApW gBb6nmJU3dkB1meW8aJSw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/cLzCfnKLOGdomifWflrIhM0ofK0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Authentication-Info X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 08:08:04 -0000 On 2014-12-06 01:53, Rifaat Shekh-Yusef wrote: > Hi Julian, > > The Digest draft based the definition of the Authentication-Info header > on the auth-param defined in RFC7235, and it registers the header with > the Message Header Field Registry. > > What else do you think we need to do to make it generic? > > Regards, > Rifaat The only remaining thing to do would be to clarify that this header field can be used in other auth schemes as well, and to de-couple the generic description completely from the Digest-specific aspects... Best regards, Julian From nobody Sat Dec 6 05:47:03 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45CA1A037C for ; Sat, 6 Dec 2014 05:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNCBjHRh7fqS for ; Sat, 6 Dec 2014 05:47:00 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19ED11A0248 for ; Sat, 6 Dec 2014 05:47:00 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id n15so1880105lbi.30 for ; Sat, 06 Dec 2014 05:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nosIFRIEZJgwBjnsIBMC27Nhis/e3MjNs1Ujrn+eH4Q=; b=PKWSNj+PS6nLYg8ExVsoNHcEqThkkwCYEVeFzywJgzgk3j6yJUVvw8Raxr7Wzgm6wG fAZ4AWYOs5cUHIXIZkwnOGRcxbV6/AUPkuIs5BFZGDkI/VYP+C9PkS8eD4KHRVpgbEnL l3py0MKPsJ4YQh57uOUTEq8taghoNDONm8Dh18tGnBmBAkZ7/NVxpox5lHL9HVtPbNXh IBJG1PeF+HjNWJuR2Wx76BEFaJsWhV9fkoERQkTdAlZIsGI6BtaaaNbewQ98TlE5cQGi py53N+sPWB6UXVq03Uq3/V8B8wLRpFcR64SyBfu83KwZ+/Ip837kotlc7y1zCoGoNWkZ f4vA== MIME-Version: 1.0 X-Received: by 10.152.120.167 with SMTP id ld7mr7486526lab.77.1417873618606; Sat, 06 Dec 2014 05:46:58 -0800 (PST) Received: by 10.114.99.36 with HTTP; Sat, 6 Dec 2014 05:46:58 -0800 (PST) In-Reply-To: <5482B951.7000007@gmx.de> References: <547DB5D1.5040909@gmx.de> <5482B951.7000007@gmx.de> Date: Sat, 6 Dec 2014 08:46:58 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=089e012290f25fa1e005098c6d91 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/TED12A9ThzIoNvH-KJaGmUsyo0w Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Authentication-Info X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 13:47:01 -0000 --089e012290f25fa1e005098c6d91 Content-Type: text/plain; charset=ISO-8859-1 This is a simple change, and much easier than option 1. I will make the change in the next version of the document along with the WGLC changes. Regards, Rifaat On Sat, Dec 6, 2014 at 3:07 AM, Julian Reschke wrote: > On 2014-12-06 01:53, Rifaat Shekh-Yusef wrote: > >> Hi Julian, >> >> The Digest draft based the definition of the Authentication-Info header >> on the auth-param defined in RFC7235, and it registers the header with >> the Message Header Field Registry. >> >> What else do you think we need to do to make it generic? >> >> Regards, >> Rifaat >> > > The only remaining thing to do would be to clarify that this header field > can be used in other auth schemes as well, and to de-couple the generic > description completely from the Digest-specific aspects... > > Best regards, Julian > > --089e012290f25fa1e005098c6d91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is a simple change, and much easier than option 1.I will make the change in the next version of the document along with the= WGLC changes.

Regards,
=A0Rifaat


On Sat, Dec 6, 2014 at 3:07 AM, Julian Reschke <jul= ian.reschke@gmx.de> wrote:
= On 2014-12-06 01:53, Rifaat Shekh-Yusef wrote:
Hi Julian,

The Digest draft based the definition of the Authentication-Info header
on the auth-param defined in RFC7235, and it registers the header with
the Message Header Field Registry.

What else do you think we need to do to make it generic?

Regards,
=A0 Rifaat

 The only remaining thing to do would be to clarify that this header field c= an be used in other auth schemes as well, and to de-couple the generic desc= ription completely from the Digest-specific aspects...

Best regards, Julian


--089e012290f25fa1e005098c6d91-- From nobody Sat Dec 6 06:33:06 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3863F1A0363 for ; Sat, 6 Dec 2014 06:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Atpsxhsc07Vm for ; Sat, 6 Dec 2014 06:33:02 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDE61A0354 for ; Sat, 6 Dec 2014 06:33:02 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so317524lbg.33 for ; Sat, 06 Dec 2014 06:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tMpMsv+gsAFZwvPbxrNbHGzbjFe23CJ8/DBaefSOZxM=; b=SVm5zU20CcsyHTIpIbirnIfdweJx+xUd/+YYQr4pGw+e4Cr0bXbV/RpMbsSuyZ3o4P 6Pgk2ToPPBk3b4YpJ73uxmqI3FO8R3t3ubltN9+yunKWOMqyVS2uCSgt5RK7RUpDPA7O kcR8XYKF8/Ix6JzC5uspujwyr/iBfOFc+L4izzdRiwaeYjfMcUCp0ClHQyeQlcaNNHUX F/7QKKKT3xsAwZgsH4liOlMI6rdO1vUy5P9IbLI6znORpC8sOHXOYHrnHxz3u3Bqio+0 dQ/mgCXMRzqeIBM1OHgP93M4l7U1QbqBAx5UvPaDQZIf+7hbnGbLbpjXszcgeueQCqxl Xmjw== MIME-Version: 1.0 X-Received: by 10.112.157.194 with SMTP id wo2mr7740249lbb.55.1417876380818; Sat, 06 Dec 2014 06:33:00 -0800 (PST) Received: by 10.114.99.36 with HTTP; Sat, 6 Dec 2014 06:33:00 -0800 (PST) In-Reply-To: References: Date: Sat, 6 Dec 2014 09:33:00 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Matthew Lepinski Content-Type: multipart/alternative; boundary=001a11c33f5e03a47205098d1280 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/ZFgAsrEv2r9UOh8Hrog_FG0H3OU Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Draft Minutes for IETF 91 HTTP-Auth Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 14:33:04 -0000 --001a11c33f5e03a47205098d1280 Content-Type: text/plain; charset=ISO-8859-1 Alexey, Did you have a chance to look into the following action? -- CNounce issue Alexey: We can recommend that it contains some number of bits of entropy and cite RFC Alexey will come up with text Thanks, Rifaat On Fri, Dec 5, 2014 at 1:49 PM, Matthew Lepinski wrote: > Draft minutes have been posted for the HTTP-Auth session at IETF 91. > > http://www.ietf.org/proceedings/91/minutes/minutes-91-httpauth > > If you have any comments/corrections for the minutes, please let us know. > > Thanks, > - Matt and Yoav > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > --001a11c33f5e03a47205098d1280 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Alexey,

Did you have a chance to look i= nto the following action?

-- CNounce issue

   Alexey: We can recommend that it contains some number of bits of entropy=
 and cite RFC
          Alexey will come up with text

Than= ks,
=A0Rifaat



<= div>

On Fri, Dec 5, 2014 at 1:49 PM, Matthew Lepinski <<= a href=3D"mailto:mlepinski.ietf@gmail.com" target=3D"_blank">mlepinski.ietf= @gmail.com> wrote:
Draft minutes have been posted for the HTTP-Auth session at IETF 9= 1.


If you have an= y comments/corrections for the minutes, please let us know.

<= /div>
Thanks,
- Matt and Yoav

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth


--001a11c33f5e03a47205098d1280-- From nobody Sun Dec 7 17:27:01 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459841A1B1F for ; Sun, 7 Dec 2014 17:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pONvy4TwyaaB for ; Sun, 7 Dec 2014 17:26:57 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8AF1A01C6 for ; Sun, 7 Dec 2014 17:26:57 -0800 (PST) Received: by mail-yk0-f175.google.com with SMTP id 200so1834479ykr.34 for ; Sun, 07 Dec 2014 17:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3CDTOQ578pg6XNFkjwUHKmCzwNvusBXG8IOGE+UXGOQ=; b=kzq9heCrLdLfpA4zvRn/jSHC5fZpntj72qo3np5I/bpTXXhJk2+vJLhSTp4htXaV+2 cpYj0bXVDcnrcueb9FegHaOqUU7SDHMd+biQTqt2HgZ0aKNz3gpkzVy5ZZqvf/XpmJ4U YUu3Z0kTubrkX6JHPICf03iwr1i9kIYYoeyK+9QD2rIeKaresXsD1QAxmoJ4qT62liZb mqTcKtcbO3/E3yyhhqHjDXsQRG/pWal9HTlOmukgRX+vvvkJBfuSN86kSywB/dcXXlrt W8FT3XOdfNo07fmYNtPVw2eTGflnCOjwqi1SZ5/2OTmrF9aiaKN+MfupEbqIpXOnxOz4 gJHA== MIME-Version: 1.0 X-Received: by 10.236.7.52 with SMTP id 40mr28351512yho.172.1418002016268; Sun, 07 Dec 2014 17:26:56 -0800 (PST) Received: by 10.170.195.21 with HTTP; Sun, 7 Dec 2014 17:26:56 -0800 (PST) Date: Sun, 7 Dec 2014 17:26:56 -0800 Message-ID: From: Watson Ladd To: http-auth@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/QEF8V9TIOEeIwVByZxDuOGo_67Y Subject: [http-auth] Concatenation is not injective X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 01:27:00 -0000 Dear all, HOBA computes a string which is signed by concatenating nonce+origin+alg+kid+challenge, where nonce is picked by the UA, and challenge by the server. Suppose we were to change this slightly by reversing the challenge and the nonce. The resulting protocol would be entirely insecure, as shown by the following, with S the server, M the attacker, and B the client. S->M sign "dog"+S M->B sign "dogS"+M B->M I signed "dogS"+M+"once" M->B I signed "dog"+S+"Monce" Is an attack like this possible on the current version? It depends on the details of the encoding, but I think so: the intermediary makes the challenge contain the entire origin+alg+kid+challenge received from the server, and uses it as a nonce. Encoding may make this impossible, but it's much easier to use an injective map from a sequence of strings to a single string to eliminate this problem entirely. Sincerely, Watson Ladd From nobody Sun Dec 7 18:32:46 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1373C1A1A7D for ; Sun, 7 Dec 2014 18:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaVjGQAfW3az for ; Sun, 7 Dec 2014 18:32:43 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5591A1B48 for ; Sun, 7 Dec 2014 18:32:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B67B2BED1; Mon, 8 Dec 2014 02:32:39 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95MnWrOAyWAr; Mon, 8 Dec 2014 02:32:38 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.46.17.214]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6DDA0BEDB; Mon, 8 Dec 2014 02:32:35 +0000 (GMT) Message-ID: <54850DBA.4060209@cs.tcd.ie> Date: Mon, 08 Dec 2014 02:32:26 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Watson Ladd , http-auth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/mkm_xku5jxcjsfLfHrSPJgvRMRA Subject: Re: [http-auth] Concatenation is not injective X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 02:32:45 -0000 Hi Watson, First, thanks. I'm very glad we're getting more scrutiny. Esp when its comes with more crypto clue than I have. On 08/12/14 01:26, Watson Ladd wrote: > Dear all, > > HOBA computes a string which is signed by concatenating > nonce+origin+alg+kid+challenge, Terminology-wise the above catenation is called HOBA-TBS in the spec. (that's mentioned below). And we're ignoring the optional realm input which is ok for this discussion I think. > where nonce is picked by the UA, and > challenge by the server. Suppose we were to change this slightly by > reversing the challenge and the nonce. The resulting protocol would be > entirely insecure, as shown by the following, with S the server, M the > attacker, and B the client. > > S->M sign "dog"+S > M->B sign "dogS"+M > B->M I signed "dogS"+M+"once" > M->B I signed "dog"+S+"Monce" > > Is an attack like this possible on the current version? It depends on > the details of the encoding, but I think so: the intermediary makes > the challenge contain the entire origin+alg+kid+challenge received > from the server, and uses it as a nonce. Encoding may make this > impossible, but it's much easier to use an injective map from a > sequence of strings to a single string to eliminate this problem > entirely. Let me first check if I'm getting the vulnerability and then check if I'm understanding the suggested solution. Then I'll say what I think is a plan. So the vulnerability doesn't apply to HOBA as specified but rather to another protocol (call it "not-quite-HOBA") that is almost like HOBA but where the nonce and challenge inputs to signing are swapped in the encoding. Is that what you mean? The concern is that given such a vulnerability exists in not-quite-HOBA, there could be some as-yet-unknown vulnerability in HOBA as-specified that we might eliminate if we also eliminate the vulnerability in not-quite-HOBA. Is that also right? And your solution is to use f(HOBA-TBS) as input to signing instead of HOBA-TBS, where f is some injective map. And maybe where the inputs to f() aren't just the catenated values, but each value as a separate input, so more like f(nonce,origin,alg,kid,challenge) and not simply this: f(nonce+origin+alg+kid+challenge). Well, first, isn't f() = identity injective too? If so, then I'm not sure what we're gaining really. And f() = sha256 or any other well known cryptographic hash is not injective I think, so I'm not sure what f() you'd suggest that's different from the current encoding/ordering. (And where that f() has been used in some standard somewhere and is not such a novelty - I far prefer lack of novelty in stuff like HOBA to be honest:-) I guess we could have f() as "prepend length of the overall, then hash" but I'm not sure even that would be injective, nor am I sure it'd offer any benefit compared to the current protocol that also doesn't suffer the same problem posited for not-quite-HOBA. That is, such an f() wouldn't help at all I think. But maybe there is an f() that would be an improvement. Absent a really better f(), I think noting the vulnerability in not-quite-HOBA is worthwhile and can do that - I recall thinking about this some time ago, (*) and given that HOBA is aiming for experimental status it's possible that it might be revised in future so it'd be good to note this potential (but not actual) vulnerability in that not-quite-HOBA protocol. Or, maybe you can suggest an f() that'd be a real improvement on the current protocol? Or can we agree that just noting the vulnerability in not-quite-HOBA is sufficient in this case? Cheers, S. (*) I guess it's a good rule-of-thumb in protocol design to provide the more local/trustworthy/more-quickly-changing stuff first as input to any hashing. And in saying that I do get that you don't like such rules of thumb and you're probably correct in general:-) > > Sincerely, > Watson Ladd > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From nobody Sun Dec 7 20:28:45 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B921A1EF4 for ; Sun, 7 Dec 2014 20:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiWdc4cm9uqk for ; Sun, 7 Dec 2014 20:28:41 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E961A1EF3 for ; Sun, 7 Dec 2014 20:28:41 -0800 (PST) Received: by mail-yk0-f175.google.com with SMTP id 200so1919803ykr.34 for ; Sun, 07 Dec 2014 20:28:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IUrnjTScVENHcgt4rVWNoiUVLeh71U0v5joJSuxNoUQ=; b=cjBeNzhfMkLuksenlN//3FDSxqU73icdlWjNdlwDXfqa8aYBKxnsJV4oj4LYOVNhqn Opktcm/+tHoMoLgiwuCvpioezlkbu/LzzTSNatbnhP4sDx4ORPNH80Idd4Nt8ju3+wmO mi9eiDeDk9BP2zAUjsMfCIT+/u9Hrq52VmqUPuKSR68vG4pbRLXmZ1QIONArLVSDsqtW i2dLUsPij4uTT+7yCU3CE4Xq9V4pPxZFh3UDaj2zJXAw4wLXlqG7E+sN+Wdm25YudN+T NyRQW1eerpeakiNi+FOIiKd731uYtmGzxp2QcfGzI0FvPF05HL1+PsZ+gztL7oX8gS2T rN6A== MIME-Version: 1.0 X-Received: by 10.170.111.210 with SMTP id d201mr32667561ykb.126.1418012920654; Sun, 07 Dec 2014 20:28:40 -0800 (PST) Received: by 10.170.195.21 with HTTP; Sun, 7 Dec 2014 20:28:40 -0800 (PST) In-Reply-To: <54850DBA.4060209@cs.tcd.ie> References: <54850DBA.4060209@cs.tcd.ie> Date: Sun, 7 Dec 2014 20:28:40 -0800 Message-ID: From: Watson Ladd To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/WDWKYoCZ3DM2Is33o-RWjnUlaxU Cc: http-auth@ietf.org Subject: Re: [http-auth] Concatenation is not injective X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 04:28:43 -0000 On Sun, Dec 7, 2014 at 6:32 PM, Stephen Farrell wrote: > > Hi Watson, > > First, thanks. I'm very glad we're getting more scrutiny. > Esp when its comes with more crypto clue than I have. > > On 08/12/14 01:26, Watson Ladd wrote: >> Dear all, >> >> HOBA computes a string which is signed by concatenating >> nonce+origin+alg+kid+challenge, > > Terminology-wise the above catenation is called HOBA-TBS in > the spec. (that's mentioned below). And we're ignoring the > optional realm input which is ok for this discussion I think. > >> where nonce is picked by the UA, and >> challenge by the server. Suppose we were to change this slightly by >> reversing the challenge and the nonce. The resulting protocol would be >> entirely insecure, as shown by the following, with S the server, M the >> attacker, and B the client. >> >> S->M sign "dog"+S >> M->B sign "dogS"+M >> B->M I signed "dogS"+M+"once" >> M->B I signed "dog"+S+"Monce" >> >> Is an attack like this possible on the current version? It depends on >> the details of the encoding, but I think so: the intermediary makes >> the challenge contain the entire origin+alg+kid+challenge received >> from the server, and uses it as a nonce. Encoding may make this >> impossible, but it's much easier to use an injective map from a >> sequence of strings to a single string to eliminate this problem >> entirely. > > Let me first check if I'm getting the vulnerability and then > check if I'm understanding the suggested solution. Then I'll > say what I think is a plan. > > So the vulnerability doesn't apply to HOBA as specified but > rather to another protocol (call it "not-quite-HOBA") that > is almost like HOBA but where the nonce and challenge inputs > to signing are swapped in the encoding. Is that what you mean? So when I first wrote the email and the example, I thought HOBA would be safe because of the order. Then I realized that doesn't matter, midway through. If HOBA is not vulnerable, it's because of a detail in the possible types of arguments, and not because it's a generically secure mechanism that doesn't care about the format of the strings used. It's possible that implementations will be vulnerable because they concatenate the nonce without checking its format for instance, even if the protocol might be implementable securely. > > The concern is that given such a vulnerability exists in > not-quite-HOBA, there could be some as-yet-unknown vulnerability > in HOBA as-specified that we might eliminate if we also eliminate > the vulnerability in not-quite-HOBA. Is that also right? > > And your solution is to use f(HOBA-TBS) as input to signing > instead of HOBA-TBS, where f is some injective map. And > maybe where the inputs to f() aren't just the catenated > values, but each value as a separate input, so more like > f(nonce,origin,alg,kid,challenge) and not simply this: > f(nonce+origin+alg+kid+challenge). > > Well, first, isn't f() = identity injective too? If so, then > I'm not sure what we're gaining really. And f() = sha256 or > any other well known cryptographic hash is not injective > I think, so I'm not sure what f() you'd suggest that's > different from the current encoding/ordering. (And where > that f() has been used in some standard somewhere and is > not such a novelty - I far prefer lack of novelty in stuff > like HOBA to be honest:-) Signature algorithms take strings, not tuples of strings. f is not, and cannot, be the identity, but concatenation, which is not injective: "CA"+"TMAN"="CAT"+"MAN". That's what it is in the current draft, and the result is most likely a vulnerability. Almost certainly someone will implement this draft without checking the nonce for well-formedness, in which case there is *definitely* going to be a problem. > > I guess we could have f() as "prepend length of the > overall, then hash" but I'm not sure even that would be > injective, nor am I sure it'd offer any benefit compared > to the current protocol that also doesn't suffer the same > problem posited for not-quite-HOBA. That is, such an f() > wouldn't help at all I think. > > But maybe there is an f() that would be an improvement. There is: Pick an injective function from sequences of strings to strings. For instance one can take f([]) = "" | f([x:xs])=len(x)+":"+x+f(xs) where len(x) is the base-10, ASCII representation of the length of x. This is an injective function from sequences of strings to strings. With this, in the analysis you don't need to worry about what the tuple being input looks like, as you will never have a collision. This is similar to the use of lengths of the message and associated data in AEAD modes. > > Absent a really better f(), I think noting the vulnerability > in not-quite-HOBA is worthwhile and can do that - I recall > thinking about this some time ago, (*) and given that HOBA is > aiming for experimental status it's possible that it might > be revised in future so it'd be good to note this potential > (but not actual) vulnerability in that not-quite-HOBA > protocol. > > Or, maybe you can suggest an f() that'd be a real improvement > on the current protocol? Or can we agree that just noting the > vulnerability in not-quite-HOBA is sufficient in this case? > > Cheers, > S. > > (*) I guess it's a good rule-of-thumb in protocol design to > provide the more local/trustworthy/more-quickly-changing > stuff first as input to any hashing. And in saying that I > do get that you don't like such rules of thumb and you're > probably correct in general:-) You can do that, and make sure the encoding is injective at the same time. Sincerely, Watson Ladd > > >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> >> -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Dec 8 01:53:54 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E631A89F0 for ; Mon, 8 Dec 2014 01:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-IYaWh3_PUm for ; Mon, 8 Dec 2014 01:53:50 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id AD4011A89EF for ; Mon, 8 Dec 2014 01:53:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 616E6BED1; Mon, 8 Dec 2014 09:53:49 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGB_BLnusRwr; Mon, 8 Dec 2014 09:53:49 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 420AABECF; Mon, 8 Dec 2014 09:53:49 +0000 (GMT) Message-ID: <5485752D.5070304@cs.tcd.ie> Date: Mon, 08 Dec 2014 09:53:49 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Watson Ladd References: <54850DBA.4060209@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/HS4sZXXIjpvaDTzmUmogMUjUkZc Cc: http-auth@ietf.org Subject: Re: [http-auth] Concatenation is not injective X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 09:53:52 -0000 Hiya, On 08/12/14 04:28, Watson Ladd wrote: >> > But maybe there is an f() that would be an improvement. > There is: Pick an injective function from sequences of strings to > strings. For instance one can take > f([]) = "" > | f([x:xs])=len(x)+":"+x+f(xs) > > where len(x) is the base-10, ASCII representation of the length of x. > This is an injective function from sequences of strings to strings. > > With this, in the analysis you don't need to worry about what the > tuple being input looks like, as you will never have a collision. This > is similar to the use of lengths of the message and associated data in > AEAD modes. > Yeah, I kinda like that I have to say. Even if there's no real attack against HOBA as-is, doing that seems like a good plan in case the HOBA signature scheme/code ever gets re-used elsewhere, and to make the analysis easier. Let me go check stuff and get back but I'm warming to this idea. S. From nobody Mon Dec 8 05:34:58 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D7C1A8A6F for ; Mon, 8 Dec 2014 05:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPMuoHJx_Is1 for ; Mon, 8 Dec 2014 05:34:47 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A7F1A8A6D for ; Mon, 8 Dec 2014 05:34:47 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so4000952lab.9 for ; Mon, 08 Dec 2014 05:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YyXExK6oWoQSBDIO/hueC7YuHF7i7xPALiFBEfGDqtM=; b=Igwa8iyYTI/cVODa9NFj3wALn1wSd20nXqBiFuhNcqWxNdNejHknvRYLKLO6y3+UsY 4FmARB3gmNFwPg5FikT0zBXFekivN9TIAeSLW/y/q6EkYbJjAtv6ZTR1KyrIDqA374mi 0eGWQehjm+w9D/2RRjWWCwqkGUKlJZ50xFfJP1XZ9hc5YfgesdV8kSlKm2Wk1xL1HSi6 kaXcSag8hf/TmBmmMQZwwImBdjl2LbpmOW6rfHzwqsFCCTApfl6OWo67PQJ4ZU7vXYT9 Rne+BxvPVFNKcw3okAoHK6dhxK8wasg1y4UQlJDIdzab8iRZtMj2ZsARRKvevQ7nc+5R NhFA== MIME-Version: 1.0 X-Received: by 10.152.120.167 with SMTP id ld7mr16075895lab.77.1418045685612; Mon, 08 Dec 2014 05:34:45 -0800 (PST) Received: by 10.114.99.36 with HTTP; Mon, 8 Dec 2014 05:34:45 -0800 (PST) In-Reply-To: <547BA70D.8060208@andyet.net> References: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> <547B99AC.4060109@gmx.de> <547B9AE0.4030301@andyet.net> <547BA19B.7010707@gmx.de> <547BA70D.8060208@andyet.net> Date: Mon, 8 Dec 2014 08:34:45 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "Peter Saint-Andre - &yet" Content-Type: multipart/alternative; boundary=089e012290f25dc87d0509b47da3 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/3b56X8enOQ6aY2MAZT8np7sQqBg Cc: Julian Reschke , IETF HTTP Auth Subject: Re: [http-auth] Allowed Characters in usernames and passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 13:34:54 -0000 --089e012290f25dc87d0509b47da3 Content-Type: text/plain; charset=ISO-8859-1 Thanks Julian, I will use the same text with the Digest document. Regards, Rifaat On Sun, Nov 30, 2014 at 6:23 PM, Peter Saint-Andre - &yet wrote: > On 11/30/14, 4:00 PM, Julian Reschke wrote: > >> On 2014-11-30 23:32, Peter Saint-Andre - &yet wrote: >> >>> On 11/30/14, 3:26 PM, Julian Reschke wrote: >>> >>>> On 2014-11-25 21:08, Yoav Nir wrote: >>>> >>>>> >>>>> On Nov 25, 2014, at 10:02 PM, Nico Williams >>>>>> wrote: >>>>>> >>>>>> On Tue, Nov 25, 2014 at 1:56 PM, Yoav Nir >>>>>> wrote: >>>>>> >>>>>>> To re-summarize, the proposal was that servers MUST support >>>>>>> usernames and passwords compliant with saslprepbis, and MAY support >>>>>>> non-compliant characters (except for specialized requirements such >>>>>>> as those around colon). >>>>>>> >>>>>> >>>>>> What does this mean? That the client MAY/SHOULD/MUST prep the thing? >>>>>> How would the server know if the thing is prep'ed with saslprepbis (if >>>>>> not by applying the prep itself)? What would it mean for the server >>>>>> to not "support usernames and passwords compliant with saslprepbis"? >>>>>> >>>>> >>>>> The discussion was about the profiles for usernames and passwords in >>>>> sections 3.2 and 4.2 respectively of >>>>> https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-10 . >>>>> >>>> >>>> In draft-11, there's a choice of "UsernameCaseMapped" and >>>> "UsernameCasePreserved" >>>> >>> >>> Yes, I added the options so that we'd all have definitive options (and >>> so that UsernameCaseMapped wasn't defined in an XMPP specification). >>> >>> - I assume we'll choose the latter... >>>> >>> >>> Probably. >>> >>> Peter >>> >> >> OK, for now I have this change >> - note >> that it only applies for the case where the server has advertised UTF-8 >> support using the charset parameter. >> > > Yes, I had always assumed so. > > Are we ok with this -- that is, can I submit a new draft and declare >> victory? >> > > I think so. [1] > > Thanks for your patience and persistence! > > Peter > > [1] It is possible that we might try to consolidate or harmonize some of > the profiles of the PRECIS FreeformClass, as we have done for profiles of > the IdentifierClass. However, I expect that won't change the substance of > the Password profile. > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --089e012290f25dc87d0509b47da3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Julian,

I will use the sam= e text with the Digest document.

Regards,
&nbs= p;Rifaat

On Sun, Nov 30, 2014 at 6:23 PM, Peter Saint-Andre - &yet <peter@an= dyet.net> wrote:
On 11/30/14, 4:00 PM, Julian Reschke wrote:=
On 2014-11-30 23:32, Peter Saint-Andre - &yet wrote:
On 11/30/14, 3:26 PM, Julian Reschke wrote:
On 2014-11-25 21:08, Yoav Nir wrote:

On Nov 25, 2014, at 10:02 PM, Nico Williams <nico@cryptonector.com>
wrote:

On Tue, Nov 25, 2014 at 1:56 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
To re-summarize, the proposal was that servers MUST support
usernames and passwords compliant with saslprepbis, and MAY support
non-compliant characters (except for specialized requirements such
as those around colon).

What does this mean?  That the client MAY/SHOULD/MUST prep the thing?<= br> How would the server know if the thing is prep'ed with saslprepbis (if<= br> not by applying the prep itself)?  What would it mean for the server to not "support usernames and passwords compliant with saslprepbis&rdq= uo;?

The discussion was about the profiles for usernames and passwords in
sections 3.2 and 4.2 respectively of
https://tools.ietf.org/html/draft-ietf-precis-saslpr= epbis-10 .

In draft-11, there's a choice of "UsernameCaseMapped" and
"UsernameCasePreserved"

Yes, I added the options so that we'd all have definitive options (and<= br> so that UsernameCaseMapped wasn't defined in an XMPP specification).
- I assume we'll choose the latter...

Probably.

Peter

OK, for now I have this change
<http://trac.tools.ietf.org/wg/httpauth/trac/ch= angeset/83#file1> - note
that it only applies for the case where the server has advertised UTF-8
support using the charset parameter.

Yes, I had always assumed so.

Are we ok with this -- that is, can I submit a new draft and declare
victory?

 I think so. [1]

Thanks for your patience and persistence!

Peter

[1] It is possible that we might try to consolidate or harmonize some of th= e profiles of the PRECIS FreeformClass, as we have done for profiles of the= IdentifierClass. However, I expect that won't change the substance of = the Password profile.


_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth

--089e012290f25dc87d0509b47da3-- From nobody Mon Dec 8 05:39:39 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0011A8A92 for ; Mon, 8 Dec 2014 05:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ3nc6gXUf2K for ; Mon, 8 Dec 2014 05:39:36 -0800 (PST) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5371A8A8F for ; Mon, 8 Dec 2014 05:39:36 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so2753107igb.5 for ; Mon, 08 Dec 2014 05:39:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RAo/bQPgecVBJRr5wr4+cHeGWyp3C3zQttRbSAb7Nk0=; b=AHplrzcOQbSwVOQ+aItYpN4OBpmS+/PiD4i5cYM5EEPYRaV//GSLOiLjeXcGkSKo3C oRljT8K1KvAayTl/ie4VdgJ3v1we7NaghI8Y++0vJ1wZaTOdmOPoZOto51CB0EyTij2Y Kb9pZS28kx83hgOWRnB2U3EEqlKRp+mPdX0uOz3QjoEVQDiY7/cLxeGlO4jWH2E4Fzkr //pHLz0BBsUOG9HbOPysFBxFO/HznwiJ6Z+Tdawj17j0mb0Ndw+i0do5IkB6eQh70I4O k9hb0deGQR0zTrD9nQUls5yc04zsi4i8GMkZM/Mxb4BHjJRe+f/RzCpE/KlY5D27BWRa oKxg== X-Gm-Message-State: ALoCoQlPjiwhrsQRLObvmWqpJ9wE9oKwR7lJwmCQf4+6u6BVyJ/d22fUmb2EH0npX1qNn4nbzvjk X-Received: by 10.50.40.8 with SMTP id t8mr14762205igk.0.1418045975500; Mon, 08 Dec 2014 05:39:35 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id qc7sm3837245igb.5.2014.12.08.05.39.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 05:39:34 -0800 (PST) Message-ID: <5485AA10.1000904@andyet.net> Date: Mon, 08 Dec 2014 06:39:28 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> <547B99AC.4060109@gmx.de> <547B9AE0.4030301@andyet.net> <547BA19B.7010707@gmx.de> <547BA70D.8060208@andyet.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/uV0uHOX2U68f8BNaynuoLgs3Uk0 Cc: Julian Reschke , IETF HTTP Auth Subject: Re: [http-auth] Allowed Characters in usernames and passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 13:39:37 -0000 On 12/8/14, 6:34 AM, Rifaat Shekh-Yusef wrote: > Thanks Julian, > > I will use the same text with the Digest document. Note that in draft-ietf-saslprepbis we changed the name of the profile from "Password" to "OpaqueString" to encourage broader re-use. The profile itself did not change at all. Peter From nobody Mon Dec 8 05:41:25 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEE41A8A85 for ; Mon, 8 Dec 2014 05:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKvvjK3rqZS0 for ; Mon, 8 Dec 2014 05:41:19 -0800 (PST) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C3D1A8A91 for ; Mon, 8 Dec 2014 05:41:16 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so2738428igb.17 for ; Mon, 08 Dec 2014 05:41:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NkK+HOS8M7ngg8OLr6WFeWL+CENSsegRn71BCY2aztA=; b=XOjHsS2k3yKHUDWxFGmR89pE0trCAPMuSkmlPAHQ6WnmIdbw9TWvaRjhNSVL3XZBiW FBN3mHd1S/zUfsJSsVktls/xQCojTpaUWm9jN5zoNAb081UFSx0MpedmPSdFHmq06qPP m0cbH4XHYdpeiwR8VAM9n46qnsWzTxpZBMkeaFbTi9qyX0lVf0bPU6Wh/vWkoAGlRh9G El9fzP+mSyQwntlkhWa5tmgfZL9LT+uedGGC1jd4+CPgvKz0fMLTCNap0FdBP1su4CKN cKNFS/eR/RY9xAnu6Gra0WQiKC64LFAHZdU5VxBkf+oy0AQAsbOmL9+5igmGEJnyvWPk FKzA== X-Gm-Message-State: ALoCoQlNnHsSa7QvgHpDq/+xyTc7fCRb0EV+Neyf9nVC9rJGnJ61IwGKv7e6+IqbsMtw0foQr4se X-Received: by 10.107.11.88 with SMTP id v85mr10723026ioi.46.1418046076297; Mon, 08 Dec 2014 05:41:16 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id vf6sm3839415igb.6.2014.12.08.05.41.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 05:41:15 -0800 (PST) Message-ID: <5485AA72.6060902@andyet.net> Date: Mon, 08 Dec 2014 06:41:06 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> <547B99AC.4060109@gmx.de> <547B9AE0.4030301@andyet.net> <547BA19B.7010707@gmx.de> <547BA70D.8060208@andyet.net> <5485AA10.1000904@andyet.net> In-Reply-To: <5485AA10.1000904@andyet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/cX2M9pUU7CM3ScexBata0o5OZxE Cc: Julian Reschke , IETF HTTP Auth Subject: Re: [http-auth] Allowed Characters in usernames and passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 13:41:22 -0000 On 12/8/14, 6:39 AM, Peter Saint-Andre - &yet wrote: > On 12/8/14, 6:34 AM, Rifaat Shekh-Yusef wrote: >> Thanks Julian, >> >> I will use the same text with the Digest document. > > Note that in draft-ietf-saslprepbis Er, draft-ietf-precis-saslprepbis, that is. > we changed the name of the profile > from "Password" to "OpaqueString" to encourage broader re-use. The > profile itself did not change at all. From nobody Mon Dec 8 05:58:14 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417E61A8AC3 for ; Mon, 8 Dec 2014 05:58:10 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECcBOzmMKtEZ for ; Mon, 8 Dec 2014 05:58:08 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE501A8AC4 for ; Mon, 8 Dec 2014 05:58:08 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M92lh-1Y7Yf83Dw5-00CSg6; Mon, 08 Dec 2014 14:58:03 +0100 Message-ID: <5485AE66.3050602@gmx.de> Date: Mon, 08 Dec 2014 14:57:58 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , Rifaat Shekh-Yusef References: <6355C77E-EEF9-4054-92A1-30C36F9BF2AC@gmail.com> <547B99AC.4060109@gmx.de> <547B9AE0.4030301@andyet.net> <547BA19B.7010707@gmx.de> <547BA70D.8060208@andyet.net> <5485AA10.1000904@andyet.net> In-Reply-To: <5485AA10.1000904@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:R6pOk1fhIggyr7GxEwhj7FBmA8azBobJodeHc6yA0SZCyjTM2G1 6lQWjH407NuY4wMpTu4aU/v7q5EP+oN3qfC+GbohO30jYf4CnRHQL+mX3UNhtNcK+/vs2Q8 KbC1sWlu/0eqcod62R1AM/HnLGryHxMvcxdSFo+JV2utMZA82lib2wfR3yIUEZ5Hc8Pzcy0 dW1aCNQXQvy99JPOuCAGQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/iHLorljX17YxBeBQLGDPrPewCI0 Cc: IETF HTTP Auth Subject: Re: [http-auth] Allowed Characters in usernames and passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 13:58:10 -0000 On 2014-12-08 14:39, Peter Saint-Andre - &yet wrote: > On 12/8/14, 6:34 AM, Rifaat Shekh-Yusef wrote: >> Thanks Julian, >> >> I will use the same text with the Digest document. > > Note that in draft-ietf-saslprepbis we changed the name of the profile > from "Password" to "OpaqueString" to encourage broader re-use. The > profile itself did not change at all. > > Peter I changed that in my current edits: Best regards, Julian From nobody Mon Dec 8 06:07:52 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C2A1A9027 for ; Mon, 8 Dec 2014 06:07:51 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmRgBkOMp2MH for ; Mon, 8 Dec 2014 06:07:47 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681C81A9029 for ; Mon, 8 Dec 2014 06:07:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 754BCE2036; Mon, 8 Dec 2014 09:07:45 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 23897-03; Mon, 8 Dec 2014 09:07:43 -0500 (EST) Received: from securerf.ihtfp.org (c-50-189-135-154.hsd1.ct.comcast.net [50.189.135.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 9D6AAE2035; Mon, 8 Dec 2014 09:07:42 -0500 (EST) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id sB8E7cdf022697; Mon, 8 Dec 2014 09:07:38 -0500 From: Derek Atkins To: Stephen Farrell References: <54850DBA.4060209@cs.tcd.ie> <5485752D.5070304@cs.tcd.ie> Date: Mon, 08 Dec 2014 09:07:38 -0500 In-Reply-To: <5485752D.5070304@cs.tcd.ie> (Stephen Farrell's message of "Mon, 08 Dec 2014 09:53:49 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/I5v9FDzrhkxEpBRdJdzTlLZrFbY Cc: http-auth@ietf.org Subject: Re: [http-auth] Concatenation is not injective X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 14:07:51 -0000 Stephen Farrell writes: > Hiya, > > On 08/12/14 04:28, Watson Ladd wrote: >>> > But maybe there is an f() that would be an improvement. >> There is: Pick an injective function from sequences of strings to >> strings. For instance one can take >> f([]) = "" >> | f([x:xs])=len(x)+":"+x+f(xs) >> >> where len(x) is the base-10, ASCII representation of the length of x. >> This is an injective function from sequences of strings to strings. >> >> With this, in the analysis you don't need to worry about what the >> tuple being input looks like, as you will never have a collision. This >> is similar to the use of lengths of the message and associated data in >> AEAD modes. >> > > Yeah, I kinda like that I have to say. Even if there's no real > attack against HOBA as-is, doing that seems like a good plan in > case the HOBA signature scheme/code ever gets re-used elsewhere, > and to make the analysis easier. > > Let me go check stuff and get back but I'm warming to this idea. I'll note that there are often attacks possible when you do pure concatination of strings into a hash. PGP had this problem, too, a long long time ago because an attacker could choose where to split the hashed values. The fix is to include lengths in the concatination, or have explicit field separators. > S. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Dec 9 04:38:15 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C061A1A6F57; Tue, 9 Dec 2014 04:38:11 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE0oEWxnbR5n; Tue, 9 Dec 2014 04:38:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8932D1A1BEA; Tue, 9 Dec 2014 04:38:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141209123810.18013.5085.idtracker@ietfa.amsl.com> Date: Tue, 09 Dec 2014 04:38:10 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/68iXbPFc2FMgvbcl5UeaM1Se5Mk Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-hoba-07.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 12:38:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : HTTP Origin-Bound Authentication (HOBA) Authors : Stephen Farrell Paul Hoffman Michael Thomas Filename : draft-ietf-httpauth-hoba-07.txt Pages : 25 Date : 2014-12-09 Abstract: HTTP Origin-Bound Authentication (HOBA) is a digital signature based design for an HTTP authentication method. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-hoba-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 9 04:38:17 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76261A6F57 for ; Tue, 9 Dec 2014 04:38:12 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcovAhnYgNwT; Tue, 9 Dec 2014 04:38:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA6E1A6F01; Tue, 9 Dec 2014 04:38:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, Kathleen.Moriarty.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141209123810.18013.92630.idtracker@ietfa.amsl.com> Date: Tue, 09 Dec 2014 04:38:10 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/xg4M9OF9u__2BqQLOdmwRG814HQ Subject: [http-auth] New Version Notification - draft-ietf-httpauth-hoba-07.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 12:38:13 -0000 A new version (-07) has been submitted for draft-ietf-httpauth-hoba: http://www.ietf.org/internet-drafts/draft-ietf-httpauth-hoba-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Dec 9 04:42:50 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6301A0367 for ; Tue, 9 Dec 2014 04:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ7EsAHzPVlD for ; Tue, 9 Dec 2014 04:42:44 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E941A0363 for ; Tue, 9 Dec 2014 04:42:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 996B6BEB5 for ; Tue, 9 Dec 2014 12:42:42 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvfq-PZikWlr for ; Tue, 9 Dec 2014 12:42:41 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.41.57.238]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1ABD3BEEE for ; Tue, 9 Dec 2014 12:42:40 +0000 (GMT) Message-ID: <5486EE3D.10507@cs.tcd.ie> Date: Tue, 09 Dec 2014 12:42:37 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: http-auth@ietf.org References: <20141209123810.18013.5085.idtracker@ietfa.amsl.com> In-Reply-To: <20141209123810.18013.5085.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/kcYgmfG6yWVrgtNXGmPS2RGmwPA Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-hoba-07.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 12:42:47 -0000 Hi all, This I hope fixes the potential issue Watson identified by adding a length: to each field in HOBA-TBS. I also took the chance to update the examples to example.com and not hoba-local.ie since they needed to change anyway with the change to the bytes of HOBA-TBS. So from my POV I think this is ready for IETF LC now once the chairs post the write up and Kathleen hits the button. Thanks, S. PS: I've updated my code enough to test this and re-generate the examples but haven't yet commited that back to the repo. Will try get to that in the next day or so. On 09/12/14 12:38, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. > > Title : HTTP Origin-Bound Authentication (HOBA) > Authors : Stephen Farrell > Paul Hoffman > Michael Thomas > Filename : draft-ietf-httpauth-hoba-07.txt > Pages : 25 > Date : 2014-12-09 > > Abstract: > HTTP Origin-Bound Authentication (HOBA) is a digital signature based > design for an HTTP authentication method. The design can also be > used in Javascript-based authentication embedded in HTML. HOBA is an > alternative to HTTP authentication schemes that require passwords and > therefore avoids all problems related to passwords, such as leakage > of server-side password databases. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-hoba-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From nobody Tue Dec 9 04:44:15 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8A01A037B for ; Tue, 9 Dec 2014 04:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z549i3ND6sUi for ; Tue, 9 Dec 2014 04:44:11 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A191A0363 for ; Tue, 9 Dec 2014 04:44:11 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so730378wgg.0 for ; Tue, 09 Dec 2014 04:44:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=7ZafBdzG8GCrKdti9+nt8WCimS6i3rEWi5XOqAvEAgU=; b=we5N4zSK+NJcg5knqjs+NyAyJtL5Sk+Kb6kv5gjjrsR1faW5rLpXg0h1o+NeetjaTe Mp1xUXVjTiuV7KAoWgM8F2t89O2RPRt7bCOf8cb6xOQWdxAYoIla6ho37bNQGcXs/Lpa yNnj+G/acHsd7GaNNCNJtakfM9Em3LgYA/ee57iTslrAIBAcLAxOg1si+duwkU3bTKFI r7whEz6TkgBZFoCKpby31dlFzTLZv1BhL/0ujCsh2IDLCojIWWvmNx4yshHRDwk1y1/Y mKbMiymXBYvlOOpRWNIOPhT8JZpQOcRavMn2iRGwzcdxeFtOvIitui8LKNn2wOQ/OYkJ 1wyw== X-Received: by 10.180.102.135 with SMTP id fo7mr4097341wib.79.1418129049853; Tue, 09 Dec 2014 04:44:09 -0800 (PST) Received: from [172.24.248.241] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id dg7sm2072921wib.24.2014.12.09.04.44.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Dec 2014 04:44:09 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_883F40F2-A0CF-4ABE-8DAA-D85A8ED66DA1" Date: Tue, 9 Dec 2014 14:44:07 +0200 References: <20141209123810.18013.92630.idtracker@ietfa.amsl.com> To: IETF HTTP Auth Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/R7WZYOAQuMy4_4v1x4LdJm60LJA Subject: [http-auth] Fwd: New Version Notification - draft-ietf-httpauth-hoba-07.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 12:44:13 -0000 --Apple-Mail=_883F40F2-A0CF-4ABE-8DAA-D85A8ED66DA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all The authors of the HOBA draft have just updated it. The major change is = in the construction of the HOBA-TBS, following the discussion with = Watson. Please look over this change. If you disagree, the time to yell about it = is NOW. Matt & Yoav (with chair hats on) > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, = httpauth-chairs@tools.ietf.org, Kathleen.Moriarty.ietf@gmail.com > Date: December 9, 2014 at 2:38:10 PM GMT+2 > Subject: [http-auth] New Version Notification - = draft-ietf-httpauth-hoba-07.txt >=20 >=20 > A new version (-07) has been submitted for draft-ietf-httpauth-hoba: > http://www.ietf.org/internet-drafts/draft-ietf-httpauth-hoba-07.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ >=20 > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-hoba-07 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > IETF Secretariat. >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth --Apple-Mail=_883F40F2-A0CF-4ABE-8DAA-D85A8ED66DA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all

The = authors of the HOBA draft have just updated it. The major change is in = the construction of the HOBA-TBS, following the discussion with = Watson.

Please = look over this change. If you disagree, the time to yell about it is = NOW.

Matt = & Yoav
(with chair hats on)

Begin forwarded message:

From: = internet-drafts@ietf.org
To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, Kathleen.Moriarty.ietf@gmail.com
Date: = December 9, 2014 at 2:38:10 PM = GMT+2
Subject: = [http-auth] New = Version Notification - draft-ietf-httpauth-hoba-07.txt


A = new version (-07) has been submitted for draft-ietf-httpauth-hoba:
http://www.ietf.org/internet-drafts/draft-ietf-httpauth-hoba-07= .txt


The IETF = datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-hoba-07<= br class=3D"">
Please note that it may take a couple of = minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

IETF Secretariat.

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth

= --Apple-Mail=_883F40F2-A0CF-4ABE-8DAA-D85A8ED66DA1-- From nobody Tue Dec 9 05:01:01 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CAF1A0451 for ; Tue, 9 Dec 2014 05:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5bA-yPxuLTg for ; Tue, 9 Dec 2014 05:00:58 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3341A0382 for ; Tue, 9 Dec 2014 05:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418130056; d=isode.com; s=selector; i=@isode.com; bh=2QM5dfooXLHNL44NQwHI1fjTISOZp2mPZHEC0T3CAQE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=omGzbuUuO+vBLl/plfgLQDXhS4Y3SvW/Ou12Yd4MomVZJUpPUjeuJht5tq+IvfXBiOdUvd WikfrO+Xb693k6ay+2wJqh9T1n/ru49pxqHgU2MhmozDnMEM9qa+gprPg7i+WU5Qb348/n JQAnLtPgEGWI12JK3zvpbEnnktXwQhg=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 9 Dec 2014 13:00:56 +0000 Message-ID: <5486F287.8050200@isode.com> Date: Tue, 09 Dec 2014 13:00:55 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 To: Yoav Nir , IETF HTTP Auth References: <20141209123810.18013.92630.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000907090508050906070108" Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/h_NfYVr4hwHWWr4TezmB8vARVtM Subject: Re: [http-auth] Fwd: New Version Notification - draft-ietf-httpauth-hoba-07.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 13:00:59 -0000 This is a multi-part message in MIME format. --------------000907090508050906070108 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 09/12/2014 12:44, Yoav Nir wrote: > Hi all > > The authors of the HOBA draft have just updated it. The major change > is in the construction of the HOBA-TBS, following the discussion with > Watson. > > Please look over this change. If you disagree, the time to yell about > it is NOW. I like the change. > Matt & Yoav > (with chair hats on) > >> Begin forwarded message: >> >> *From: *internet-drafts@ietf.org >> *To: *draft-ietf-httpauth-hoba.all@tools.ietf.org >> , >> http-auth@ietf.org , >> httpauth-chairs@tools.ietf.org >> , >> Kathleen.Moriarty.ietf@gmail.com >> >> *Date: *December 9, 2014 at 2:38:10 PM GMT+2 >> *Subject: **[http-auth] New Version Notification - >> draft-ietf-httpauth-hoba-07.txt* >> >> >> A new version (-07) has been submitted for draft-ietf-httpauth-hoba: >> http://www.ietf.org/internet-drafts/draft-ietf-httpauth-hoba-07.txt >> >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ >> >> Diff from previous version: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-07 >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> IETF Secretariat. >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth --------------000907090508050906070108 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 09/12/2014 12:44, Yoav Nir wrote:
Hi all

The authors of the HOBA draft have just updated it. The major change is in the construction of the HOBA-TBS, following the discussion with Watson.

Please look over this change. If you disagree, the time to yell about it is NOW.
I like the change.
Matt & Yoav
(with chair hats on)

Begin forwarded message:

Date: December 9, 2014 at 2:38:10 PM GMT+2
Subject: [http-auth] New Version Notification - draft-ietf-httpauth-hoba-07.txt


A new version (-07) has been submitted for draft-ietf-httpauth-hoba:
http://www.ietf.org/internet-drafts/draft-ietf-httpauth-hoba-07.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth



_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth

--------------000907090508050906070108-- From nobody Tue Dec 9 17:25:06 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F1D1A1A62; Tue, 9 Dec 2014 17:25:05 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOD8MWHUQhPr; Tue, 9 Dec 2014 17:25:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6603F1A038F; Tue, 9 Dec 2014 17:25:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> Date: Tue, 09 Dec 2014 17:25:03 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/QvF9V5ucVCHPyFCekX_Dw-U24x4 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 01:25:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-09.txt Pages : 31 Date : 2014-12-09 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that may be used with the authentication mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 9 17:30:22 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49DD1A1A0B for ; Tue, 9 Dec 2014 17:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wndpcv3AG6Km for ; Tue, 9 Dec 2014 17:30:18 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141E11A1B79 for ; Tue, 9 Dec 2014 17:30:18 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so1500827lbi.24 for ; Tue, 09 Dec 2014 17:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HnloZDwg+oP3L2sR1sfBXb0JM0vWBxCJe7I3dPEsyrs=; b=mlyjY6jUmrhG9BfW4RFwnq//moB9UQQgkpFtDNT0iAtu9DvwqWfOcHRIrCs3QguQjm LzRvnTn9+muKolmYkBEF8a370EFY3SX4N/lfGR81WCZALSJozMFbD5wrQ/BnDqJuF/gq 5/RzCsqW2TyiwF05V370a1NpN9XNMjs4XcNVPMJhcfFEIneQQ8G2pejcsRY5oR4OsEnX BW/uF6TpxfRaRagToM41S8yr07GfzCCpwOGoyNS1+iID8FBgLvCgdedWKecN9dYmu3+2 PkVbXT02i7CQez8/UrC/RYgZKyE4PCVmyM3ccnc1tRoHlynCZPTkvcvDFhwwixpW5Hxe XfQw== MIME-Version: 1.0 X-Received: by 10.152.5.198 with SMTP id u6mr1436256lau.42.1418175016641; Tue, 09 Dec 2014 17:30:16 -0800 (PST) Received: by 10.114.99.36 with HTTP; Tue, 9 Dec 2014 17:30:16 -0800 (PST) In-Reply-To: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> Date: Tue, 9 Dec 2014 20:30:16 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=089e013d1b6e18a8920509d29ad2 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/5Dx21TK4wtgDJb8vJJtyphCWtlU Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 01:30:21 -0000 --089e013d1b6e18a8920509d29ad2 Content-Type: text/plain; charset=ISO-8859-1 Hi, We believe that with -09 we have addressed all the comment we received during the WGLC and during the meeting in Honolulu. We believe that the document is ready to go to the IESG. Please, take a look and let us know if you have any further comments. Regards, Rifaat On Tue, Dec 9, 2014 at 8:25 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. > > Title : HTTP Digest Access Authentication > Authors : Rifaat Shekh-Yusef > David Ahrens > Sophie Bremer > Filename : draft-ietf-httpauth-digest-09.txt > Pages : 31 > Date : 2014-12-09 > > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that may be used with the > authentication mechanism. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-09 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --089e013d1b6e18a8920509d29ad2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

We believe that with -09 we have ad= dressed all the comment we received during the WGLC and during the meeting = in Honolulu.
We believe that the document is ready to go to the I= ESG.

Please, take a look and let us know if yo= u have any further comments.

Regards,
= =A0Rifaat


On Tue, Dec 9, 2014 at 8:25 PM, <internet-drafts@ietf= .org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Hypertext Transfer Protocol Authenticat= ion Working Group of the IETF.

=A0 =A0 =A0 =A0 Title=A0 =A0 =A0 =A0 =A0 =A0: HTTP Digest Access Authentica= tion
=A0 =A0 =A0 =A0 Authors=A0 =A0 =A0 =A0 =A0: Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Ahrens
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sophie Bremer
=A0 =A0 =A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-httpauth-digest-09.txt=
=A0 =A0 =A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 =A0: 31
=A0 =A0 =A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2014-12-09

Abstract:
=A0 =A0HTTP provides a simple challenge-response authentication mechanism =A0 =A0that may be used by a server to challenge a client request and by a<= br> =A0 =A0client to provide authentication information. This document defines<= br> =A0 =A0the HTTP Digest Authentication scheme that may be used with the
=A0 =A0authentication mechanism.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest= /

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-09
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-09


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth

--089e013d1b6e18a8920509d29ad2-- From nobody Wed Dec 10 03:17:02 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1901A1A20; Wed, 10 Dec 2014 03:17:00 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nbNMc2C8Xgo; Wed, 10 Dec 2014 03:16:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3294A1A19EC; Wed, 10 Dec 2014 03:16:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Yoav Nir" To: Kathleen.Moriarty.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210111658.11637.16175.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 03:16:58 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/JtscfRgDS_Xf1mEJ2ag5KqYgU54 Cc: iesg-secretary@ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, draft-ietf-httpauth-hoba.all@tools.ietf.org Subject: [http-auth] Publication has been requested for draft-ietf-httpauth-hoba-07 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 11:17:00 -0000 Yoav Nir has requested publication of draft-ietf-httpauth-hoba-07 as Experimental on behalf of the HTTPAUTH working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ From nobody Wed Dec 10 06:07:20 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AFE1A902C; Wed, 10 Dec 2014 06:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nid4nm6rivC4; Wed, 10 Dec 2014 06:07:14 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278861A9029; Wed, 10 Dec 2014 06:07:14 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id pv20so2457356lab.13 for ; Wed, 10 Dec 2014 06:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JoxbhLVXXaVTY8BsxFLUc+jDVzEPBjAywFDrtWq5k04=; b=h75GxGgVgO/4TcVT7csw5RLqTJPISWUwCYHSZ40dXUmG69wJ+AOQ0kNVtPsjRrWgEw 9OPpucMdyDYCdD7+Q69TVE7JEnLM/JSxYvEjrvoMwCO0M43CE3/tthvDN+CB//RefdXi DFF4kgYfQr54AeQCYPpg4E74ePi/+GZ7Z5NqFTvFg+IM2PfWc6SG+NIocSYI+K0H+xIv kKxLfFHdXmnw1yyR+mNW5OtmkUPakEC2tlbVadC6emku+d6yfmG1Qi+XstnJqRgze2WB RRr6kcikRVv7CcMA6z4N2xk8juFyQHzWezRx7xiTcNqI18ZyHjgtLVkWH+Oh2lUEGO/y w+Tw== MIME-Version: 1.0 X-Received: by 10.152.87.67 with SMTP id v3mr4090669laz.97.1418220432596; Wed, 10 Dec 2014 06:07:12 -0800 (PST) Received: by 10.112.49.52 with HTTP; Wed, 10 Dec 2014 06:07:12 -0800 (PST) In-Reply-To: <20141210111658.11637.16175.idtracker@ietfa.amsl.com> References: <20141210111658.11637.16175.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 09:07:12 -0500 Message-ID: From: Kathleen Moriarty To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/IsmtHO9JuvYISyQKeT-sbB_ZvEg Cc: "iesg-secretary@ietf.org" , "http-auth@ietf.org" , httpauth-chairs@tools.ietf.org, draft-ietf-httpauth-hoba.all@tools.ietf.org Subject: Re: [http-auth] Publication has been requested for draft-ietf-httpauth-hoba-07 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 14:07:19 -0000 Thank you, all. I requested last call for this draft. Best regards, Kathleen On Wed, Dec 10, 2014 at 6:16 AM, Yoav Nir wrote: > Yoav Nir has requested publication of draft-ietf-httpauth-hoba-07 as Experimental on behalf of the HTTPAUTH working group. > > Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ > -- Best regards, Kathleen From nobody Wed Dec 10 06:09:10 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B721A902C for ; Wed, 10 Dec 2014 06:06:35 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJUEgsfcgANW; Wed, 10 Dec 2014 06:06:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 514B41A9027; Wed, 10 Dec 2014 06:06:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210140633.16157.4151.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 06:06:33 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/w5hsljtpetD72QpLTv3QDp377Zs X-Mailman-Approved-At: Wed, 10 Dec 2014 06:09:07 -0800 Subject: [http-auth] ID Tracker State Update Notice: X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 14:06:35 -0000 IESG state changed to Last Call Requested from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ From nobody Wed Dec 10 06:23:03 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90AE1A9024; Wed, 10 Dec 2014 06:22:50 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA7TziMWHPlM; Wed, 10 Dec 2014 06:22:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8291A8FD4; Wed, 10 Dec 2014 06:22:47 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141210142247.26304.1220.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 06:22:47 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/JxcAUJpCgUk6HLLQ5LrB2D0M91E Cc: http-auth@ietf.org Subject: [http-auth] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 14:22:50 -0000 The IESG has received a request from the Hypertext Transfer Protocol Authentication WG (httpauth) to consider the following document: - 'HTTP Origin-Bound Authentication (HOBA)' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract HTTP Origin-Bound Authentication (HOBA) is a digital signature based design for an HTTP authentication method. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Dec 10 06:24:22 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F025D1A9037 for ; Wed, 10 Dec 2014 06:23:01 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8IhoBXjTsJT; Wed, 10 Dec 2014 06:22:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0BE1A903B; Wed, 10 Dec 2014 06:22:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210142248.26304.81918.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 06:22:48 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/YAW9FPVeFyUFC8K_tBTb8lsKF5c X-Mailman-Approved-At: Wed, 10 Dec 2014 06:24:18 -0800 Subject: [http-auth] ID Tracker State Update Notice: X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 14:23:02 -0000 Last call has been made for draft-ietf-httpauth-hoba and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ From nobody Wed Dec 10 06:34:51 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F57D1A1B05 for ; Wed, 10 Dec 2014 06:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE9ySzCMd30T for ; Wed, 10 Dec 2014 06:34:47 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901C11A1AA8 for ; Wed, 10 Dec 2014 06:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418222087; x=2282135687; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7uwGzcMFtuNDx1b3Dm+CCgvdpY5I7pv9/rU1iHdSHpw=; b=C7dh7siI975vv0uBw+qJ2PNtx6k3YaoT1Dv5ECVg8TIPrFJ0yQ2da3AVM7pHSltO lQB5o7jF+Zuy3yUWM6SLHutC2uaLEsz9nE7b7fUr3Mw/JWyT+/PC/9z6oJld3l40 FCfRCGvJYcUhMIH6aeAPgNziy2EQFNx2GrFvQ3Hi5rogdwiit/8esnx70zsj7Ggh JVk59ATO3H9gyVXfdi6dvajLGHr2txKx3KQq/fq09m8wUqIAHMYOnfV1phCkK/gW n0gJWdGjpLpF5bVr6MtsXrEq62SK1un6EqnTgDdsNIB/f4vorfXn7djRvSe36enY mhiHd/nyMzelBQ6lbkRYaA==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id A7.CC.18524.70A58845; Wed, 10 Dec 2014 06:34:47 -0800 (PST) X-AuditID: 11973e15-f79476d00000485c-99-54885a076c3c Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 9F.EE.06091.7E958845; Wed, 10 Dec 2014 06:34:15 -0800 (PST) Received: from [17.153.41.13] (unknown [17.153.41.13]) by chicory.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGD0088JF5XPZ30@chicory.apple.com> for http-auth@ietf.org; Wed, 10 Dec 2014 06:34:47 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-type: text/plain; charset=iso-8859-1 From: Michael Sweet In-reply-to: Date: Wed, 10 Dec 2014 09:34:44 -0500 Content-transfer-encoding: quoted-printable Message-id: References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FCYqsse1RFicKWB1+LD/jlMDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeP3Mq+CFeMX6zUUNjGeFuhg5OSQETCQm9y1lg7DFJC7cWw9k c3EICexjlPjVs5AZpujGnF3MEIl+JolfkzaxQDiTmCRerLvK1MXIwSEs4CbR8kwcpIFXQE+i 6cljJhCbWUBHovf7N7BBbAJqEr8n9bGC2JwCwRKb//aAbWYRUJV4sXEDVL2uxNKT3YwQtrbE k3cXWCFm2kjceNjGDrG3nVHi2rvn7CAJEaBl7X8XMkFcKivx7+IZsCIJgbesEquXz2OcwCg8 C8lRs5AcNQvJkgWMzKsYhXITM3N0M/PM9BILCnJS9ZLzczcxgsJ4up3oDsYzq6wOMQpwMCrx 8K642h4ixJpYVlyZe4hRmoNFSZz3yG6gkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbX/yOS +o7VzP2U9U7+2SeG5nM7ShkO+M04FJz244cy/4Mbd7g6es1dhErOaK/ckiLCcT+6jPlz2osD AhL+Vl+evCr59kc/8oXK7Mm7I/b9esP56L7Hx2q3+y/216cXh10SmPruRMlXEWmuzyfEkyeK 7+WVX/zl6s0aDrnDU1NyQxuCLW8nbpykxFKckWioxVxUnAgAV7B8WEQCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FCcrPs8siPE4GGXkMWH/XOYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8fqZV8EL8Yr1m4saGM8KdTFyckgImEjcmLOLGcIWk7hwbz1b FyMXh5BAP5PEr0mbWCCcSUwSL9ZdZepi5OAQFnCTaHkmDtLAK6An0fTkMROIzSygI9H7/RvY IDYBNYnfk/pYQWxOgWCJzX972EBsFgFViRcbN0DV60osPdnNCGFrSzx5d4EVYqaNxI2HbewQ e9sZJa69e84OkhABWtb+dyETxKWyEv8unmGfwCgwC8kds5DcMQvJ3AWMzKsYBYpScxIrzfUS CwpyUvWS83M3MYLDrjB1B2PjcqtDjAIcjEo8vCuutocIsSaWFVfmHmKU4GBWEuF9I9kRIsSb klhZlVqUH19UmpNafIhRmoNFSZw35F1jiJBAemJJanZqakFqEUyWiYNTqoGR77NbIdsj5o83 7XMkRORYvwnwxfV2V+05OEVViG/egUwGqbtu3UsKZzD/3LNAanH0xgYeM/maDLac1pWeqtvY zHTCrSzr93EosIllpBaVm/Vu7DzDvuWO5o2sK+mFazPKZI7svck1+8yPV2+LlqhNMV+65t3E RYUvuHQ/hadIMfI9OfXV+qESS3FGoqEWc1FxIgA98cU2NwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/U_mQtY3ipIG38j3waGV7hP_LHX0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 14:34:49 -0000 Comments: - Is the plan to publish the Basic and Digest updates at the same time? = The current BASIC reference is out of date (September 2013) and I don't = see any RFC Editor notes. Would it make sense to include a paragraph up = front explaining this for the RFC Editor and any reviewers? - The examples on Page 18 lack a space between "Authorization:" and = "Digest". Obviously not necessary for HTTP but the examples for = "WWW-Authenticate" include a space so it would be nice to have spaces = for consistency with the rest of the examples. Otherwise looks really good! > On Dec 9, 2014, at 8:30 PM, Rifaat Shekh-Yusef = wrote: >=20 > Hi, >=20 > We believe that with -09 we have addressed all the comment we received = during the WGLC and during the meeting in Honolulu. > We believe that the document is ready to go to the IESG. >=20 > Please, take a look and let us know if you have any further comments. >=20 > Regards, > Rifaat >=20 >=20 > On Tue, Dec 9, 2014 at 8:25 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Hypertext Transfer Protocol = Authentication Working Group of the IETF. >=20 > Title : HTTP Digest Access Authentication > Authors : Rifaat Shekh-Yusef > David Ahrens > Sophie Bremer > Filename : draft-ietf-httpauth-digest-09.txt > Pages : 31 > Date : 2014-12-09 >=20 > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that may be used with the > authentication mechanism. >=20 >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From nobody Wed Dec 10 07:08:18 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EF11A1A9C; Wed, 10 Dec 2014 07:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk0rALfe60_A; Wed, 10 Dec 2014 07:08:13 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837211A1A90; Wed, 10 Dec 2014 07:08:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 51AF8BE7C; Wed, 10 Dec 2014 15:08:12 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bvvqh2At32wD; Wed, 10 Dec 2014 15:08:12 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EFD82BE80; Wed, 10 Dec 2014 15:08:11 +0000 (GMT) Message-ID: <548861DB.8030105@cs.tcd.ie> Date: Wed, 10 Dec 2014 15:08:11 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kathleen Moriarty , Yoav Nir References: <20141210111658.11637.16175.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/8j4k92CBHWSR8vyngNIDvj7OgRo Cc: "iesg-secretary@ietf.org" , "http-auth@ietf.org" , httpauth-chairs@tools.ietf.org, draft-ietf-httpauth-hoba.all@tools.ietf.org Subject: Re: [http-auth] Publication has been requested for draft-ietf-httpauth-hoba-07 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 15:08:16 -0000 On 10/12/14 14:07, Kathleen Moriarty wrote: > Thank you, all. I requested last call for this draft. Cool. Thanks, S > > Best regards, > Kathleen > > On Wed, Dec 10, 2014 at 6:16 AM, Yoav Nir wrote: >> Yoav Nir has requested publication of draft-ietf-httpauth-hoba-07 as Experimental on behalf of the HTTPAUTH working group. >> >> Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ >> > > > From nobody Wed Dec 10 13:32:27 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7671A039C for ; Wed, 10 Dec 2014 13:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYuNWU3BYkmd for ; Wed, 10 Dec 2014 13:32:20 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524BD1A011E for ; Wed, 10 Dec 2014 13:32:19 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id s18so3220395lam.30 for ; Wed, 10 Dec 2014 13:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t+JXV/pOOKmOWEzvjEjtatrER9/LhrpYePRIbHh+rmw=; b=TIRIPyDcG0SIzBsj9CEmumn4CjahPqI0m7IRvltUXcrEMCTNs8iTpeV65fu62AbZnw ZiocP1bhWnV9xr9DAozRE5Bl366P5p7zJfvje8eYN3ng8rSOY0KCd8cED74yTzOVUvfc xmzv2ij9CfhLS//G+gkR0SuYfCGamTJbmy7eUXjE7pTtmQryPR0OM5LajUnnbngvT8p7 uhVUNxKXmXPfZ7cvXdxFwGeUMhGsCd+1w6UuXFDRT0nu4bf1NPYPYdNbEHC2Tz5aHDn8 tSmKj2gMJABE8DqmWDqY++ZECgigndVeQU/PvW5VAexpTs8X0BRK0sS03+85x+hDsd8g cRAw== MIME-Version: 1.0 X-Received: by 10.112.254.162 with SMTP id aj2mr6370686lbd.70.1418247137527; Wed, 10 Dec 2014 13:32:17 -0800 (PST) Received: by 10.114.99.36 with HTTP; Wed, 10 Dec 2014 13:32:17 -0800 (PST) In-Reply-To: References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 16:32:17 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Michael Sweet Content-Type: multipart/alternative; boundary=001a113462bed60e5b0509e36430 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Yordt29GmAJb3o7nFJBtLrCWv0k Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 21:32:24 -0000 --001a113462bed60e5b0509e36430 Content-Type: text/plain; charset=ISO-8859-1 Thanks Michael, Please, see my reply inline... Regards, Rifaat On Wed, Dec 10, 2014 at 9:34 AM, Michael Sweet wrote: > Comments: > > - Is the plan to publish the Basic and Digest updates at the same time? I will let the chairs answer this question. > The current BASIC reference is out of date (September 2013) Thanks. I will fix that. > and I don't see any RFC Editor notes. Would it make sense to include a > paragraph up front explaining this for the RFC Editor and any reviewers? > Can you please elaborate? > > - The examples on Page 18 lack a space between "Authorization:" and > "Digest". Obviously not necessary for HTTP but the examples for > "WWW-Authenticate" include a space so it would be nice to have spaces for > consistency with the rest of the examples. > > I will fix that. Again, thank you very much for your review and comments. Regards, Rifaat > Otherwise looks really good! > > > > On Dec 9, 2014, at 8:30 PM, Rifaat Shekh-Yusef > wrote: > > > > Hi, > > > > We believe that with -09 we have addressed all the comment we received > during the WGLC and during the meeting in Honolulu. > > We believe that the document is ready to go to the IESG. > > > > Please, take a look and let us know if you have any further comments. > > > > Regards, > > Rifaat > > > > > > On Tue, Dec 9, 2014 at 8:25 PM, wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. > > > > Title : HTTP Digest Access Authentication > > Authors : Rifaat Shekh-Yusef > > David Ahrens > > Sophie Bremer > > Filename : draft-ietf-httpauth-digest-09.txt > > Pages : 31 > > Date : 2014-12-09 > > > > Abstract: > > HTTP provides a simple challenge-response authentication mechanism > > that may be used by a server to challenge a client request and by a > > client to provide authentication information. This document defines > > the HTTP Digest Authentication scheme that may be used with the > > authentication mechanism. > > > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-httpauth-digest-09 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-09 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > --001a113462bed60e5b0509e36430 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Michael,

Please, see my reply in= line...

Regards,
=A0Rifaat

On Wed, De= c 10, 2014 at 9:34 AM, Michael Sweet <msweet@apple.com> wrote= :
Comments:

- Is the plan to publish the Basic and Digest updates at the same time?

I will let the chairs answer this question.

=A0
The current= BASIC reference is out of date (September 2013)

Thanks. I will fix that.

=A0
and I don't see any RFC Editor notes. Would it ma= ke sense to include a paragraph up front explaining this for the RFC Editor= and any reviewers?

Can you please elab= orate?

=A0

- The examples on Page 18 lack a space between "Authorization:" a= nd "Digest". Obviously not necessary for HTTP but the examples fo= r "WWW-Authenticate" include a space so it would be nice to have = spaces for consistency with the rest of the examples.


I will fix that.

<= div>
Again, thank you very much for your review and comments.=

Regards,
=A0Rifaat

=
=A0
Otherwise looks really good!


> On Dec 9, 2014, at 8:30 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
>
> Hi,
>
> We believe that with -09 we have addressed all the comment we received= during the WGLC and during the meeting in Honolulu.
> We believe that the document is ready to go to the IESG.
>
> Please, take a look and let us know if you have any further comments.<= br> >
> Regards,
>=A0 Rifaat
>
>
> On Tue, Dec 9, 2014 at 8:25 PM, <internet-drafts@ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>=A0 This draft is a work item of the Hypertext Transfer Protocol Authen= tication Working Group of the IETF.
>
>=A0 =A0 =A0 =A0 =A0Title=A0 =A0 =A0 =A0 =A0 =A0: HTTP Digest Access Aut= hentication
>=A0 =A0 =A0 =A0 =A0Authors=A0 =A0 =A0 =A0 =A0: Rifaat Shekh-Yusef
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0David Ahrens
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sophie Bremer >=A0 =A0 =A0 =A0 =A0Filename=A0 =A0 =A0 =A0 : draft-ietf-httpauth-digest= -09.txt
>=A0 =A0 =A0 =A0 =A0Pages=A0 =A0 =A0 =A0 =A0 =A0: 31
>=A0 =A0 =A0 =A0 =A0Date=A0 =A0 =A0 =A0 =A0 =A0 : 2014-12-09
>
> Abstract:
>=A0 =A0 HTTP provides a simple challenge-response authentication mechan= ism
>=A0 =A0 that may be used by a server to challenge a client request and = by a
>=A0 =A0 client to provide authentication information. This document def= ines
>=A0 =A0 the HTTP Digest Authentication scheme that may be used with the=
>=A0 =A0 authentication mechanism.
>
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-httpauth-d= igest/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-httpauth-digest-09
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-http= auth-digest-09
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--001a113462bed60e5b0509e36430-- From nobody Wed Dec 10 13:46:45 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E201A8A84 for ; Wed, 10 Dec 2014 13:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Eg-qKoW72sf for ; Wed, 10 Dec 2014 13:46:43 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7911A8884 for ; Wed, 10 Dec 2014 13:46:42 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so12660229wib.4 for ; Wed, 10 Dec 2014 13:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=/IVIV6B4gT6rLrFW0nYXUtXJ6pNs4eYJCY3ocBKEz6Q=; b=VRvSp2MlP2B2krxNM3Ccn5BUA4qEJaRdPFHhsasMwA14gZ39pDr+FU1XVpjK1jTHin dzfJ4T+BFP+RouDjbt3Kq3qTh3XeL1O7uxBCptN9KvGb4wxac4LN3jx0V2WQusGwolA6 mb/t2se4E50lv2PPXVO18IqtSOXTVvZMjaymwIwHsngIy/CfafM2kmspDcb7wCj3/fkh QW2h9sJ2JQ5Zjpg/PA0K2sz5obS+lbkZS2svsCE/vmxscXWqgh7I3GDwRLNlE7SB72Je jGv7QTNggvmri6+ZolWILDGMQN/CTZyy9HpXzp2Kioy+NXCgbCHkfJZE2BgZfhPu5kBn EpWg== X-Received: by 10.194.90.244 with SMTP id bz20mr10235100wjb.125.1418248001583; Wed, 10 Dec 2014 13:46:41 -0800 (PST) Received: from [192.168.1.103] (IGLD-84-228-36-153.inter.net.il. [84.228.36.153]) by mx.google.com with ESMTPSA id nb8sm345597wic.7.2014.12.10.13.46.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 13:46:40 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_232B6933-E54A-493F-9FE2-779A86D98C6A" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: Date: Wed, 10 Dec 2014 23:46:38 +0200 Message-Id: <23913841-2324-4359-806B-EED6532FAE95@gmail.com> References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/XaR5QHCNJOc4suoKxQF-nmevmjk Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 21:46:44 -0000 --Apple-Mail=_232B6933-E54A-493F-9FE2-779A86D98C6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Dec 10, 2014, at 11:32 PM, Rifaat Shekh-Yusef = wrote: >=20 > Thanks Michael, >=20 > Please, see my reply inline... >=20 > Regards, > Rifaat >=20 >=20 > On Wed, Dec 10, 2014 at 9:34 AM, Michael Sweet > wrote: > Comments: >=20 > - Is the plan to publish the Basic and Digest updates at the same = time? >=20 > I will let the chairs answer this question. That=92s the plan. If one or the other gets bogged down by some further = comments, we won=92t delay the other. Yoav= --Apple-Mail=_232B6933-E54A-493F-9FE2-779A86D98C6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 10, 2014, at 11:32 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thanks Michael,

Please, see my reply inline...

Regards,
 Rifaat


On Wed, = Dec 10, 2014 at 9:34 AM, Michael Sweet <msweet@apple.com> wrote:
Comments:
=
- Is the plan to publish the Basic and Digest updates at the same time? =

I will = let the chairs answer this = question.

That=92s the plan. If one or the other gets bogged down = by some further comments, we won=92t delay the other.

Yoav
= --Apple-Mail=_232B6933-E54A-493F-9FE2-779A86D98C6A-- From nobody Wed Dec 10 18:26:40 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875F61A6EFB for ; Wed, 10 Dec 2014 18:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zplcDW7cBAhM for ; Wed, 10 Dec 2014 18:26:37 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28F31A1A4E for ; Wed, 10 Dec 2014 18:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418264797; x=2282178397; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=P4kgFMG+fqCMrFQqa3I0+jqbmwffUHRk1sL4fh8wQlc=; b=1MhFiuSdjvhrSV3XL7v9Tqx6ifeKayeMdH8yBrTZxalXmy8o95/4PGjWIa2rYcbd 3rKyu0/+6Pscv5CHaXOJ4kvCkUnBE3a6XPzQOsUwmBMul6NETo90ydSRNh6JYy8r 8D6NMfXb5yghpP+ExjXVL4YmWEkEVwsOmObVlqwfPG/x6dFT0IYRuvVwEqwhBG4S TD+zwlSdFei2yiB50HQXXd3XKk8oXgrZmNBT9TSK1dcIiBZW0xJbYXtTSWPFGNuf gOQonFusrPAJH+Ent2PS7TiBjhRBP9htFGWd324FaPS+utKfqRiFFzZO0qbS45// mW8c5Rt3BTScJW0of61OGA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 9C.A8.18524.DD009845; Wed, 10 Dec 2014 18:26:37 -0800 (PST) X-AuditID: 11973e15-f79476d00000485c-43-548900dd1b63 Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 8E.F1.05452.0E009845; Wed, 10 Dec 2014 18:26:40 -0800 (PST) Received: from [17.153.41.13] (unknown [17.153.41.13]) by chicory.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGE00J4CC4BWN60@chicory.apple.com> for http-auth@ietf.org; Wed, 10 Dec 2014 18:26:36 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-type: text/plain; charset=iso-8859-1 From: Michael Sweet In-reply-to: Date: Wed, 10 Dec 2014 21:26:34 -0500 Content-transfer-encoding: quoted-printable Message-id: <8182CE85-217B-4813-A8F2-4B49FA8E1620@apple.com> References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FCYpnuXoTPEoLeN1+LD/jlMDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+LT8ClvBctaKnesuMTUwzmPpYuTkkBAwkWjuWckOYYtJXLi3 nq2LkYtDSGAfo8SNHSfhivqPn2WFSPQzSSz/1MwE4Uxikni7eTOQw8EhLOAm0fJMHKSBV0BP ounJYyYQm1lAR6L3+zdmEJtNQE3i96Q+VhCbUyBY4tfdNWCbWQRUJaae/sEGUa8rsfRkNyOE rS3x5N0FVpDxvAI2Ei2/dCHWNjJJ7D7+DaxXBGhX+9+FTBCHykr8u3iGHaRIQuAjq8StT18Z JzAKz0Jy0ywkN81CsmMBI/MqRqHcxMwc3cw8M73EgoKcVL3k/NxNjKBAnm4nuoPxzCqrQ4wC HIxKPLwrrraHCLEmlhVX5h5ilOZgURLnPbIbKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGx WTPk4yHhc/NDjTx5P2RpPj87XSJnx5Ovsje+dKvry8sY79n3vYCB6+P6FRMvuFq42rzkeuXb L/NFeWHB04i0xoBnX0NnxSQvu7XuyT3hlfrXXx/fwJv0lHHyUZML2SxprNoNUzS0Cj3XlToa GhvdPZPu6tD4q+aJ/AbFK/sjpgU2TcgJFPVSYinOSDTUYi4qTgQAn995w0UCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FCcrPuAoTPEYEeLqMWH/XOYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8Wn5FbaC5awVO9ddYmpgnMfSxcjJISFgItF//CwrhC0mceHe erYuRi4OIYF+Jonln5qZIJxJTBJvN28Gcjg4hAXcJFqeiYM08AroSTQ9ecwEYjML6Ej0fv/G DGKzCahJ/J7UBzaUUyBY4tfdNewgNouAqsTU0z/YIOp1JZae7GaEsLUlnry7wAoynlfARqLl ly7E2kYmid3Hv4H1igDtav+7kAniUFmJfxfPsE9gFJiF5IxZSM6YhWTsAkbmVYwCRak5iZUW eokFBTmpesn5uZsYwYFXmLaDsWm51SFGAQ5GJR7eFVfbQ4RYE8uKK3MPMUpwMCuJ8Cbd6AgR 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzlv2rjFESCA9sSQ1OzW1ILUIJsvEwSnVwNjzxP2dhu6T ++cMj3h0bJ189ZZztFbpmTvVj94ef32ywXiynvq/GQLTFgiu2BPWUPvmSfGLrWq+y/Kc0gL+ rtZ79PWOOfPGY3v+PLH7vGB1QvJq21lCbMo633a4L5IsmF0dFeW8cu2pr/E9crfV3HzP3X8u NPHRkrdOejNqgl3vWMet8uftVLulxFKckWioxVxUnAgA1jgUoTgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/CkAqejomdpxV4AuIJunS9ti1PP0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 02:26:38 -0000 > On Dec 10, 2014, at 4:32 PM, Rifaat Shekh-Yusef = wrote: > ...=20 > and I don't see any RFC Editor notes. Would it make sense to include a = paragraph up front explaining this for the RFC Editor and any reviewers? >=20 > Can you please elaborate? I mean something like: RFC Editor's Note: This and the HTTP Basic update are intended for simultaneous publication and together obsolete RFC 2617. References = to [BASIC] should be changed to [RFCnnnn]. And/or use RFCnnnn for the HTTP Basic reference? _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From nobody Wed Dec 10 22:38:55 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B699E1A88CF for ; Wed, 10 Dec 2014 22:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1scg_-2lYvUU for ; Wed, 10 Dec 2014 22:38:51 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017E01A037D for ; Wed, 10 Dec 2014 22:38:51 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so13503162wib.4 for ; Wed, 10 Dec 2014 22:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=myytU8wQrGt2CqPzcy/4n7olDqAXx6bcq4v09QQbZf4=; b=n0oHiw9yEMkXOeXKHls7vy3g3RQV9lH6QOqGMtu1wKJKD0/6kWNYvt1+8WXvbZNHTe I2XFkn1VyHaZl+Si0ewH8yGCBuEI2jIaH7CoigYJ+NfG/mEL9SKSPEoEvbczzjSrryju JMv9tyr3OLGQs3XdffPWUFcn9DWHf4o2at82N+DDE6z5Jwkx2HdbYb6KYaZrhg+4ZFwF QnNevUljLLNAtFvAuAL0kN+Siu+PGeO5orvvm22pTecnFvFhQzeq5sANilEbAUhOoUVg 1C4gmW9QxXXRADLo1bVuibAO1Bc5yuhgXQlIOMU64LzM/p2k8LjRBX4XBeBjao3OIbWO 1pqw== X-Received: by 10.194.83.42 with SMTP id n10mr12911836wjy.133.1418279929798; Wed, 10 Dec 2014 22:38:49 -0800 (PST) Received: from yoavs-mbp.mshome.net ([109.253.142.216]) by mx.google.com with ESMTPSA id vy7sm379570wjc.27.2014.12.10.22.38.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 22:38:49 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <8182CE85-217B-4813-A8F2-4B49FA8E1620@apple.com> Date: Thu, 11 Dec 2014 08:38:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <8182CE85-217B-4813-A8F2-4B49FA8E1620@apple.com> To: Michael Sweet X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/WNWQDGILhCJ1bYZ1DogKyg-OcU4 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 06:38:52 -0000 It=E2=80=99s not a problem. What you have there is a normative reference to a draft. RFCs never([1]) = get published with normative reference to Internet Drafts or to RFCs at = a lower maturity level. The RFC editor will correct this reference, and even delay publication = of Digest until Basis is ready (if Digest gets to the RFC editor first). Yoav [1] well, hardly ever - = http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry > On Dec 11, 2014, at 4:26 AM, Michael Sweet wrote: >=20 >> On Dec 10, 2014, at 4:32 PM, Rifaat Shekh-Yusef = wrote: >> ...=20 >> and I don't see any RFC Editor notes. Would it make sense to include = a paragraph up front explaining this for the RFC Editor and any = reviewers? >>=20 >> Can you please elaborate? >=20 > I mean something like: >=20 > RFC Editor's Note: This and the HTTP Basic update are intended for > simultaneous publication and together obsolete RFC 2617. = References to > [BASIC] should be changed to [RFCnnnn]. >=20 > And/or use RFCnnnn for the HTTP Basic reference? >=20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Wed Dec 10 22:43:47 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BA91A8888 for ; Wed, 10 Dec 2014 22:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF9e7NqCOqZh for ; Wed, 10 Dec 2014 22:43:44 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE321A037D for ; Wed, 10 Dec 2014 22:43:43 -0800 (PST) Received: from [192.168.2.160] ([93.217.124.29]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LwJFG-1Xu9ZL2X2E-0182sp for ; Thu, 11 Dec 2014 07:43:41 +0100 Message-ID: <54893D16.7020600@gmx.de> Date: Thu, 11 Dec 2014 07:43:34 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "http-auth@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:V+gLLklgM+VE+eoID3OYarehlJS64GZ82byV+yEYaqjXsxsfa/M Ncv9N/hxXuediCVjCtw3AVmLDjeKKe392EFFZAWQOQt079pQMudpTcuHRlNy7A3QC5gRbMz Jtee8XLyKDdjoJ/NDGG2fvoMVJYAuFn0C3xPBdwNOasDsuL16dFXd9Tuyl7yZ48+znQ/zj8 x9twbVCe+B+BHJGJllycg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/kRB-bJeo52Xz1xaXuOILN8eu9TU Subject: [http-auth] Last Calls X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 06:43:45 -0000 Wow. We now have one document in WGLC and two soon in IETF LC at the same time. Furthermore, the ones being last-called had their IDs updated with no review time for the WG (as far as I can tell). Can we slow down a bit. Please? From nobody Wed Dec 10 22:44:49 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980501A8942 for ; Wed, 10 Dec 2014 22:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYPfODpUS2nq for ; Wed, 10 Dec 2014 22:44:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF8E1A8971 for ; Wed, 10 Dec 2014 22:44:48 -0800 (PST) Received: from [192.168.2.160] ([93.217.124.29]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MJSx9-1Xx1gB0GS3-0031dN; Thu, 11 Dec 2014 07:44:40 +0100 Message-ID: <54893D50.8000408@gmx.de> Date: Thu, 11 Dec 2014 07:44:32 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Michael Sweet , Rifaat Shekh-Yusef References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <8182CE85-217B-4813-A8F2-4B49FA8E1620@apple.com> In-Reply-To: <8182CE85-217B-4813-A8F2-4B49FA8E1620@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:tYpI4pImuPLJCzOnKW3nXFu056xap4APzmOyGUsmJS0FJWtoyOG DwTDYuZ6KK+kKCZowXzpF30gvgt7FzWOD+tYMfUTvBUXjJvGRnICZX+2+FUvwPv8HGS3xUM FPmOXIZ7tnyVZN3vTaDoUVFsoCKH6sz/f51meIPX+7P5DyrNMe2wYFoIch7whrI0G0MoDzI f3VMQ5KCpOfL4uztSjpXg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Dqj9KQ27qVoUGVFgfEcwKWeoHV0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 06:44:49 -0000 On 2014-12-11 03:26, Michael Sweet wrote: >> On Dec 10, 2014, at 4:32 PM, Rifaat Shekh-Yusef wrote: >> ... >> and I don't see any RFC Editor notes. Would it make sense to include a paragraph up front explaining this for the RFC Editor and any reviewers? >> >> Can you please elaborate? > > I mean something like: > > RFC Editor's Note: This and the HTTP Basic update are intended for > simultaneous publication and together obsolete RFC 2617. References to > [BASIC] should be changed to [RFCnnnn]. > > And/or use RFCnnnn for the HTTP Basic reference? > ... That's something that is usually dealt with at time of AUTH48; no special note needed. Best regards, Julian From nobody Wed Dec 10 22:51:38 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E9E1A1A7E for ; Wed, 10 Dec 2014 22:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyrUkfUE5q3M for ; Wed, 10 Dec 2014 22:51:35 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C111A0AC8 for ; Wed, 10 Dec 2014 22:51:35 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so13566028wiw.2 for ; Wed, 10 Dec 2014 22:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BInkdoxDo4DB7AUT8v2iASTWPaCiTaWkGNUnLWPHm/I=; b=UAde9sSBu2v2n5p10djAc8nek8aISTz4Nv5Fm6eqt73NYD6jKgdiZOUNxzxMn4siUH CsdLe5a3BsqMyvgCAUWxUX7k4XT7JqjidKU14TtIUQ3cSERwQWFPWTynp0V5vhTHlAtE U/fX0I5gVBk6aT279xfrXXZsocryF/ZnCgFY2YNZw4QsTCoooG/hfVGdRuikDS/EenDK vSiuXl+DpGRiOPhN9mJ62K+EyCVhvhjRiq+/9R9GNGCJ0+CwFBa6++22nTIKT/KD323F Iei+vLbOm07YU8m4cC2qlZ26A7LKaNcHt3cShnkSKVH/8hlAmqElEe8u+kdFH4Ev2X/8 bVxQ== X-Received: by 10.194.60.45 with SMTP id e13mr13562173wjr.109.1418280694208; Wed, 10 Dec 2014 22:51:34 -0800 (PST) Received: from yoavs-mbp.mshome.net ([109.253.142.216]) by mx.google.com with ESMTPSA id bj7sm403579wjc.33.2014.12.10.22.51.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 22:51:33 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <54893D16.7020600@gmx.de> Date: Thu, 11 Dec 2014 08:51:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <860939B0-A843-4B36-BA08-61E24C8C0198@gmail.com> References: <54893D16.7020600@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/HB4TQqbIBMG00iaYPFZc9w0BFgc Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Last Calls X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 06:51:36 -0000 > On Dec 11, 2014, at 8:43 AM, Julian Reschke = wrote: >=20 > Wow. >=20 > We now have one document in WGLC and two soon in IETF LC at the same = time. Furthermore, the ones being last-called had their IDs updated with = no review time for the WG (as far as I can tell). >=20 > Can we slow down a bit. Please? Well, people were complaining that the IETF doesn=E2=80=99t develop = protocols in a timely fashion=E2=80=A6 Anyway, we currently have one document (HOBA) in IETF last call. We have = one document (Basic) in WGLC. Digest has been revised since last WGLC, = and the changes are enough to warrant another WGLC, which we=E2=80=99ll = start after the Basic one is over.=20 With any luck HOBA will be through the IESG shortly after the new year, = and immediately after that we will get Basic and Digest into IETF last = call. Is that too fast? Yoav From nobody Wed Dec 10 23:20:31 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D40A1A065C for ; Wed, 10 Dec 2014 23:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ir-WetKMGxT for ; Wed, 10 Dec 2014 23:20:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F095A1A03A1 for ; Wed, 10 Dec 2014 23:20:25 -0800 (PST) Received: from [192.168.2.160] ([93.217.124.29]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQiB3-1YNxZj0CY1-00U1W8; Thu, 11 Dec 2014 08:20:23 +0100 Message-ID: <548945AA.5020603@gmx.de> Date: Thu, 11 Dec 2014 08:20:10 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Yoav Nir References: <54893D16.7020600@gmx.de> <860939B0-A843-4B36-BA08-61E24C8C0198@gmail.com> In-Reply-To: <860939B0-A843-4B36-BA08-61E24C8C0198@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:wHJOz+qvxjfgpf3c3X6v3cApMyoRwDEbTD8TcpG/PEMOYB/iv6X xi/Y3zzYFQspLOKCANv4eARp/ZL3vS4z/bIJMYhKJXNkhop2P4Nl20ZS+YAbxMZIVPUIkYm kKeISnXzlFuZiqlkHbCci6y3HrLC1E6+dewdntgfBDydF586VvPnb63hd5u2YXXe7Ni1ITx p4PiLE+CdaBWY4llvmRYw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/9WDriaP0McOrj_rsHNch3S1iM1M Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Last Calls X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 07:20:28 -0000 On 2014-12-11 07:51, Yoav Nir wrote: > >> On Dec 11, 2014, at 8:43 AM, Julian Reschke wrote: >> >> Wow. >> >> We now have one document in WGLC and two soon in IETF LC at the same time. Furthermore, the ones being last-called had their IDs updated with no review time for the WG (as far as I can tell). >> >> Can we slow down a bit. Please? > > Well, people were complaining that the IETF doesn’t develop protocols in a timely fashion… > > Anyway, we currently have one document (HOBA) in IETF last call. We have one document (Basic) in WGLC. Digest has been revised since last WGLC, and the changes are enough to warrant another WGLC, which we’ll start after the Basic one is over. Ack. This is good. I thought we were going to IETF LC right away. > With any luck HOBA will be through the IESG shortly after the new year, and immediately after that we will get Basic and Digest into IETF last call. > > Is that too fast? It would have been good to have time to look at the new HOBA draft before sending it to the IESG, but other than that... Best regards, Julian From nobody Thu Dec 11 02:15:41 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709B51ACDD3 for ; Thu, 11 Dec 2014 02:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYo7IrpCq-gz for ; Thu, 11 Dec 2014 02:15:37 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22761A1A73 for ; Thu, 11 Dec 2014 02:15:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8D833BE79; Thu, 11 Dec 2014 10:15:34 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpNJqyUmbJPu; Thu, 11 Dec 2014 10:15:33 +0000 (GMT) Received: from [10.43.49.179] (unknown [193.190.253.145]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 78569BE56; Thu, 11 Dec 2014 10:15:33 +0000 (GMT) Message-ID: <54896EC5.8070001@cs.tcd.ie> Date: Thu, 11 Dec 2014 10:15:33 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , Yoav Nir References: <54893D16.7020600@gmx.de> <860939B0-A843-4B36-BA08-61E24C8C0198@gmail.com> <548945AA.5020603@gmx.de> In-Reply-To: <548945AA.5020603@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/uAXA0KvYvpFo6BIAMSCKuYYD-n4 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Last Calls X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 10:15:39 -0000 On 11/12/14 07:20, Julian Reschke wrote: > > It would have been good to have time to look at the new HOBA draft > before sending it to the IESG, but other than that... Well, the diff is quite small, adding some more length fields to handle the good comment from Watson (and updating examples), plus a paragraph about that. That was (briefly admittedly) discussed on the list with a few folks supporting the change. I also updated my code to match so's I could generate the new examples and it all seems fine to me (but then it would, wouldn't it:-) And we're quite happy to take comments during IETF LC of course. Cheers, S. From nobody Thu Dec 11 02:30:30 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41121ACDE1 for ; Thu, 11 Dec 2014 02:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1073QopU5qU for ; Thu, 11 Dec 2014 02:30:24 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 67B511A1BEE for ; Thu, 11 Dec 2014 02:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418293823; d=isode.com; s=selector; i=@isode.com; bh=AYDVGqtqyu+pBAdyqkLNtfVwZEhXK0gzxIkuiEo9Z28=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=TpjrjNFJD0LuNAkayvVp738tDQVJKlkBrqtrFQ4oF6ASvu70CMh/kNffiNcZ7nTjkNmcjM pijo3H2yNl1OCZq0gQufUuHqZJMefIBgaNJEwDVHWoI2F//AbINzxzlbZm7m1n159jLQXO 2ci46L0BXXaV+Y3PRKGJfNIShHdcD2E=; Received: from [192.168.0.12] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 11 Dec 2014 10:30:23 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (12B435) In-Reply-To: Date: Thu, 11 Dec 2014 10:34:11 +0000 Message-Id: <01074188-FCD7-4E76-9540-FC56E2B428D0@isode.com> References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> To: Rifaat Shekh-Yusef MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-0EBECD32-3BA2-40C0-B96B-14AF3AA601E5 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/7t14Y9kyKZ4ZyAu_icnqDF-ynJ4 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 10:30:29 -0000 --Apple-Mail-0EBECD32-3BA2-40C0-B96B-14AF3AA601E5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 10 Dec 2014, at 01:30, Rifaat Shekh-Yusef wrote= : >=20 > Hi, >=20 > We believe that with -09 we have addressed all the comment we received dur= ing the WGLC and during the meeting in Honolulu. > We believe that the document is ready to go to the IESG. >=20 > Please, take a look and let us know if you have any further comments. Hi Rifaat, I am mostly Ok with this version, but you made the Authentication-Info heade= r field optional for Digest servers to return which I think is an incompatib= le change. Is there any evidence that servers don't return it? > Regards, > Rifaat >=20 >=20 >> On Tue, Dec 9, 2014 at 8:25 PM, wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >> This draft is a work item of the Hypertext Transfer Protocol Authenticat= ion Working Group of the IETF. >>=20 >> Title : HTTP Digest Access Authentication >> Authors : Rifaat Shekh-Yusef >> David Ahrens >> Sophie Bremer >> Filename : draft-ietf-httpauth-digest-09.txt >> Pages : 31 >> Date : 2014-12-09 >>=20 >> Abstract: >> HTTP provides a simple challenge-response authentication mechanism >> that may be used by a server to challenge a client request and by a >> client to provide authentication information. This document defines >> the HTTP Digest Authentication scheme that may be used with the >> authentication mechanism. >>=20 >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-httpauth-digest-09 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-09 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submiss= ion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth --Apple-Mail-0EBECD32-3BA2-40C0-B96B-14AF3AA601E5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 10 Dec 2014, at 01:3= 0, Rifaat Shekh-Yusef <rifaat.ie= tf@gmail.com> wrote:

Hi,

We believe that with -09 we have address= ed all the comment we received during the WGLC and during the meeting in Hon= olulu.
We believe that the document is ready to go to the IESG.

Please, take a look and let us know if you have a= ny further comments.

Hi Rifaat,=
I am mostly Ok with this version, but you made the Authentication-Info h= eader field optional for Digest servers to return which I think is an incomp= atible change. Is there any evidence that servers don't return it?

Regards,
 Rifaat


On Tue, Dec 9, 2014 at 8:25 PM, <internet-drafts@ietf.= org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directori= es.
 This draft is a work item of the Hypertext Transfer Protocol Authentic= ation Working Group of the IETF.

        Title           : H= TTP Digest Access Authentication
        Authors         : Rifaa= t Shekh-Yusef
                     =     David Ahrens
                     =     Sophie Bremer
        Filename        : draft-ietf= -httpauth-digest-09.txt
        Pages           : 3= 1
        Date            : 2= 014-12-09

Abstract:
   HTTP provides a simple challenge-response authentication mechan= ism
   that may be used by a server to challenge a client request and b= y a
   client to provide authentication information. This document def= ines
   the HTTP Digest Authentication scheme that may be used with the=
   authentication mechanism.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/<= /a>

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-di= gest-09


Please note that it may take a couple of minutes from the time of submission=
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.= ietf.org/internet-drafts/

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth

____________________= ___________________________
http-auth mailing listhttp-auth@ietf.orghttps://= www.ietf.org/mailman/listinfo/http-auth
= --Apple-Mail-0EBECD32-3BA2-40C0-B96B-14AF3AA601E5-- From nobody Thu Dec 11 05:20:52 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFBB1A88B6 for ; Thu, 11 Dec 2014 05:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NwIVR7dF4uT for ; Thu, 11 Dec 2014 05:20:46 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CBFE1A88B0 for ; Thu, 11 Dec 2014 05:20:46 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so4133591lbv.0 for ; Thu, 11 Dec 2014 05:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KlN3GJMX462G1bpSfJlE2b+QmugpH01TCJvOFpcN350=; b=VNCPF+IdSuaw7uiBaJxfADHDGVoy/wHIZ/84oPShz6//JHUeB0eDsCEfuDdLm6PD+2 tMT03dZqefQIR1M45IA1W2JRAKAfpqI77BROoErrf3AyzDAcw4w+zMWLxuzB165cnjy5 vdnMFSICsTWho7kgnokoS0mO2eQGAGgYe6nz4HKGexb2M0ugI4wLWPFvLK2ZCSWXVr8k A91vM7YaWGFMuJFDQU2g1ExazKhPs0G0q2q8yJFd/ViVND6tUDPjE5xy6PNNyq/q5F+M Or8wmZfI1yCosqJ4S49zIYTsMBmP5wE0mx6P245oRPsHN0dG/zexMf0ZMoRiGQfkkgCV /NOQ== MIME-Version: 1.0 X-Received: by 10.112.91.43 with SMTP id cb11mr9682910lbb.63.1418304044659; Thu, 11 Dec 2014 05:20:44 -0800 (PST) Received: by 10.114.99.36 with HTTP; Thu, 11 Dec 2014 05:20:44 -0800 (PST) In-Reply-To: <01074188-FCD7-4E76-9540-FC56E2B428D0@isode.com> References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <01074188-FCD7-4E76-9540-FC56E2B428D0@isode.com> Date: Thu, 11 Dec 2014 08:20:44 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a11348fd6c3f91b0509f0a4c0 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/nOvYU1B4X6D1xBNi8yKsxOs8sTI Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 13:20:51 -0000 --001a11348fd6c3f91b0509f0a4c0 Content-Type: text/plain; charset=ISO-8859-1 Hi Alexey, Thanks for your review. I could not find a clear text in RFC2617 that requires the servers to use the Authentication-Info header field. Can you please point to the text that mandates the servers to use it? Regards, Rifaat On Thu, Dec 11, 2014 at 5:34 AM, Alexey Melnikov wrote: > > On 10 Dec 2014, at 01:30, Rifaat Shekh-Yusef > wrote: > > Hi, > > We believe that with -09 we have addressed all the comment we received > during the WGLC and during the meeting in Honolulu. > We believe that the document is ready to go to the IESG. > > Please, take a look and let us know if you have any further comments. > > > Hi Rifaat, > I am mostly Ok with this version, but you made the Authentication-Info > header field optional for Digest servers to return which I think is an > incompatible change. Is there any evidence that servers don't return it? > > Regards, > Rifaat > > > On Tue, Dec 9, 2014 at 8:25 PM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Hypertext Transfer Protocol >> Authentication Working Group of the IETF. >> >> Title : HTTP Digest Access Authentication >> Authors : Rifaat Shekh-Yusef >> David Ahrens >> Sophie Bremer >> Filename : draft-ietf-httpauth-digest-09.txt >> Pages : 31 >> Date : 2014-12-09 >> >> Abstract: >> HTTP provides a simple challenge-response authentication mechanism >> that may be used by a server to challenge a client request and by a >> client to provide authentication information. This document defines >> the HTTP Digest Authentication scheme that may be used with the >> authentication mechanism. >> >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-httpauth-digest-09 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-09 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > --001a11348fd6c3f91b0509f0a4c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alexey,

Thanks for your review.

I could not find a clear text in RFC2617 that requires= the servers to use the Authentication-Info header field. Can you please po= int to the text that mandates the servers to use it?

Regards,
=A0Rifaat



On T= hu, Dec 11, 2014 at 5:34 AM, Alexey Melnikov <alexey.melnikov@iso= de.com> wrote:

On 10 Dec 2014, at 01:30, Rifaat= Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Hi,

We believe that with -09 we = have addressed all the comment we received during the WGLC and during the m= eeting in Honolulu.
We believe that the document is ready to go t= o the IESG.

Please, take a look and let us kno= w if you have any further comments.

=
Hi Rifaat,
I am mostly Ok with this version, but you made = the Authentication-Info header field optional for Digest servers to return = which I think is an incompatible change. Is there any evidence that servers= don't return it?

Regards,
=A0Rifaat


On Tue= , Dec 9, 2014 at 8:25 PM, <internet-drafts@ietf.org>= wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Hypertext Transfer Protocol Authenticat= ion Working Group of the IETF.

=A0 =A0 =A0 =A0 Title=A0 =A0 =A0 =A0 =A0 =A0: HTTP Digest Access Authentica= tion
=A0 =A0 =A0 =A0 Authors=A0 =A0 =A0 =A0 =A0: Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Ahrens
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sophie Bremer
=A0 =A0 =A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-httpauth-digest-09.txt=
=A0 =A0 =A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 =A0: 31
=A0 =A0 =A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2014-12-09

Abstract:
=A0 =A0HTTP provides a simple challenge-response authentication mechanism =A0 =A0that may be used by a server to challenge a client request and by a<= br> =A0 =A0client to provide authentication information. This document defines<= br> =A0 =A0the HTTP Digest Authentication scheme that may be used with the
=A0 =A0authentication mechanism.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest= /

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-09
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-09


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth

___________________= ____________________________
http-auth mailing list<= br>http-auth@= ietf.org
https://www.ietf.org/mailman/listinfo/http-= auth
=
--001a11348fd6c3f91b0509f0a4c0-- From nobody Thu Dec 11 05:50:04 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732DA1ACE77 for ; Thu, 11 Dec 2014 05:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CZI0WMmJvoK for ; Thu, 11 Dec 2014 05:49:57 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id DB43B1ACE74 for ; Thu, 11 Dec 2014 05:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418305796; d=isode.com; s=selector; i=@isode.com; bh=FQiFE1xpZSXV9XTuI4q3vQpryYVANz5xpP2hhaxiLgQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=d51lIgaf0bCZwyZ9uS3jrFHa4lWSNnvZB+NA+Ma0Wc6qeDMZze9Yh5qBF5LjwYiBi/V05s EJp+CVBrsNpXvwVI+lE7Wf66eBG7wy0BK0zuf8bXNGDBBF3fSamKCgpor+xYxQ3ISksu9n ZUuRgvkL8S4vf/SDLgb75ZSHkKSZ/h4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 11 Dec 2014 13:49:55 +0000 Message-ID: <5489A0F8.7000300@isode.com> Date: Thu, 11 Dec 2014 13:49:44 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 To: Rifaat Shekh-Yusef References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <01074188-FCD7-4E76-9540-FC56E2B428D0@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050108070406010906070802" Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/OYl6CHjQDh-saM_kO5o_NBRxHMY Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 13:50:01 -0000 --------------050108070406010906070802 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 11/12/2014 13:20, Rifaat Shekh-Yusef wrote: > Hi Alexey, > > Thanks for your review. > > I could not find a clear text in RFC2617 that requires the servers to > use the Authentication-Info header field. Can you please point to the > text that mandates the servers to use it? Mutual authentication property (which is an advertised feature of Digest) is only available if the server sends Authentication-Info. SASL DIGEST-MD5 (based on Digest) has the last response from the server as mandatory. (Which doesn't quite prove this, but this is why I always thought that it was mandatory.) I would like to get some feedback from implementors before declaring Authentication-Info header optional. > Regards, > Rifaat > > > > On Thu, Dec 11, 2014 at 5:34 AM, Alexey Melnikov > > wrote: > > > On 10 Dec 2014, at 01:30, Rifaat Shekh-Yusef > > wrote: > >> Hi, >> >> We believe that with -09 we have addressed all the comment we >> received during the WGLC and during the meeting in Honolulu. >> We believe that the document is ready to go to the IESG. >> >> Please, take a look and let us know if you have any further comments. > > Hi Rifaat, > I am mostly Ok with this version, but you made the > Authentication-Info header field optional for Digest servers to > return which I think is an incompatible change. Is there any > evidence that servers don't return it? > >> Regards, >> Rifaat >> >> >> On Tue, Dec 9, 2014 at 8:25 PM, > > wrote: >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Hypertext Transfer Protocol >> Authentication Working Group of the IETF. >> >> Title : HTTP Digest Access Authentication >> Authors : Rifaat Shekh-Yusef >> David Ahrens >> Sophie Bremer >> Filename : draft-ietf-httpauth-digest-09.txt >> Pages : 31 >> Date : 2014-12-09 >> >> Abstract: >> HTTP provides a simple challenge-response authentication >> mechanism >> that may be used by a server to challenge a client request >> and by a >> client to provide authentication information. This >> document defines >> the HTTP Digest Authentication scheme that may be used >> with the >> authentication mechanism. >> >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-httpauth-digest-09 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-09 >> >> >> Please note that it may take a couple of minutes from the >> time of submission >> until the htmlized version and diff are available at >> tools.ietf.org . >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > --------------050108070406010906070802 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable On 11/12/2014 13:20, Rifaat Shekh-Yusef wrote:
Hi Alexey,

Thanks for your review.

I could not find a clear text in RFC2617 that requires the servers to use the Authentication-Info header field. Can you please point to the text that mandates the servers to use it?
Mutual authentication property (which is an advertised feature of Digest) is only available if the server sends Authentication-Info. SASL DIGEST-MD5 (based on Digest) has the last response from the server as mandatory. (Which doesn't quite prove this, but this is why I always thought that it was mandatory.)

I would like to get some feedback from implementors before declaring Authentication-Info header optional.
Regards,
Rifaat



On Thu, Dec 11, 2014 at 5:34 AM, Alexey Melnikov <al= exey.melnikov@isode.com> wrote:

On 10 Dec 2014, at 01:30, Rifaat Shekh-Yusef <= rifaat.ietf@gmail.com> wrote:

Hi,

We believe that with -09 we have addressed all the comment we received during the WGLC and during the meeting in Honolulu.
We believe that the document is ready to go to the IESG.

Please, take a look and let us know if you have any further comments.

Hi Rifaat,
I am mostly Ok with this version, but you made the Authentication-Info header field optional for Digest servers to return which I think is an incompatible change. Is there any evidence that servers don't return it?

Regards,
=A0Rifaat


On Tue, Dec 9, 2014 at 8:25 PM, <internet-drafts@ietf.org= > wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
=A0This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

=A0 =A0 =A0 =A0 Title=A0 =A0 =A0 =A0 =A0 =A0= : HTTP Digest Access Authentication
=A0 =A0 =A0 =A0 Authors=A0 =A0 =A0 =A0 =A0: = Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 David Ahrens
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Sophie Bremer
=A0 =A0 =A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-httpauth-digest-09.txt
=A0 =A0 =A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 =A0= : 31
=A0 =A0 =A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 = : 2014-12-09

Abstract:
=A0 =A0HTTP provides a simple challenge-response authentication mechanism
=A0 =A0that may be used by a server to challenge a client request and by a
=A0 =A0client to provide authentication information. This document defines
=A0 =A0the HTTP Digest Authentication scheme that may be used with the
=A0 =A0authentication mechanism.




The IETF datatracker status page for this draft is:
https://datatracker.ietf= .org/doc/draft-ietf-httpauth-digest/

There's also a htmlized version available at:
http://tools.ietf.org/ht= ml/draft-ietf-httpauth-digest-09

A diff from the previous version is available at:
http://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-httpauth-digest-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/inter= net-drafts/

_______________________________________________
http-auth mailing list
http-auth@ietf.org https://www.ietf.org/mai= lman/listinfo/http-auth

___________________________________________= ____
http-auth mailing list
http-auth@ietf.org<= br> https://www.ietf.org/mailman/l= istinfo/http-auth


--------------050108070406010906070802-- From nobody Thu Dec 11 06:04:54 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F77B1ACE64 for ; Thu, 11 Dec 2014 06:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J45TvTJsdx27 for ; Thu, 11 Dec 2014 06:04:50 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26F21A1A77 for ; Thu, 11 Dec 2014 06:04:49 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id q1so4314442lam.19 for ; Thu, 11 Dec 2014 06:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=72JCPxs2TFYDG30pMJa0whqT/9kviv+4ZJ6wEwyzN6A=; b=Ty+7mJLkiPgAPXXAoAxxKjVHnw1LKi8jqTiwSdtHKk14X3Op2WTO4S02CYw6rziVXO LOGAT92yXiP9cyGUmY0s6rERAbPlHO9gDdK6s45I3azS/1/JaKxaZu2Y4hztibDukv2n +FNiOW1TQ6xsqcG/gHkGlFRfGhJWZvOTyxRy57XqwtPJgP6iYE0KMRt/66ncNbsK40wH vYzOCyYliK0NJZfnRA5adTn/k7Lnv+5PtIxIepiFbwUEEVlBMtxvPrewBItisve8dGiY r3N05SneaG8EuaWIt0vHl+eh9QBZtPGYPmhILEzhrmmIso7wiJ0uObsrpmLjf7ng8/2V ZKuQ== MIME-Version: 1.0 X-Received: by 10.152.120.167 with SMTP id ld7mr9806262lab.77.1418306688069; Thu, 11 Dec 2014 06:04:48 -0800 (PST) Received: by 10.114.99.36 with HTTP; Thu, 11 Dec 2014 06:04:47 -0800 (PST) In-Reply-To: <5489A0F8.7000300@isode.com> References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <01074188-FCD7-4E76-9540-FC56E2B428D0@isode.com> <5489A0F8.7000300@isode.com> Date: Thu, 11 Dec 2014 09:04:47 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Alexey Melnikov Content-Type: multipart/alternative; boundary=089e012290f25335b40509f14218 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/suyhwxSJqHpIEpmkikqD-MWrlW8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 14:04:52 -0000 --089e012290f25335b40509f14218 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 11, 2014 at 8:49 AM, Alexey Melnikov wrote: > On 11/12/2014 13:20, Rifaat Shekh-Yusef wrote: > > Hi Alexey, > > Thanks for your review. > > I could not find a clear text in RFC2617 that requires the servers to > use the Authentication-Info header field. Can you please point to the text > that mandates the servers to use it? > > Mutual authentication property (which is an advertised feature of Digest) > is only available if the server sends Authentication-Info. > That is correct; if you want mutual authentication, then you must use Authentication-Info and you must use the rspauth parameter. But even the rspauth parameter is optional, because not all implementations use mutual authentication. See the following quote from RFC2617, section 3.2.3: The optional response digest in the "response-auth" directive supports mutual authentication -- the server proves that it knows the user's secret, and with qop=auth-int also provides limited integrity protection of the response. Regards, Rifaat > SASL DIGEST-MD5 (based on Digest) has the last response from the server as > mandatory. (Which doesn't quite prove this, but this is why I always > thought that it was mandatory.) > > I would like to get some feedback from implementors before declaring > Authentication-Info header optional. > > Regards, > Rifaat > > > > On Thu, Dec 11, 2014 at 5:34 AM, Alexey Melnikov < > alexey.melnikov@isode.com> wrote: > >> >> On 10 Dec 2014, at 01:30, Rifaat Shekh-Yusef >> wrote: >> >> Hi, >> >> We believe that with -09 we have addressed all the comment we received >> during the WGLC and during the meeting in Honolulu. >> We believe that the document is ready to go to the IESG. >> >> Please, take a look and let us know if you have any further comments. >> >> >> Hi Rifaat, >> I am mostly Ok with this version, but you made the Authentication-Info >> header field optional for Digest servers to return which I think is an >> incompatible change. Is there any evidence that servers don't return it? >> >> Regards, >> Rifaat >> >> >> On Tue, Dec 9, 2014 at 8:25 PM, wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Hypertext Transfer Protocol >>> Authentication Working Group of the IETF. >>> >>> Title : HTTP Digest Access Authentication >>> Authors : Rifaat Shekh-Yusef >>> David Ahrens >>> Sophie Bremer >>> Filename : draft-ietf-httpauth-digest-09.txt >>> Pages : 31 >>> Date : 2014-12-09 >>> >>> Abstract: >>> HTTP provides a simple challenge-response authentication mechanism >>> that may be used by a server to challenge a client request and by a >>> client to provide authentication information. This document defines >>> the HTTP Digest Authentication scheme that may be used with the >>> authentication mechanism. >>> >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-httpauth-digest-09 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-09 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >>> >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> >> > > --089e012290f25335b40509f14218 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 11, 2014 at 8:49 AM, Alexey Melnikov <= alexey.melni= kov@isode.com> wrote:
=20 =20 =20
On 11/12/2014 13:20, Rifaat Shekh-Yusef wrote:
Hi Alexey,

Thanks for your review.

I could not find a clear text in RFC2617 that requires the servers to use the Authentication-Info header field. Can you please point to the text that mandates the servers to use it?
Mutual authentication property (which is an advertised feature of Digest) is only available if the server sends Authentication-Info.

That is correct; if you want mutual = authentication, then you must use Authentication-Info and you must use the= =A0rspaut= h parameter.
But even the=A0rspauth parameter is optional, because no= t all implementations use mutual authentication.

<= div>See t= he following quote from RFC2617, section 3.2.3:

=A0 = =A0The optiona= l response digest in the "response-auth" directive
supports mutual= authentication -- the server proves that it knows the
user's secret, and with qop=3Da= uth-int also provides limited integrity
protection of the response.

=
Regards,
=A0Rifaat

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
SASL DIGEST-M= D5 (based on Digest) has the last response from the server as mandatory. (Which doesn't quite prove this, but this is why I always thought that it was mandatory.)

I would like to get some feedback from implementors before declaring Authentication-Info header optional.

Regards,
Rifaat



On Thu, Dec 11, 2014 at 5:34 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

On 10 Dec 2014, at 01:30, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com= > wrote:

Hi,

We believe that with -09 we have addressed all the comment we received during the WGLC and during the meeting in Honolulu.
We believe that the document is ready to go to the IESG.

Please, take a look and let us know if you have any further comments.

Hi Rifaat,
I am mostly Ok with this version, but you made the Authentication-Info header field optional for Digest servers to return which I think is an incompatible change. Is there any evidence that servers don't return it?

Regards,
=A0Rifaat


On Tue, Dec 9, 2014 at 8:25 PM, <internet-drafts@ietf.org= > wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories. =A0This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

=A0 =A0 =A0 =A0 Title=A0 =A0 =A0 =A0 =A0 = =A0: HTTP Digest Access Authentication
=A0 =A0 =A0 =A0 Authors=A0 =A0 =A0 =A0 =A0:= Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 David Ahrens
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 Sophie Bremer
=A0 =A0 =A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-httpauth-digest-09.txt
=A0 =A0 =A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 = =A0: 31
=A0 =A0 =A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0= : 2014-12-09

Abstract:
=A0 =A0HTTP provides a simple challenge-response authentication mechanism
=A0 =A0that may be used by a server to challenge a client request and by a
=A0 =A0client to provide authentication information. This document defines
=A0 =A0the HTTP Digest Authentication schem= e that may be used with the
=A0 =A0authentication mechanism.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.or= g/doc/draft-ietf-httpauth-digest/

There's also a htmlized version available at:
http://tools.ietf.org/html/draf= t-ietf-httpauth-digest-09

A diff from the previous version is available at:
http://www.ietf.org/rfc= diff?url2=3Ddraft-ietf-httpauth-digest-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/ht= tp-auth

__________________________________________= _____
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http= -auth



--089e012290f25335b40509f14218-- From nobody Fri Dec 12 07:06:50 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98CA1A8F50 for ; Fri, 12 Dec 2014 07:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_y947rYmTnE for ; Fri, 12 Dec 2014 07:06:42 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965C81A8F4E for ; Fri, 12 Dec 2014 07:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418396802; x=2282310402; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GIc1cWoqjT1vNZc9qdbYEDd7l8nWZ0kTfl3YJH9AgxY=; b=PXnKHgZNb5UvosbgzrjGG/N/1grSQGXX8susQWZfdIyeNp2JXqO2f4h6c3JGwZOe Fyl8uf1djSJySPzKn+Vz+ZwtqtLgLiNIpWbEEL9DJ160C4IK2XakAAgKXolHvWv7 YsdhLG6XJ6XOfaspY8gxjgP5TQChwh0zJwHiZlEVwYrmPdEaJwtPzuuAU0O5icCn xVDDh9rwGVoIvmVMXD81/XZh3n24jk0sb0Yl0jv1Be0oF5UmGpaO6rQnhu7RZp3Z IhcfKegWhQ6zo0z35lgae58UwPW8rQ/v03HFuL8UyYu0r/wmuMI/S/4ALk3M4ux/ dsvTln7rp01JMoNUDlZf2w==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id A5.71.06819.2840B845; Fri, 12 Dec 2014 07:06:42 -0800 (PST) X-AuditID: 11973e13-f79656d000001aa3-71-548b04827dc3 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id C9.1B.06123.3840B845; Fri, 12 Dec 2014 07:06:43 -0800 (PST) Received: from [17.153.58.214] by sesame.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGH00IRV5Z3C460@sesame.apple.com> for http-auth@ietf.org; Fri, 12 Dec 2014 07:06:41 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-type: multipart/signed; boundary="Apple-Mail=_B4536308-B76B-4C4E-8A7F-49D0216B97C0"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <5486EE3D.10507@cs.tcd.ie> Date: Fri, 12 Dec 2014 10:06:38 -0500 Message-id: <7866D906-5A25-4926-845A-7562E42A4370@apple.com> References: <20141209123810.18013.5085.idtracker@ietfa.amsl.com> <5486EE3D.10507@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUi2FAYodvE0h1icHoZu8WH/XOYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfTcAsaCmVkVjxdtYWlgfB7dxcjJISFgIjHx9A5GCFtM4sK9 9WxdjFwcQgJ7GSVa9x5l72LkACvaedsbIt7HJHGldwIzhPODUWLjt//MIN3CAi4SBy5sZgOx eQX0JJqePGYCKWIWmMIosaJ1JVgRm4CaxO9JfawgNqeAusSfA10sIDaLgKrE0+ePwWqYgc7o eHgJapCNxIEFG8BqhARiJVa9nAbWKyKgL7F38zl2iLNlJf5dPMMOskxCYA2bxKWV75gnMArN QnLILGSHzAJboi2xbOFrIJsDyNaRmLyQESJsKvHk7XY2CNta4uecR1BxRYkp3Q/ZFzCyr2IU yk3MzNHNzDPVSywoyEnVS87P3cQIionpdsI7GE+vsjrEKMDBqMTD+yK1K0SINbGsuDL3EKM0 B4uSOK9vL1BIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD48olV7/UC7fO/Fe28BwL2+Jzehv9 DhlYB6i12jyUURHUFK2cxp+Vqb1iqUONSPwh5pJlj6WSdzxMF/qp+P/pk3YR1Sd5yXb8K0v5 5N98Yi9+W891Iu7IKsGFga0H3+QkmHzu6c8x3v/ruMzdWCmPKa3XloR7nq5yZfv84lzaWWfD JbtuXxZJV2Ipzkg01GIuKk4EACEH0gNqAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUi2FDcoNvM0h1i8HqBjcWH/XOYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfTcAsaCmVkVjxdtYWlgfB7dxcjBISFgIrHztncXIyeQKSZx 4d56ti5GLg4hgT4miSu9E5ghnB+MEhu//WcGqRIWcJE4cGEzG4jNK6An0fTkMRNIEbPAFEaJ Fa0rwYrYBNQkfk/qYwWxOQXUJf4c6GIBsVkEVCWePn8MVsMMtK7j4SWoQTYSBxZsAKsREoiV WPVyGliviIC+xN7N59ghzpOV+HfxDPsERv5ZSHbPQrZ7FthcbYllC18D2RxAto7E5IWMEGFT iSdvt7NB2NYSP+c8goorSkzpfsi+gJF9FaNAUWpOYqWpXmJBQU6qXnJ+7iZGcAgXRuxg/L/M 6hCjAAejEg/vhOSuECHWxLLiytxDjCpAIx5tWH2BUYolLz8vVUmE928UUJo3JbGyKrUoP76o NCe1+BCjNAeLkjhvybvGECGB9MSS1OzU1ILUIpgsEwenVANj9/Zkl8mRqY68+1bwTDb3P2Te qMlVcOgw37WOx0r3mS3f7r6crF53Yedlfm/BDR6XZ0svLWm4XPFgdyuLhqhVhp0M40pL3Qd/ utxXpzvpL775invbsXATy9JGOb3nEWHbpd7IZ6evFPfIyfbclW7O8ZtpotrajvDYvYXzt8zX 9djhw5RU/VWJpTgj0VCLuag4EQB0NuESaQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/JRp0E0u49RZHpHPfaFq8Ks8Aw3A Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-hoba-07.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 15:06:48 -0000 --Apple-Mail=_B4536308-B76B-4C4E-8A7F-49D0216B97C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Stephen, Some comments for things I think should be resolved before this goes to = IETF LC: - In section 6.1.1 you say the values are "regok" and "reginwork", but = the ABNF and subsequent text use "regok" and "inwork". - Also in section 6.1.1, bottom of page 13 and top of page 14 you have: o Only one single value is allowed in a Hobareg header field. Should more than one (a list) be encountered, that should be interpreted as being the same as "inwork." Suggested rewording to fix grammar and use of 2119 conformance = terms: o Only a single value is allowed in a Hobareg header field. If the server receives a list of values, it SHOULD = interpret them as the same as "inwork." [or "reginwork", whichever is the correct one] o The Hobareg header field can only be used in HTTP responses. But you allow clients to send it in requests? o Since Hobareg is only meant for responses it ought not appear in a PUT request. How about listing the methods that MAY contain it as a request = header? And tie it/merge it with the previous bullet. o The HTTP response code does affect the interpretation of Hobareg. Registration is only considered to have succeeded if the regok value is seen in a 2xx response. 4xx and other errors means that registration has failed regardless of the value of Hobareg seen. The request method has no influence on the interpretation of Hobareg. Suggest you separate the Hobareg request header discussion = from the Hobareg response header. o Intermediaries should never insert, delete or modify a Hobareg header field. SHOULD? o As a response-only header field, it is not appropriate to list a Hobareg in a Vary response header field. Is this still true? o Hobareg is allowed in trailers. o As a response-only header field, Hobareg will not be preserved across re-directs. Is this still true? Or just true that the Hobareg response header is not preserved across redirects? o Hobareg itself discloses little security or privacy sensitive information. If an attacker can somehow detect that a Hobareg header field is being added, then that attacker would know that the UA is in the process of registration which could be significant. However, it is likely that the set of messages between the UA and server would expose this information in many cases, regardless of whether or not TLS is used. Using TLS is still however a good plan. TLS is RECOMMENDED? - In section 6.3 you say "The server MUST NOT allow TLS session = resumption for any logged out session." but you don't say why. - In section 6.4, you say the challenge is returned in the body of the = response. Is that sufficient, or do you want to say the response will = have a specific Content-Type and the body *is* the challenge with no = other data (other than whitespace)? - In section 8, how does one enforce conformance of hard-to-guess URLs? = Perhaps reword as "To make this more difficult, the server generates = hard to guess URLs and other values as part of any CPK binding = processes, for whatever level of difficulty chosen by the server." - Also in section 8, you state a conformance requirement for server = administrators. Perhaps "Server administrators can set the max-age ..." = instead of SHOULD. - In section 8.1, "we" are sending a key - reword as "the client/user = agent needs to send"? =20 > On Dec 9, 2014, at 7:42 AM, Stephen Farrell = wrote: >=20 >=20 > Hi all, >=20 > This I hope fixes the potential issue Watson identified by > adding a length: to each field in HOBA-TBS. >=20 > I also took the chance to update the examples to example.com > and not hoba-local.ie since they needed to change anyway > with the change to the bytes of HOBA-TBS. >=20 > So from my POV I think this is ready for IETF LC now once > the chairs post the write up and Kathleen hits the button. >=20 > Thanks, > S. >=20 > PS: I've updated my code enough to test this and re-generate > the examples but haven't yet commited that back to the > repo. Will try get to that in the next day or so. >=20 > On 09/12/14 12:38, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Hypertext Transfer Protocol = Authentication Working Group of the IETF. >>=20 >> Title : HTTP Origin-Bound Authentication (HOBA) >> Authors : Stephen Farrell >> Paul Hoffman >> Michael Thomas >> Filename : draft-ietf-httpauth-hoba-07.txt >> Pages : 25 >> Date : 2014-12-09 >>=20 >> Abstract: >> HTTP Origin-Bound Authentication (HOBA) is a digital signature = based >> design for an HTTP authentication method. The design can also be >> used in Javascript-based authentication embedded in HTML. HOBA is = an >> alternative to HTTP authentication schemes that require passwords = and >> therefore avoids all problems related to passwords, such as leakage >> of server-side password databases. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-httpauth-hoba-07 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-hoba-07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >>=20 >>=20 >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_B4536308-B76B-4C4E-8A7F-49D0216B97C0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO0jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUiMIIECqADAgECAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzEyMTcw MDAwMDBaFw0xNDEyMTcyMzU5NTlaMCExHzAdBgkqhkiG9w0BCQEWEG1zd2VldEBhcHBsZS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDXb0GGUQlc3NMCGLyDp/9D7+81MLiL2wHz P1txcnpqmcd33SsV+FsTdseTQt4YQRxq1FoqyR+65eiLddmxkOtbhwCuY7CYpFeZPpjmI2WijSCs Y9LmCJNzCkJrJjPLd53XauZqdpscFf1OwBT089X4IXZKk2/zZB2OXgPCqpLGnqsHzIKGohlXglIa bVp16LHGvDwJG/ovbuaxKJOc4GPkD9CLliyRDXwOKnRDLB/jgMDBjr/XzQoHHWqRZ43kmGo+9Juq lIquOOvvGtq4VLBFCkGsjjII55tm4FLjce6Tr7PyYMyJWaE8/5ZZhNR1kRBs0o0Zy1sEPfH7KX3m VgPvAgMBAAGjggHgMIIB3DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4E FgQU7SgSaBvZMWYrE6iYOPsK9dpeLLYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYD VR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAE PzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8u bmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHow UgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9k b2NhLmNvbTAbBgNVHREEFDASgRBtc3dlZXRAYXBwbGUuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAY OSi0CubvYBiO+bvr2B/4urjAypaUyCzv6/xaTdom6qcAAdpZ/aCrzyANf696PgwQvO06p5SQIj1u AAxR6UZqpaa29E7vaffJz/8JebQWYxD/HWOIh9Ewdwdq/SR8EcMCUNtAqiabgp/XZry9tebGUqry X5blZSHAEAi8ad2SjCAtqTSorbMHY4x3bmiro9kzHsa8zLa0RkbRRfaXDHJ7KhNkLSVKlz1e/zOF k9skVJiOE4T7fTvX5jx9pLudoXW+reKl78HUEpAx7caNyf1XP4w0dv33nnQ4UJhtFfY+rR7Lhum1 VYXBolp0pkqD34NdxZUMJcWU8hbYjGdoyC8qMYIDrjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMAkGBSsOAwIaBQCgggHZMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTIxMjE1MDYzOVowIwYJ KoZIhvcNAQkEMRYEFO6I6B6UbX3Dg5w5NceovHEBFzKTMIG6BgkrBgEEAYI3EAQxgawwgakwgZMx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMIG8Bgsq hkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNV BAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUH t1fFyUsR52q4+8ZfwIYwDQYJKoZIhvcNAQEBBQAEggEAdgf2Vw08mKCK1ctAE8jYjSVspNRa8QHl skjxvMX8xPuSL6h3bpsnjGcPZo2DGrAiQdi7xARaTeoK4tyYJMTRQArGNrYKmwwtdCJEEFWUlaoV 6xKiEQvqcgBoydmOo/sDJfiB1hah7oLoVFs6KbIgClT4PR6KCFbGgdbuCFqJFzCzmjCg6EaOGtG9 S0I0IVP3FdccFMvKtX4yPujrvsm8q/pqq0Vxxlfuo5AxY7MZ+JbVegdpxjHIoXQgT3Yb0qPN2L8F PMg/O0kstmOuwMdFnA0CSPXpWeCporUuhp+DqahSNYSFk0Ne5bEE4J/JFmOdppuAUta9DoDnIY1C 59L3lgAAAAAAAA== --Apple-Mail=_B4536308-B76B-4C4E-8A7F-49D0216B97C0-- From nobody Fri Dec 12 07:26:58 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF981A8A15 for ; Fri, 12 Dec 2014 07:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAAGsjHOQUNY for ; Fri, 12 Dec 2014 07:26:54 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A988F1A6FF3 for ; Fri, 12 Dec 2014 07:26:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7E9DDBEBF; Fri, 12 Dec 2014 15:26:51 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yCPnzoReHEA; Fri, 12 Dec 2014 15:26:48 +0000 (GMT) Received: from [10.43.49.179] (unknown [193.190.253.145]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A7389BE13; Fri, 12 Dec 2014 15:26:48 +0000 (GMT) Message-ID: <548B0938.3060805@cs.tcd.ie> Date: Fri, 12 Dec 2014 15:26:48 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Michael Sweet References: <20141209123810.18013.5085.idtracker@ietfa.amsl.com> <5486EE3D.10507@cs.tcd.ie> <7866D906-5A25-4926-845A-7562E42A4370@apple.com> In-Reply-To: <7866D906-5A25-4926-845A-7562E42A4370@apple.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/rq4y9KUrvnzmUxZjhrV6lj5DGB0 Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-hoba-07.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 15:26:57 -0000 Hi Michael, The IETF LC has started but these are fine IETF LC comments:-) I'm heading for an airport now but will get back in a day or so. Thanks, S. On 12/12/14 15:06, Michael Sweet wrote: > Stephen, > > Some comments for things I think should be resolved before this goes to IETF LC: > > - In section 6.1.1 you say the values are "regok" and "reginwork", but the ABNF and subsequent text use "regok" and "inwork". > > - Also in section 6.1.1, bottom of page 13 and top of page 14 you have: > > o Only one single value is allowed in a Hobareg header field. > Should more than one (a list) be encountered, that should be > interpreted as being the same as "inwork." > > Suggested rewording to fix grammar and use of 2119 conformance terms: > > o Only a single value is allowed in a Hobareg header field. > If the server receives a list of values, it SHOULD interpret them > as the same as "inwork." > > [or "reginwork", whichever is the correct one] > > > o The Hobareg header field can only be used in HTTP responses. > > But you allow clients to send it in requests? > > > o Since Hobareg is only meant for responses it ought not appear in a > PUT request. > > How about listing the methods that MAY contain it as a request header? > And tie it/merge it with the previous bullet. > > > o The HTTP response code does affect the interpretation of Hobareg. > Registration is only considered to have succeeded if the regok > value is seen in a 2xx response. 4xx and other errors means that > registration has failed regardless of the value of Hobareg seen. > The request method has no influence on the interpretation of > Hobareg. > > Suggest you separate the Hobareg request header discussion from the > Hobareg response header. > > > o Intermediaries should never insert, delete or modify a Hobareg > header field. > > SHOULD? > > > o As a response-only header field, it is not appropriate to list a > Hobareg in a Vary response header field. > > Is this still true? > > > o Hobareg is allowed in trailers. > > o As a response-only header field, Hobareg will not be preserved > across re-directs. > > Is this still true? Or just true that the Hobareg response > header is not preserved across redirects? > > > o Hobareg itself discloses little security or privacy sensitive > information. If an attacker can somehow detect that a Hobareg > header field is being added, then that attacker would know that > the UA is in the process of registration which could be > significant. However, it is likely that the set of messages > between the UA and server would expose this information in many > cases, regardless of whether or not TLS is used. Using TLS is > still however a good plan. > > TLS is RECOMMENDED? > > - In section 6.3 you say "The server MUST NOT allow TLS session resumption for any logged out > session." but you don't say why. > > - In section 6.4, you say the challenge is returned in the body of the response. Is that sufficient, or do you want to say the response will have a specific Content-Type and the body *is* the challenge with no other data (other than whitespace)? > > - In section 8, how does one enforce conformance of hard-to-guess URLs? Perhaps reword as "To make this more difficult, the server generates hard to guess URLs and other values as part of any CPK binding processes, for whatever level of difficulty chosen by the server." > > - Also in section 8, you state a conformance requirement for server administrators. Perhaps "Server administrators can set the max-age ..." instead of SHOULD. > > - In section 8.1, "we" are sending a key - reword as "the client/user agent needs to send"? > > > > >> On Dec 9, 2014, at 7:42 AM, Stephen Farrell wrote: >> >> >> Hi all, >> >> This I hope fixes the potential issue Watson identified by >> adding a length: to each field in HOBA-TBS. >> >> I also took the chance to update the examples to example.com >> and not hoba-local.ie since they needed to change anyway >> with the change to the bytes of HOBA-TBS. >> >> So from my POV I think this is ready for IETF LC now once >> the chairs post the write up and Kathleen hits the button. >> >> Thanks, >> S. >> >> PS: I've updated my code enough to test this and re-generate >> the examples but haven't yet commited that back to the >> repo. Will try get to that in the next day or so. >> >> On 09/12/14 12:38, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. >>> >>> Title : HTTP Origin-Bound Authentication (HOBA) >>> Authors : Stephen Farrell >>> Paul Hoffman >>> Michael Thomas >>> Filename : draft-ietf-httpauth-hoba-07.txt >>> Pages : 25 >>> Date : 2014-12-09 >>> >>> Abstract: >>> HTTP Origin-Bound Authentication (HOBA) is a digital signature based >>> design for an HTTP authentication method. The design can also be >>> used in Javascript-based authentication embedded in HTML. HOBA is an >>> alternative to HTTP authentication schemes that require passwords and >>> therefore avoids all problems related to passwords, such as leakage >>> of server-side password databases. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-httpauth-hoba-07 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-07 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >>> >>> >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > From nobody Sun Dec 14 08:26:06 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378671A00E5 for ; Sun, 14 Dec 2014 08:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReQR_B2vokK5 for ; Sun, 14 Dec 2014 08:25:50 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id E722B1A006D for ; Sun, 14 Dec 2014 08:25:49 -0800 (PST) Received: from [192.168.2.160] (unknown [93.217.117.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 8271C15A01E4; Sun, 14 Dec 2014 17:25:47 +0100 (CET) Message-ID: <548DBA0B.6080201@greenbytes.de> Date: Sun, 14 Dec 2014 17:25:47 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , "http-auth@ietf.org" References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/NvnWsp_dKxAYAKnaE_BGc2m0yUA Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 16:26:05 -0000 Hi there, it's the first time I read this in a long time; apologies for the lack of structure; and also that most of these should have been made during WGLC. Abstract HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that may be used with the authentication mechanism. s/may/can/ Also maybe: ...that can used with the *HTTP* authentication mechanism. 1 Introduction HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that may be used with the authentication mechanism. (see above) The details of the challenge-response authentication mechanism are specified in the [RFC7235] document. ...in "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235]. The combination of this document with Basic [BASIC] and [RFC7235] obsolete RFC2617. s/Basic/the definition of the "Basic" authentication scheme/ s/RFC2617/RFC 2617/ 2.2 Algorithm Variants When used with the Digest mechanism, each one of the algorithms has two variants: Session variant and non-Session variant. The non-Session variant is denoted by "", e.g. "SHA-256", and the Session variant is denoted by "-sess", e.g. "SHA- 256-sess". This comes very early; maybe it would be better mentioned later on. 2.3 ABNF This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. Actually, you'll also need (see below later). realm A string to be displayed to users so they know which username and password to use. This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An example might be "registered_users@gotham.news.com". (See section 2.2 of [RFC7235] for more details). s/section/Section/ For the host name part, see . domain A quoted, space-separated list of URIs, as specified in RFC 3986 [RFC3986], that define the protection space. If a URI is an abs_path, it is relative to the canonical root URL of the web- origin. An absolute-URI in this list may refer to a different server than the web-origin. The client can use this list to determine the set of URIs for which the same authentication information may be sent: any URI that has a URI in this list as a s/may/can/ or MAY prefix (after both have been made absolute) may be assumed to be in the same protection space. If this parameter is omitted or its value is empty, the client SHOULD assume that the protection space consists of all URIs on the web-origin. All URIs in this list SHOULD use the same scheme (https or http); mixing them is a bad idea. web_origin and canonical root need definitions. Why is mixing them a "bad idea"? - maybe this could be explained better. This parameter is not meaningful in Proxy-Authenticate header fields, for which the protection space is always the entire proxy; if present it should be ignored. MUST? SHOULD? nonce A server-specified data string which should be uniquely generated each time a 401 response is made. It is recommended that this RECOMMENDED? Would there be a problem if it is a differen format? If no, why a normative requirement here? string be base64 or hexadecimal data. Specifically, since the string is passed in the header field lines as a quoted string, the double-quote character is not allowed. well, unless suitably escaped. The contents of the nonce are implementation dependent. The s/are/is/? quality of the implementation depends on a good choice. A nonce might, for example, be constructed as the base 64 encoding of time-stamp H(time-stamp ":" ETag ":" secret-data) where time-stamp is a server-generated time, which preferably s/value/values/ includes micro or nano seconds, or other non-repeating value, ETag is the value of the HTTP ETag header field associated with the requested entity, and secret-data is data known only to the server. With a nonce of this form a server would recalculate the hash portion after receiving the client authentication header field and reject the request if it did not match the nonce from that header field or if the time-stamp value is not recent enough. In this way the server can limit the time of the nonce's validity. The inclusion of the ETag prevents a replay request for an updated version of the resource. Including the IP address of the client in the nonce would appear to offer the server the ability to limit the reuse of the nonce to the same client that originally got it. However, that would break proxy farms, where requests from a single user often go through different proxies in the farm. Also, IP address spoofing is not that hard. Do you need a proxy *farm* for this problem? An implementation might choose not to accept a previously used nonce or a previously used digest, in order to protect against a replay attack. Or, an implementation might choose to use one-time nonces or digests for POST or PUT requests and a time-stamp for GET requests. For more details on the issues involved see section 5 of this document. s/section/Section/ ...why are these lowercase; aren't they generated by xml2rfc? If not, they should, because otherwise they break too easily. The nonce is opaque to the client. opaque A string of data, specified by the server, which SHOULD be returned by the client unchanged in the Authorization header field of subsequent requests with URIs in the same protection space. It is RECOMMENDED that this string be base64 or hexadecimal data. (see above) stale A case-insensitive flag indicating that the previous request from the client was rejected because the nonce value was stale. If stale is TRUE, the client MAY wish to simply retry the request "MAY wish" doesn't seem like a case for a BCP14 keyword. with a new encrypted response, without re-prompting the user for a new username and password. The server SHOULD only set stale to TRUE if it receives a request for which the nonce is invalid. If stale is FALSE, or anything other than TRUE, or the stale parameter is not present, the username and/or password are invalid, and new values MUST be obtained. algorithm A string indicating a pair of algorithms used to produce the digest and a checksum. If this is not present it is assumed to be "MD5". If the algorithm is not understood, the challenge should be ignored (and a different one used, if there is more than one). Avoid lowercase BCP14 keywords. Either uppercase or choose something else (here and later on). userhash This is an OPTIONAL parameter that is used by the server to indicate that it supports username hashing. Valid values are: "true" or "false". Defaults to false, I assume. 3.4 The Authorization Request Header s/header/header field/ The client is expected to retry the request, passing an Authorization header field line with Digest scheme, which is defined according to the framework above. The values of the opaque and algorithm fields must be those supplied in the WWW- Authenticate response header field for the entity being requested. The request includes some or all of the following parameters: "some or all" reads weird... uri The URI from request-target of the Request-Line; duplicated here because proxies are allowed to change the Request-Line in transit. The request-target of the Request-Line isn't necessarily a URI... qop Indicates what "quality of protection" the client has applied to the message. Its value MUST be one of the alternatives the server indicated it supports in the WWW-Authenticate header field. These values affect the computation of the response. Note that this is a single token, not a quoted list of alternatives as in WWW- Authenticate. Can it use quoted-string nevertheless? nc This parameter MUST be used by all implementations compliant with this version of the Digest scheme. The "nc" parameter stands for I wonder why we need to say "compliant with this version"? userhash This OPTIONAL parameter is used by the client to indicate that the username has been hashed. Valid values are: "true" or "false". Default? If a parameter or its value is improper, or required parameters are missing, the proper response is 400 Bad Request. If the request- Is this a requirement? Could it be a more specifc 4xx code? digest is invalid, then a login failure should be logged, since repeated login failures from a single client may indicate an attacker attempting to guess passwords. The server implementation should be SHOULD? careful with the information being logged so that it won't put a cleartext password (e.g. entered into the username field) into the log. The definition of response above indicates the encoding for its s/of/of the/ value. The following definitions show how the value is computed. This creates a 'session key' for the authentication of subsequent double quotes? requests and responses which is different for each "authentication session", thus limiting the amount of material hashed with any one key. (Note: see further discussion of the authentication session in section 3.6.) Because the server need only use the hash of the user s/need/needs/ credentials in order to create the A1 value, this construction could be used in conjunction with a third party authentication service so that the web server would not need the actual password value. The specification of such a protocol is beyond the scope of this specification. Also note that if integrity protection is applied (qop=auth-int), the H(entity-body) is the hash of the entity body, not the message body - it is computed before any transfer encoding is applied by the sender and after it has been removed by the recipient. Note that this includes multipart boundaries and embedded header fields in each part of any multipart content-type. (reduce amout of "note that"...) 3.4.6 Various Considerations The "Method" value is the HTTP request method, in all-uppercase US- ASCII letters, as specified in section 3.1.1 of [RFC7230]. The Hm, no. The registered methods happen to be all-uppercase, but method names are case-sensitive. Implementers should be aware of how authenticated transactions ...need to be... interact with shared caches. The HTTP/1.1 protocol specifies that s/The HTTP/1.1 protocol/HTTP/ when a shared cache (see [RFC7234]) has received a request containing an Authorization header field and a response from relaying that request, it MUST NOT return that response as a reply to any other request, unless one of two Cache-Control (see section 3.2 of [RFC7234]) directive was present in the response. If the original response included the "must-revalidate" Cache-Control directive, the cache MAY use the entity of that response in replying to a subsequent request, but MUST first revalidate it with the origin server, using the request header fields from the new request to allow the origin server to authenticate the new request. Alternatively, if the original response included the "public" Cache-Control directive, the response entity MAY be returned in reply to any subsequent request. Do we need to replicate this information here? (Asking because the Basic spec does not) 3.5 The Authentication-Info Header The Authentication-Info header field is a generic field that MAY be used by a server to communicate some information regarding the successful authentication of a client response. The following is the syntax of the header: Authentication-Info = auth-info auth-info = *auth-param This needs to be "#auth-param" and invoke the list ABNF extension from RFC 7230. The auth-param is defined in [RFC7235]. (I still believe we should extract this into a separate spec) 3.5.1 Digest Usage of Authentication-Info The Digest authentication scheme MAY add the Authentication-Info header field in the confirmation request with some or all of the following parameters: "Some or all" reads weird. 3.6 Digest Operation Upon receiving the Authorization header field, the server MAY check its validity by looking up the password that corresponds to the submitted username. Then, the server MUST perform the same digest operation (e.g. MD5, SHA-256) performed by the client, and compare the result to the given response value. Note that the HTTP server does not actually need to know the user's cleartext password. As long as H(A1) is available to the server, the validity of an Authorization header field MAY be verified. s/MAY/can/ Because the client is required to return the value of the opaque s/required/REQUIRED/ parameter given to it by the server for the duration of a session, the opaque data MAY be used to transport authentication session state s/MAY/can/ information. (Note that any such use can also be accomplished more easily and safely by including the state in the nonce.) For example, a server could be responsible for authenticating content that actually sits on another server. It would achieve this by having the first 401 response include a domain parameter whose value includes a URI on the second server, and an opaque parameter whose value contains the state information. The client will retry the request, at which time the server might respond with a 301/302 redirection, Do not exclude 307/308. Just say "HTTP Redirection (Section 6.4 of [RFC7231])" As with the basic scheme, proxies MUST be completely transparent in s/basic/"Basic"/ Is it wise to cite that hear? the Digest access authentication scheme. That is, they MUST forward the WWW-Authenticate, Authentication-Info and Authorization header fields untouched. If a proxy wants to authenticate a client before a request is forwarded to the server, it can be done using the Proxy- Authenticate and Proxy-Authorization header fields described in section 3.8 below. 3.7 Security Protocol Negotiation It is useful for a server to be able to know which security schemes a client is capable of handling. It is possible that a server MAY want to require Digest as its s/MAY want/wants/ authentication method, even if the server does not know that the client supports it. A client is encouraged to fail gracefully if the server specifies only authentication schemes it cannot handle. When a server receives a request to access a resource, the server might challenge the client by responding with "401 Unauthorized" status code, and include one or more WWW-Authenticate header fields. s/status code/response/ If the server challenges with multiple Digest header fields, then each one of these header fields MUST use a different digest You could have multiple challenges in a single header field instance. algorithm. The server MUST add these Digest header fields to the response in order of preference, starting with the most preferred header field, followed by the less preferred header fields. most preferred algorithm? When the client receives the response it SHOULD use the topmost header field that it supports, unless a local policy dictates First challenge. otherwise. The client SHOULD ignore any challenge it does not understand. MUST, I believe. Also, this sounds like requirements that are generic to WWW-A, not specific to Digest, no? 3.8 Proxy-Authenticate and Proxy-Authorization The digest authentication scheme MAY also be used for authenticating s/MAY/can/ users to proxies, proxies to proxies, or proxies to origin servers by use of the Proxy-Authenticate and Proxy-Authorization header fields. These header fields are instances of the Proxy-Authenticate and Proxy- Authorization header fields specified in sections 4.2 and 4.3 s/Proxy- Authorization/Proxy-Authorization/ of the HTTP/1.1 specification [RFC7235] and their behavior is subject to restrictions described there. The transactions for proxy authentication are very similar to those already described. Upon receiving a request which requires authentication, the proxy/server MUST issue the "407 Proxy Authentication Required" response with a "Proxy-Authenticate" header field. The digest-challenge used in the Proxy-Authenticate header field is the same as that for the WWW- Authenticate header field as defined above in section 3.2.1. I don't see a Section 3.2.1. 3.9 Examples 3.9.1 Example with SHA-256 and MD5 The following example assumes that an access protected document is being requested from the server via a GET request. The URI of the document is http://www.nowhere.org/dir/index.html". Both client and server know that the username for this document is "Mufasa" and the password is "Circle of Life" ( with one space between each of the three words). Need to use RFC 2606 hostnames. The first time the client requests the document, no Authorization header field is sent, so the server responds with: HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="http-auth@example.org", qop="auth, auth-int", algorithm="SHA-256", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" WWW-Authenticate: Digest realm="http-auth@example.org", qop="auth, auth-int", algorithm="MD5", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" The client MAY prompt the user for their username and password, after s/MAY/can/ or /will/ Maybe also point out that you could also send...: WWW-Authenticate: Digest realm="http-auth@example.org", qop="auth, auth-int", algorithm="SHA-256", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS", Digest realm="http-auth@example.org", qop="auth, auth-int", algorithm="MD5", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" Later: Authorization:Digest username="Mufasa", insert an SP after the colon. realm="http-auth@example.org", uri="/dir/index.html", algorithm=MD5, nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", nc=00000001, cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ", qop=auth, response="8ca523f5e9506fed4657c9700eebdbec", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" If the client chooses to use the SHA-256 algorithm for calculating the response, the client responds with a new request including the following Authorization header field: Authorization:Digest username="Mufasa", realm="http-auth@example.org", uri="/dir/index.html", algorithm=SHA-256, nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", nc=00000001, cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ", qop=auth, response="753927fa0e85d155564e2e272a28d1802ca10daf449 6794697cf8db5856cb6c1", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" 3.9.2 Example with SHA-512-256, Charset, and Userhash The following example assumes that an access protected document is being requested from the server via a GET request. The URI for the request is "http://api.example.org/doe.json". Both client and server know the userhash of the username, support the UTF-8 charset, and use s/UTF-8 charset/UTF-8 character encoding scheme/ the SHA-512-256 algorithm. The username for the request is "Jason Doe" and the password is "Secret, or not?". It would be good to have non-ASCII characters in the example. The first time the client requests the document, no Authorization header field is sent, so the server responds with: HTTP/2.0 401 Unauthorized HTTP/2.0???? WWW-Authenticate: Digest realm="api@example.org", qop=auth, algorithm=SHA-512-256, nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", charset=UTF-8, userhash=true The client MAY prompt the user for the required credentials and send a new request with following Authorization header field: Authorization: Digest username="488869477bf257147b804c45308cd62ac4e25eb717 b12b298c79e62dcea254ec", realm="api@example.org", uri="/doe.json", algorithm=SHA-512-256, nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", nc=00000001, cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v", qop=auth, response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d 6c861229025f607a79dd", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", userhash=true If the client can not provide a hashed username for any reason, the client MAY try a request with this Authorization header field: Authorization: Digest username*=UTF-8''J%C3%A4s%C3%B8n%20Doe, realm="api@example.org", uri="/doe.json", algorithm=SHA-512-256, nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", nc=00000001, cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v", qop=auth, response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d6 c861229025f607a79dd", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", userhash=false Wait, you can't do that. You'll need to formally state that some or all of your auth-params can be sent using the RFC 5987 encoding (and upfront, not in the example here). For the username, recipients MUST support all characters defined in the "UsernameCasePreserved" profile defined in in Section 3.3 of [PRECIS], with the exception of the colon (":") character. This is copied from Basic. Is it true for Digest as well? If the user agent does not support the encoding indicated by the server, it MUST fail the request. That sounds like a deployment problem. Also it reads weird given the fact that only one value ("UTF-8") is allowed. 5.6 Weakness Created by Multiple Authentication Schemes An HTTP/1.1 server MAY return multiple challenges with a 401 (Authenticate) response, and each challenge MAY use a different auth- scheme. A user agent MUST choose to use the strongest auth- scheme it s/auth- scheme/auth-scheme/ understands and request credentials from the user based upon that challenge. Note that many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should only s/should/SHOULD/ include Basic if it is minimally acceptable. When the server offers choices of authentication schemes using the WWW-Authenticate header field, the strength of the resulting authentication is only as good as that of the of the weakest of the authentication schemes. See section 5.7 below for discussion of particular attack scenarios that exploit multiple authentication schemes. 5.8 Man in the Middle Both Basic and Digest authentication are vulnerable to "man in the middle" (MITM) attacks, for example, from a hostile or compromised proxy. Clearly, this would present all the problems of eavesdropping. But it also offers some additional opportunities to the attacker. The Digest spec shouldn't talk about "Basic". And it seems that there's a security consideration I dropped from 2617 and which I need to include into the Basic spec. 5.12 Spoofing by Counterfeit Servers Basic Authentication is vulnerable to spoofing by counterfeit servers. If a user can be led to believe that she is connecting to a ...this section doesn't belong here. 6.2 Digest Scheme Registration This specification registers the Digest scheme with the Authentication Scheme Registry. Authentication Scheme Name: Digest Pointer to specification text: RFCXXX s/RFCXXXX/this specification/ 7 Acknowledgments The authors of this document would like to thank the authors of RFC2617, as this document heavily borrows text from their document to provide a complete description of the digest scheme and its operations. s/RFC2617/RFC 2617/ 8 References 8.1 Normative References [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006. doesn't seem to be normative. [BASIC] Reschke, J., "The 'Basic' HTTP Authentication Scheme", draft-ietf-httpauth-basicauth-update (Work in Progress), September 2013. Needs update. Also shouldn't be normative. Best regards, Julian From nobody Sun Dec 14 08:26:30 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760191A00EA for ; Sun, 14 Dec 2014 08:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MG8Xin-1LtFj for ; Sun, 14 Dec 2014 08:26:24 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D651A006D for ; Sun, 14 Dec 2014 08:26:24 -0800 (PST) Received: from [192.168.2.160] ([93.217.117.235]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MUHoI-1YRAnX1L0M-00R48c; Sun, 14 Dec 2014 17:26:21 +0100 Message-ID: <548DBA2D.2010808@gmx.de> Date: Sun, 14 Dec 2014 17:26:21 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , "http-auth@ietf.org" References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:GvgiiabSWB+YStVM4hysky8skRrTEwl8f7AiWtbXWnHg96vpVUe gCz6siG8ilO4wn5IfO52QvlNRYqcTohub/rfI7fHm1cz5HgdjBtoCquBUbRIVVB/J1Vymzm 2KMwIv+ciAYZ7y8CnDtqp+K4YV+A3OFJVunFaAv1akIjhd4twUxl822piZCZy/bMw0irNDW 4Q4CMzeYoZVb1bnPRrTNw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Y5OETy-zK2I7kO6a4IQJdA34CEM Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 16:26:29 -0000 Hi there, it's the first time I read this in a long time; apologies for the lack of structure; and also that most of these should have been made during WGLC. Abstract HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that may be used with the authentication mechanism. s/may/can/ Also maybe: ...that can used with the *HTTP* authentication mechanism. 1 Introduction HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that may be used with the authentication mechanism. (see above) The details of the challenge-response authentication mechanism are specified in the [RFC7235] document. ...in "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235]. The combination of this document with Basic [BASIC] and [RFC7235] obsolete RFC2617. s/Basic/the definition of the "Basic" authentication scheme/ s/RFC2617/RFC 2617/ 2.2 Algorithm Variants When used with the Digest mechanism, each one of the algorithms has two variants: Session variant and non-Session variant. The non-Session variant is denoted by "", e.g. "SHA-256", and the Session variant is denoted by "-sess", e.g. "SHA- 256-sess". This comes very early; maybe it would be better mentioned later on. 2.3 ABNF This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. Actually, you'll also need (see below later). realm A string to be displayed to users so they know which username and password to use. This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An example might be "registered_users@gotham.news.com". (See section 2.2 of [RFC7235] for more details). s/section/Section/ For the host name part, see . domain A quoted, space-separated list of URIs, as specified in RFC 3986 [RFC3986], that define the protection space. If a URI is an abs_path, it is relative to the canonical root URL of the web- origin. An absolute-URI in this list may refer to a different server than the web-origin. The client can use this list to determine the set of URIs for which the same authentication information may be sent: any URI that has a URI in this list as a s/may/can/ or MAY prefix (after both have been made absolute) may be assumed to be in the same protection space. If this parameter is omitted or its value is empty, the client SHOULD assume that the protection space consists of all URIs on the web-origin. All URIs in this list SHOULD use the same scheme (https or http); mixing them is a bad idea. web_origin and canonical root need definitions. Why is mixing them a "bad idea"? - maybe this could be explained better. This parameter is not meaningful in Proxy-Authenticate header fields, for which the protection space is always the entire proxy; if present it should be ignored. MUST? SHOULD? nonce A server-specified data string which should be uniquely generated each time a 401 response is made. It is recommended that this RECOMMENDED? Would there be a problem if it is a differen format? If no, why a normative requirement here? string be base64 or hexadecimal data. Specifically, since the string is passed in the header field lines as a quoted string, the double-quote character is not allowed. well, unless suitably escaped. The contents of the nonce are implementation dependent. The s/are/is/? quality of the implementation depends on a good choice. A nonce might, for example, be constructed as the base 64 encoding of time-stamp H(time-stamp ":" ETag ":" secret-data) where time-stamp is a server-generated time, which preferably s/value/values/ includes micro or nano seconds, or other non-repeating value, ETag is the value of the HTTP ETag header field associated with the requested entity, and secret-data is data known only to the server. With a nonce of this form a server would recalculate the hash portion after receiving the client authentication header field and reject the request if it did not match the nonce from that header field or if the time-stamp value is not recent enough. In this way the server can limit the time of the nonce's validity. The inclusion of the ETag prevents a replay request for an updated version of the resource. Including the IP address of the client in the nonce would appear to offer the server the ability to limit the reuse of the nonce to the same client that originally got it. However, that would break proxy farms, where requests from a single user often go through different proxies in the farm. Also, IP address spoofing is not that hard. Do you need a proxy *farm* for this problem? An implementation might choose not to accept a previously used nonce or a previously used digest, in order to protect against a replay attack. Or, an implementation might choose to use one-time nonces or digests for POST or PUT requests and a time-stamp for GET requests. For more details on the issues involved see section 5 of this document. s/section/Section/ ...why are these lowercase; aren't they generated by xml2rfc? If not, they should, because otherwise they break too easily. The nonce is opaque to the client. opaque A string of data, specified by the server, which SHOULD be returned by the client unchanged in the Authorization header field of subsequent requests with URIs in the same protection space. It is RECOMMENDED that this string be base64 or hexadecimal data. (see above) stale A case-insensitive flag indicating that the previous request from the client was rejected because the nonce value was stale. If stale is TRUE, the client MAY wish to simply retry the request "MAY wish" doesn't seem like a case for a BCP14 keyword. with a new encrypted response, without re-prompting the user for a new username and password. The server SHOULD only set stale to TRUE if it receives a request for which the nonce is invalid. If stale is FALSE, or anything other than TRUE, or the stale parameter is not present, the username and/or password are invalid, and new values MUST be obtained. algorithm A string indicating a pair of algorithms used to produce the digest and a checksum. If this is not present it is assumed to be "MD5". If the algorithm is not understood, the challenge should be ignored (and a different one used, if there is more than one). Avoid lowercase BCP14 keywords. Either uppercase or choose something else (here and later on). userhash This is an OPTIONAL parameter that is used by the server to indicate that it supports username hashing. Valid values are: "true" or "false". Defaults to false, I assume. 3.4 The Authorization Request Header s/header/header field/ The client is expected to retry the request, passing an Authorization header field line with Digest scheme, which is defined according to the framework above. The values of the opaque and algorithm fields must be those supplied in the WWW- Authenticate response header field for the entity being requested. The request includes some or all of the following parameters: "some or all" reads weird... uri The URI from request-target of the Request-Line; duplicated here because proxies are allowed to change the Request-Line in transit. The request-target of the Request-Line isn't necessarily a URI... qop Indicates what "quality of protection" the client has applied to the message. Its value MUST be one of the alternatives the server indicated it supports in the WWW-Authenticate header field. These values affect the computation of the response. Note that this is a single token, not a quoted list of alternatives as in WWW- Authenticate. Can it use quoted-string nevertheless? nc This parameter MUST be used by all implementations compliant with this version of the Digest scheme. The "nc" parameter stands for I wonder why we need to say "compliant with this version"? userhash This OPTIONAL parameter is used by the client to indicate that the username has been hashed. Valid values are: "true" or "false". Default? If a parameter or its value is improper, or required parameters are missing, the proper response is 400 Bad Request. If the request- Is this a requirement? Could it be a more specifc 4xx code? digest is invalid, then a login failure should be logged, since repeated login failures from a single client may indicate an attacker attempting to guess passwords. The server implementation should be SHOULD? careful with the information being logged so that it won't put a cleartext password (e.g. entered into the username field) into the log. The definition of response above indicates the encoding for its s/of/of the/ value. The following definitions show how the value is computed. This creates a 'session key' for the authentication of subsequent double quotes? requests and responses which is different for each "authentication session", thus limiting the amount of material hashed with any one key. (Note: see further discussion of the authentication session in section 3.6.) Because the server need only use the hash of the user s/need/needs/ credentials in order to create the A1 value, this construction could be used in conjunction with a third party authentication service so that the web server would not need the actual password value. The specification of such a protocol is beyond the scope of this specification. Also note that if integrity protection is applied (qop=auth-int), the H(entity-body) is the hash of the entity body, not the message body - it is computed before any transfer encoding is applied by the sender and after it has been removed by the recipient. Note that this includes multipart boundaries and embedded header fields in each part of any multipart content-type. (reduce amout of "note that"...) 3.4.6 Various Considerations The "Method" value is the HTTP request method, in all-uppercase US- ASCII letters, as specified in section 3.1.1 of [RFC7230]. The Hm, no. The registered methods happen to be all-uppercase, but method names are case-sensitive. Implementers should be aware of how authenticated transactions ...need to be... interact with shared caches. The HTTP/1.1 protocol specifies that s/The HTTP/1.1 protocol/HTTP/ when a shared cache (see [RFC7234]) has received a request containing an Authorization header field and a response from relaying that request, it MUST NOT return that response as a reply to any other request, unless one of two Cache-Control (see section 3.2 of [RFC7234]) directive was present in the response. If the original response included the "must-revalidate" Cache-Control directive, the cache MAY use the entity of that response in replying to a subsequent request, but MUST first revalidate it with the origin server, using the request header fields from the new request to allow the origin server to authenticate the new request. Alternatively, if the original response included the "public" Cache-Control directive, the response entity MAY be returned in reply to any subsequent request. Do we need to replicate this information here? (Asking because the Basic spec does not) 3.5 The Authentication-Info Header The Authentication-Info header field is a generic field that MAY be used by a server to communicate some information regarding the successful authentication of a client response. The following is the syntax of the header: Authentication-Info = auth-info auth-info = *auth-param This needs to be "#auth-param" and invoke the list ABNF extension from RFC 7230. The auth-param is defined in [RFC7235]. (I still believe we should extract this into a separate spec) 3.5.1 Digest Usage of Authentication-Info The Digest authentication scheme MAY add the Authentication-Info header field in the confirmation request with some or all of the following parameters: "Some or all" reads weird. 3.6 Digest Operation Upon receiving the Authorization header field, the server MAY check its validity by looking up the password that corresponds to the submitted username. Then, the server MUST perform the same digest operation (e.g. MD5, SHA-256) performed by the client, and compare the result to the given response value. Note that the HTTP server does not actually need to know the user's cleartext password. As long as H(A1) is available to the server, the validity of an Authorization header field MAY be verified. s/MAY/can/ Because the client is required to return the value of the opaque s/required/REQUIRED/ parameter given to it by the server for the duration of a session, the opaque data MAY be used to transport authentication session state s/MAY/can/ information. (Note that any such use can also be accomplished more easily and safely by including the state in the nonce.) For example, a server could be responsible for authenticating content that actually sits on another server. It would achieve this by having the first 401 response include a domain parameter whose value includes a URI on the second server, and an opaque parameter whose value contains the state information. The client will retry the request, at which time the server might respond with a 301/302 redirection, Do not exclude 307/308. Just say "HTTP Redirection (Section 6.4 of [RFC7231])" As with the basic scheme, proxies MUST be completely transparent in s/basic/"Basic"/ Is it wise to cite that hear? the Digest access authentication scheme. That is, they MUST forward the WWW-Authenticate, Authentication-Info and Authorization header fields untouched. If a proxy wants to authenticate a client before a request is forwarded to the server, it can be done using the Proxy- Authenticate and Proxy-Authorization header fields described in section 3.8 below. 3.7 Security Protocol Negotiation It is useful for a server to be able to know which security schemes a client is capable of handling. It is possible that a server MAY want to require Digest as its s/MAY want/wants/ authentication method, even if the server does not know that the client supports it. A client is encouraged to fail gracefully if the server specifies only authentication schemes it cannot handle. When a server receives a request to access a resource, the server might challenge the client by responding with "401 Unauthorized" status code, and include one or more WWW-Authenticate header fields. s/status code/response/ If the server challenges with multiple Digest header fields, then each one of these header fields MUST use a different digest You could have multiple challenges in a single header field instance. algorithm. The server MUST add these Digest header fields to the response in order of preference, starting with the most preferred header field, followed by the less preferred header fields. most preferred algorithm? When the client receives the response it SHOULD use the topmost header field that it supports, unless a local policy dictates First challenge. otherwise. The client SHOULD ignore any challenge it does not understand. MUST, I believe. Also, this sounds like requirements that are generic to WWW-A, not specific to Digest, no? 3.8 Proxy-Authenticate and Proxy-Authorization The digest authentication scheme MAY also be used for authenticating s/MAY/can/ users to proxies, proxies to proxies, or proxies to origin servers by use of the Proxy-Authenticate and Proxy-Authorization header fields. These header fields are instances of the Proxy-Authenticate and Proxy- Authorization header fields specified in sections 4.2 and 4.3 s/Proxy- Authorization/Proxy-Authorization/ of the HTTP/1.1 specification [RFC7235] and their behavior is subject to restrictions described there. The transactions for proxy authentication are very similar to those already described. Upon receiving a request which requires authentication, the proxy/server MUST issue the "407 Proxy Authentication Required" response with a "Proxy-Authenticate" header field. The digest-challenge used in the Proxy-Authenticate header field is the same as that for the WWW- Authenticate header field as defined above in section 3.2.1. I don't see a Section 3.2.1. 3.9 Examples 3.9.1 Example with SHA-256 and MD5 The following example assumes that an access protected document is being requested from the server via a GET request. The URI of the document is http://www.nowhere.org/dir/index.html". Both client and server know that the username for this document is "Mufasa" and the password is "Circle of Life" ( with one space between each of the three words). Need to use RFC 2606 hostnames. The first time the client requests the document, no Authorization header field is sent, so the server responds with: HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="http-auth@example.org", qop="auth, auth-int", algorithm="SHA-256", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" WWW-Authenticate: Digest realm="http-auth@example.org", qop="auth, auth-int", algorithm="MD5", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" The client MAY prompt the user for their username and password, after s/MAY/can/ or /will/ Maybe also point out that you could also send...: WWW-Authenticate: Digest realm="http-auth@example.org", qop="auth, auth-int", algorithm="SHA-256", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS", Digest realm="http-auth@example.org", qop="auth, auth-int", algorithm="MD5", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" Later: Authorization:Digest username="Mufasa", insert an SP after the colon. realm="http-auth@example.org", uri="/dir/index.html", algorithm=MD5, nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", nc=00000001, cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ", qop=auth, response="8ca523f5e9506fed4657c9700eebdbec", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" If the client chooses to use the SHA-256 algorithm for calculating the response, the client responds with a new request including the following Authorization header field: Authorization:Digest username="Mufasa", realm="http-auth@example.org", uri="/dir/index.html", algorithm=SHA-256, nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", nc=00000001, cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ", qop=auth, response="753927fa0e85d155564e2e272a28d1802ca10daf449 6794697cf8db5856cb6c1", opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" 3.9.2 Example with SHA-512-256, Charset, and Userhash The following example assumes that an access protected document is being requested from the server via a GET request. The URI for the request is "http://api.example.org/doe.json". Both client and server know the userhash of the username, support the UTF-8 charset, and use s/UTF-8 charset/UTF-8 character encoding scheme/ the SHA-512-256 algorithm. The username for the request is "Jason Doe" and the password is "Secret, or not?". It would be good to have non-ASCII characters in the example. The first time the client requests the document, no Authorization header field is sent, so the server responds with: HTTP/2.0 401 Unauthorized HTTP/2.0???? WWW-Authenticate: Digest realm="api@example.org", qop=auth, algorithm=SHA-512-256, nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", charset=UTF-8, userhash=true The client MAY prompt the user for the required credentials and send a new request with following Authorization header field: Authorization: Digest username="488869477bf257147b804c45308cd62ac4e25eb717 b12b298c79e62dcea254ec", realm="api@example.org", uri="/doe.json", algorithm=SHA-512-256, nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", nc=00000001, cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v", qop=auth, response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d 6c861229025f607a79dd", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", userhash=true If the client can not provide a hashed username for any reason, the client MAY try a request with this Authorization header field: Authorization: Digest username*=UTF-8''J%C3%A4s%C3%B8n%20Doe, realm="api@example.org", uri="/doe.json", algorithm=SHA-512-256, nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", nc=00000001, cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v", qop=auth, response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d6 c861229025f607a79dd", opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", userhash=false Wait, you can't do that. You'll need to formally state that some or all of your auth-params can be sent using the RFC 5987 encoding (and upfront, not in the example here). For the username, recipients MUST support all characters defined in the "UsernameCasePreserved" profile defined in in Section 3.3 of [PRECIS], with the exception of the colon (":") character. This is copied from Basic. Is it true for Digest as well? If the user agent does not support the encoding indicated by the server, it MUST fail the request. That sounds like a deployment problem. Also it reads weird given the fact that only one value ("UTF-8") is allowed. 5.6 Weakness Created by Multiple Authentication Schemes An HTTP/1.1 server MAY return multiple challenges with a 401 (Authenticate) response, and each challenge MAY use a different auth- scheme. A user agent MUST choose to use the strongest auth- scheme it s/auth- scheme/auth-scheme/ understands and request credentials from the user based upon that challenge. Note that many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should only s/should/SHOULD/ include Basic if it is minimally acceptable. When the server offers choices of authentication schemes using the WWW-Authenticate header field, the strength of the resulting authentication is only as good as that of the of the weakest of the authentication schemes. See section 5.7 below for discussion of particular attack scenarios that exploit multiple authentication schemes. 5.8 Man in the Middle Both Basic and Digest authentication are vulnerable to "man in the middle" (MITM) attacks, for example, from a hostile or compromised proxy. Clearly, this would present all the problems of eavesdropping. But it also offers some additional opportunities to the attacker. The Digest spec shouldn't talk about "Basic". And it seems that there's a security consideration I dropped from 2617 and which I need to include into the Basic spec. 5.12 Spoofing by Counterfeit Servers Basic Authentication is vulnerable to spoofing by counterfeit servers. If a user can be led to believe that she is connecting to a ...this section doesn't belong here. 6.2 Digest Scheme Registration This specification registers the Digest scheme with the Authentication Scheme Registry. Authentication Scheme Name: Digest Pointer to specification text: RFCXXX s/RFCXXXX/this specification/ 7 Acknowledgments The authors of this document would like to thank the authors of RFC2617, as this document heavily borrows text from their document to provide a complete description of the digest scheme and its operations. s/RFC2617/RFC 2617/ 8 References 8.1 Normative References [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006. doesn't seem to be normative. [BASIC] Reschke, J., "The 'Basic' HTTP Authentication Scheme", draft-ietf-httpauth-basicauth-update (Work in Progress), September 2013. Needs update. Also shouldn't be normative. Best regards, Julian From nobody Sun Dec 14 10:35:03 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C6E1A013B for ; Sun, 14 Dec 2014 10:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcuGf1cqYsWa for ; Sun, 14 Dec 2014 10:34:58 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DC71A0127 for ; Sun, 14 Dec 2014 10:34:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D50C1BF15; Sun, 14 Dec 2014 18:34:54 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZzPe5tQdafj; Sun, 14 Dec 2014 18:34:52 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.42.20.84]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 54A0BBF09; Sun, 14 Dec 2014 18:34:52 +0000 (GMT) Message-ID: <548DD84B.1080805@cs.tcd.ie> Date: Sun, 14 Dec 2014 18:34:51 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Michael Sweet References: <20141209123810.18013.5085.idtracker@ietfa.amsl.com> <5486EE3D.10507@cs.tcd.ie> <7866D906-5A25-4926-845A-7562E42A4370@apple.com> In-Reply-To: <7866D906-5A25-4926-845A-7562E42A4370@apple.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/nAxU--FBqaGFpmTk-7TOUqDkfwA Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-hoba-07.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 18:35:02 -0000 Hi Michael, Thanks again for the further review. On 12/12/14 15:06, Michael Sweet wrote: > Stephen, > > Some comments for things I think should be resolved before this goes > to IETF LC: > > - In section 6.1.1 you say the values are "regok" and "reginwork", > but the ABNF and subsequent text use "regok" and "inwork". Thanks. Fixed so both say reginwork now. > - Also in section 6.1.1, bottom of page 13 and top of page 14 you > have: > > o Only one single value is allowed in a Hobareg header field. Should > more than one (a list) be encountered, that should be interpreted as > being the same as "inwork." > > Suggested rewording to fix grammar and use of 2119 conformance > terms: > > o Only a single value is allowed in a Hobareg header field. If the > server receives a list of values, it SHOULD interpret them as the > same as "inwork." No, the server dosn't get Hobareg headers from a client at all. Those are only server->UA. If we give the wrong impression somewhere then we should fix that so if you can say what gave you the impression the client was sending Hobareg we might want to change something. > [or "reginwork", whichever is the correct one] Fixed that. > o The Hobareg header field can only be used in HTTP responses. > > But you allow clients to send it in requests? No. > o Since Hobareg is only meant for responses it ought not appear in > a PUT request. > > How about listing the methods that MAY contain it as a request > header? And tie it/merge it with the previous bullet. None. > o The HTTP response code does affect the interpretation of Hobareg. > Registration is only considered to have succeeded if the regok value > is seen in a 2xx response. 4xx and other errors means that > registration has failed regardless of the value of Hobareg seen. The > request method has no influence on the interpretation of Hobareg. > > Suggest you separate the Hobareg request header discussion from the > Hobareg response header. But it's never part of a request. > > > o Intermediaries should never insert, delete or modify a Hobareg > header field. > > SHOULD? I went for s/should never/never/ as it's really a MUST NOT but we actually don't need any 2119 term in this case. > o As a response-only header field, it is not appropriate to list a > Hobareg in a Vary response header field. > > Is this still true? Yes. > > > o Hobareg is allowed in trailers. > > o As a response-only header field, Hobareg will not be preserved > across re-directs. > > Is this still true? Yes. > Or just true that the Hobareg response header is > not preserved across redirects? > > > o Hobareg itself discloses little security or privacy sensitive > information. If an attacker can somehow detect that a Hobareg header > field is being added, then that attacker would know that the UA is in > the process of registration which could be significant. However, it > is likely that the set of messages between the UA and server would > expose this information in many cases, regardless of whether or not > TLS is used. Using TLS is still however a good plan. > > TLS is RECOMMENDED? Elsewhere yes, so no need to repeat that here. I think it's ok as is. > > - In section 6.3 you say "The server MUST NOT allow TLS session > resumption for any logged out session." but you don't say why. Yes, we don't and I'd argue to not try add much there as it's likely hard to get right and not that useful. The reason for the MUST NOT is so a server is less likely to get confused between TLS and HOBA state. > - In section 6.4, you say the challenge is returned in the body of > the response. Is that sufficient, or do you want to say the response > will have a specific Content-Type and the body *is* the challenge > with no other data (other than whitespace)? Ah - good catch. I don't think we care about the content-type (or at least I don't:-) but yes it could be more specific about the body being the challenge. I added that whitespace MUST be ignored but would be equally fine with saying that the entire response MUST be the b64-encoded challenge if that was better. > - In section 8, how does one enforce conformance of hard-to-guess > URLs? Perhaps reword as "To make this more difficult, the server > generates hard to guess URLs and other values as part of any CPK > binding processes, for whatever level of difficulty chosen by the > server." One cannot enforce such conformance except by looking into the implementation, but I think the MUST is ok in a security considerations section. And the "how" for that is well known really. I think the current text is ok as-is but would also be ok with getting rid of the MUST. > > - Also in section 8, you state a conformance requirement for server > administrators. Perhaps "Server administrators can set the max-age > ..." instead of SHOULD. Yeah, I think "can" is better there s/SHOULD/can/ done > > - In section 8.1, "we" are sending a key - reword as "the client/user > agent needs to send"? Could do, but I think it's ok as-is. Happy to change it if others feel that further de-personalisation is better:-) I've put a working-copy for a -08 at [1], diff vs. 07 at [2]. (On the assumption that the resolutions above are ok, if not we'll iterate/fix as guided by the shepherd/AD.) That proto-08 also moves a bit of text I put in the wrong place in 07 and updates the implementation status section which I also forgot for -07. Cheers, S. [1] [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-07.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt >> On Dec 9, 2014, at 7:42 AM, Stephen Farrell >> wrote: >> >> >> Hi all, >> >> This I hope fixes the potential issue Watson identified by adding a >> length: to each field in HOBA-TBS. >> >> I also took the chance to update the examples to example.com and >> not hoba-local.ie since they needed to change anyway with the >> change to the bytes of HOBA-TBS. >> >> So from my POV I think this is ready for IETF LC now once the >> chairs post the write up and Kathleen hits the button. >> >> Thanks, S. >> >> PS: I've updated my code enough to test this and re-generate the >> examples but haven't yet commited that back to the repo. Will try >> get to that in the next day or so. >> >> On 09/12/14 12:38, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. This draft is a work item of the >>> Hypertext Transfer Protocol Authentication Working Group of the >>> IETF. >>> >>> Title : HTTP Origin-Bound Authentication (HOBA) Authors >>> : Stephen Farrell Paul Hoffman Michael Thomas Filename : >>> draft-ietf-httpauth-hoba-07.txt Pages : 25 Date >>> : 2014-12-09 >>> >>> Abstract: HTTP Origin-Bound Authentication (HOBA) is a digital >>> signature based design for an HTTP authentication method. The >>> design can also be used in Javascript-based authentication >>> embedded in HTML. HOBA is an alternative to HTTP authentication >>> schemes that require passwords and therefore avoids all problems >>> related to passwords, such as leakage of server-side password >>> databases. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-httpauth-hoba-07 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-07 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ http-auth mailing >>> list http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >>> >>> >> >> _______________________________________________ http-auth mailing >> list http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > _________________________________________________________ Michael > Sweet, Senior Printing System Engineer, PWG Chair > From nobody Sun Dec 14 10:37:48 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937B41A0143 for ; Sun, 14 Dec 2014 10:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E5vgMOwr7ew for ; Sun, 14 Dec 2014 10:37:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763F81A0127 for ; Sun, 14 Dec 2014 10:37:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3DFDABF15; Sun, 14 Dec 2014 18:37:44 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia270SYjdaYa; Sun, 14 Dec 2014 18:37:43 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.42.20.84]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E91BFBF09; Sun, 14 Dec 2014 18:37:42 +0000 (GMT) Message-ID: <548DD8F6.7090409@cs.tcd.ie> Date: Sun, 14 Dec 2014 18:37:42 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Michael Sweet References: <20141209123810.18013.5085.idtracker@ietfa.amsl.com> <5486EE3D.10507@cs.tcd.ie> <7866D906-5A25-4926-845A-7562E42A4370@apple.com> <548DD84B.1080805@cs.tcd.ie> In-Reply-To: <548DD84B.1080805@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/0aAMkCOZqocYyRfuaqTAqopnI2k Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-hoba-07.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 18:37:46 -0000 On 14/12/14 18:34, Stephen Farrell wrote: > I've put a working-copy for a -08 at [1], diff vs. 07 at [2]. > (On the assumption that the resolutions above are ok, if not > we'll iterate/fix as guided by the shepherd/AD.) Forgot to put in the URL for [1]. It was guessable though:-) S. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-07.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt From nobody Sun Dec 14 11:29:42 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B491A0172 for ; Sun, 14 Dec 2014 11:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baT-FBrJgZH4 for ; Sun, 14 Dec 2014 11:29:38 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947551A0164 for ; Sun, 14 Dec 2014 11:29:37 -0800 (PST) X-AuditID: 1209190d-f79006d000000cfe-79-548de51fe2b0 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id AF.49.03326.F15ED845; Sun, 14 Dec 2014 14:29:35 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id sBEJTY2U019199; Sun, 14 Dec 2014 14:29:35 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBEJTWlg030826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Dec 2014 14:29:34 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBEJTWg3016919; Sun, 14 Dec 2014 14:29:32 -0500 (EST) Date: Sun, 14 Dec 2014 14:29:31 -0500 (EST) From: Benjamin Kaduk To: Julian Reschke In-Reply-To: <548DBA0B.6080201@greenbytes.de> Message-ID: References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA0B.6080201@greenbytes.de> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixCmqrSv/tDfE4GuzmcWH/XOYLCac2cRq sfNFK5sDs8fOWXfZPSZt7mXyWLLkJ1MAcxSXTUpqTmZZapG+XQJXxvoJtgVTlCpam4UaGPuk uhg5OSQETCS2P1jFDGGLSVy4t56ti5GLQ0hgMZPE02+tUM5GRonr87cxQjiHmCRWLpjLAuE0 MEr07foD1s8ioC1xYNt9FhCbTUBFYuabjWwgtoiAocTBj9OAajg4mAWSJI7fYgQxhQXcJFqe iYNUcAroSjy6f5MdJMwr4Cgx8YYnxPRljBIfey6BTRcV0JFYvX8K2HReAUGJkzOfgNnMAloS y6dvY5nAKDgLSWoWktQCRqZVjLIpuVW6uYmZOcWpybrFyYl5ealFukZ6uZkleqkppZsYwYEr ybuD8d1BpUOMAhyMSjy8H6J6Q4RYE8uKK3MPMUpyMCmJ8trcAArxJeWnVGYkFmfEF5XmpBYf YpTgYFYS4X2wGSjHm5JYWZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTBG38H qFGwKDU9tSItM6cEIc3EwQkynAdoeBZIDW9xQWJucWY6RP4Uo6KUOG8uSEIAJJFRmgfXC0ss rxjFgV4R5o0CqeIBJiW47ldAg5mABl9m7AEZXJKIkJJqYNztdeOOy91VX4P95l521eaY9SY5 yy3p08r503r+1ulUdfVbtjd6Hjv79sUNB2X+VwpZrE+LMx68Pu+z+Pf+Qzv+nf8RUO+ruKhf b6eVoeoqL6YYP72f9Y9+nc1beaOQ5SfzrvNXiyLVt5ipPn3jOPv7b5WDRZsi4lc/fJRsUf7J 5FjB+vmcyZOUWIozEg21mIuKEwF5ZUzhBwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/_42jARyVFIBP86cyk8rHedjnv2Q Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 19:29:41 -0000 Trimming bits I don't have anything in particular to say about... On Sun, 14 Dec 2014, Julian Reschke wrote: > Also maybe: ...that can used with the *HTTP* authentication mechanism. Adding HTTP sounds good to me. > This parameter is not meaningful in Proxy-Authenticate header > fields, for which the protection space is always the entire proxy; > if present it should be ignored. > > MUST? SHOULD? Seems like MUST, to me ... what would it be interpreted as, anyway? > nonce > A server-specified data string which should be uniquely generated > each time a 401 response is made. It is recommended that this > > RECOMMENDED? > > Would there be a problem if it is a differen format? If no, why a normative > requirement here? I believe there would not be a problem. I don't see normative text, here. It is useful to give concrete examples of how this might be done, since many developers do not have a good understanding of randomness and why it is needed and how it should be used. > string be base64 or hexadecimal data. Specifically, since the > string is passed in the header field lines as a quoted string, the > double-quote character is not allowed. > > well, unless suitably escaped. I guess so. That sentence has a comma splice, too. > The contents of the nonce are implementation dependent. The > > s/are/is/? No. "are" agrees with "contents"; both are plural. > opaque > A string of data, specified by the server, which SHOULD be > returned by the client unchanged in the Authorization header field > of subsequent requests with URIs in the same protection space. It > is RECOMMENDED that this string be base64 or hexadecimal data. > > (see above) Okay, this one is normative, sure. I don't have a strong preference for or against the 2119 language, but would lean towards using the normative language. > The request includes some or all of the following parameters: > > "some or all" reads weird... But how else would you say it? Just "some" could be read as saying that "all" is forbidden. > digest is invalid, then a login failure should be logged, since > repeated login failures from a single client may indicate an attacker > attempting to guess passwords. The server implementation should be > > SHOULD? Not required for interoperability; required for security. > careful with the information being logged so that it won't put a > cleartext password (e.g. entered into the username field) into the > log. > [...] > requests and responses which is different for each "authentication > session", thus limiting the amount of material hashed with any one > key. (Note: see further discussion of the authentication session in > section 3.6.) Because the server need only use the hash of the user > > s/need/needs/ No. "X need only do Y" is a valid construct; to use "needs" it would need to be "X needs to only do Y" or something else. > credentials in order to create the A1 value, this construction could > be used in conjunction with a third party authentication service so > that the web server would not need the actual password value. The > specification of such a protocol is beyond the scope of this > specification. > [...] > 3.5.1 Digest Usage of Authentication-Info > > The Digest authentication scheme MAY add the Authentication-Info > header field in the confirmation request with some or all of the > following parameters: > > "Some or all" reads weird. [The same considerations previously mentioned still apply] > Also, this sounds like requirements that are generic to WWW-A, not specific to > Digest, no? Probably. But what document wouldu such generic requirements go in? > The following example assumes that an access protected document is > being requested from the server via a GET request. The URI of the > document is http://www.nowhere.org/dir/index.html". Both client and > server know that the username for this document is "Mufasa" and the > password is "Circle of Life" ( with one space between each of the > three words). > > Need to use RFC 2606 hostnames. Yes, this has been mentioned before, by me and others. -Ben From nobody Sun Dec 14 12:54:56 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDAD1A0196 for ; Sun, 14 Dec 2014 12:54:55 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d391IJ2IH06B for ; Sun, 14 Dec 2014 12:54:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BD21A0181 for ; Sun, 14 Dec 2014 12:54:53 -0800 (PST) Received: from [192.168.2.160] ([93.217.112.113]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MEnjW-1YBkeM090M-00FzOX; Sun, 14 Dec 2014 21:54:52 +0100 Message-ID: <548DF91B.5040501@gmx.de> Date: Sun, 14 Dec 2014 21:54:51 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA0B.6080201@greenbytes.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DMjeUOJ/9izLj54oadx831up9uvz4pT+uIexDwpOf7BE5K7x8yN n2OcX0gGZkLOcBpRfSbCk8z1Y1Eb05RSga9Tfdeq8+aj60gI9I/7G+i4D0BOrtOBrQP0PD6 QB95uVs0s/sjk+aQnaBZwiyj3a2APi06eAjmokSXiqDd0Kt0WvAVloKcgVI3qcg7sHBmEtq YelHAqbEy6uXXAG8hwFlA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/zDv8eB5qP9h1gj_kTSXpD3sRk9w Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 20:54:56 -0000 On 2014-12-14 20:29, Benjamin Kaduk wrote: > Trimming bits I don't have anything in particular to say about... > ... Same here.... >> nonce >> A server-specified data string which should be uniquely generated >> each time a 401 response is made. It is recommended that this >> >> RECOMMENDED? >> >> Would there be a problem if it is a differen format? If no, why a normative >> requirement here? > > I believe there would not be a problem. > I don't see normative text, here. > It is useful to give concrete examples of how this might be done, since > many developers do not have a good understanding of randomness and why it > is needed and how it should be used. The question was about the format, not the randomness... >> The contents of the nonce are implementation dependent. The >> >> s/are/is/? > > No. "are" agrees with "contents"; both are plural. Is "contents" plural? /me leaves it to the native English speakers >> opaque >> A string of data, specified by the server, which SHOULD be >> returned by the client unchanged in the Authorization header field >> of subsequent requests with URIs in the same protection space. It >> is RECOMMENDED that this string be base64 or hexadecimal data. >> >> (see above) > > Okay, this one is normative, sure. > I don't have a strong preference for or against the 2119 language, but > would lean towards using the normative language. But what is the requirement good for= >> The request includes some or all of the following parameters: >> >> "some or all" reads weird... > > But how else would you say it? Just "some" could be read as saying that > "all" is forbidden. "The request can include parameters from the list below" >> digest is invalid, then a login failure should be logged, since >> repeated login failures from a single client may indicate an attacker >> attempting to guess passwords. The server implementation should be >> >> SHOULD? > > Not required for interoperability; required for security. It it's required then it ought to use a BCP14 term. >> Also, this sounds like requirements that are generic to WWW-A, not specific to >> Digest, no? > > Probably. But what document wouldu such generic requirements go in? They should have gone into RFC 7235. Which we can revise sometime in the future. > ... Best regards, Julian From nobody Mon Dec 15 05:56:38 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB2F1A1AF4 for ; Mon, 15 Dec 2014 05:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9Wb_kyKIFTN for ; Mon, 15 Dec 2014 05:56:35 -0800 (PST) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FF01A1ADC for ; Mon, 15 Dec 2014 05:56:35 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id e89so8577584qgf.10 for ; Mon, 15 Dec 2014 05:56:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=KptF+csBM+578r/FZ6u1l0k+LLLojEESusnaw7XRQF4=; b=muxjiMW5I6XK2CXMAoaJoa2iNILa5I93RUBOj9i6DqyZAqgxQxQk/zM7rkrnjl7vE1 64vfO5lTHtqusK3yykuH+llZ1TTf3cgYDVdI0wdF5Ze1BVTZqrbFAJ9wKikyBJmI4nYs baQx9uZaDcokIdNdzKJnRSKkh+wxGMi+7h5wLR7pytWGCzhucexLblgvFPZ3fcKtQjoV tBzR3ZAKJx4lE4YHUN+5dFJSyeg3B47N5pEF296VJc8Lpx4XrvSPLrMUrud7wNy2n5Gj rotCNOJu4JN76ZiI1i6tzG+KMSAOWBK9a4kW9UOoToVd3XuuJ18cxMomNdNdk59aol8Z hnyQ== X-Gm-Message-State: ALoCoQmWqT3XnLFCQ6dt9IS6gLJf5kdEKwpyP/4xGiyIT9szC2A9KSq2S6yodON030cHByYs408J X-Received: by 10.229.250.130 with SMTP id mo2mr43155352qcb.0.1418651794657; Mon, 15 Dec 2014 05:56:34 -0800 (PST) From: Brett Tate References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> In-Reply-To: <548DBA2D.2010808@gmx.de> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGSVmlRjw6lmMHoV78JN3V4yMoSMwKcxgTDANZVfHKc8HmNYA== Date: Mon, 15 Dec 2014 08:56:33 -0500 Message-ID: To: Julian Reschke , Rifaat Shekh-Yusef , http-auth@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/g83mnttnUQprDHCfBIP_CLDDxe4 Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 13:56:37 -0000 Hi, Concerning the quoted-string ambiguity, I agree that the ambiguity still exists. Draft-ietf-httpauth-digest-09 did not address my quoted string general comment. http://www.ietf.org/mail-archive/web/http-auth/current/msg01949.html Was it not addressed because of working group discussion at IETF 91? If so, I have the same comment. The draft is not clear concerning when quoted strings MUST/SHOULD/MAY be used. For historical reasons, the resolution from a sender perspective should be backward compatible with RFC 2617 which used ABNF to clearly indicate the mandate. Additional comments inline. > qop > Indicates what "quality of protection" the client has applied to > the message. Its value MUST be one of the alternatives the server > indicated it supports in the WWW-Authenticate header field. These > values affect the computation of the response. Note that this is a > single token, not a quoted list of alternatives as in WWW- > Authenticate. > > Can it use quoted-string nevertheless? Not if the draft/device wants to remain backward compatible with RFC 2617. > nc > This parameter MUST be used by all implementations compliant with > this version of the Digest scheme. The "nc" parameter stands for > > I wonder why we need to say "compliant with this version"? I also think that the sentence should be reworded. A compliant implementation does not need to include the nc when interoperating with a device which did not include a qop parameter. > of the HTTP/1.1 specification [RFC7235] and their behavior is subject > to restrictions described there. The transactions for proxy > authentication are very similar to those already described. Upon > receiving a request which requires authentication, the proxy/server > MUST issue the "407 Proxy Authentication Required" response with a > "Proxy-Authenticate" header field. The digest-challenge used in the > Proxy-Authenticate header field is the same as that for the WWW- > Authenticate header field as defined above in section 3.2.1. > > I don't see a Section 3.2.1. It and the use of "digest-challenge" are cut/paste errors from RFC 2617. The sentence should be updated the reflect the draft. > 3.9 Examples > > 3.9.1 Example with SHA-256 and MD5 > > Maybe also point out that you could also send...: > > WWW-Authenticate: Digest realm="http-auth@example.org", > qop="auth, auth-int", > algorithm="SHA-256", > nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", > opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS", > Digest realm="http-auth@example.org", > qop="auth, auth-int", > algorithm="MD5", > nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", > opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" It is not allowed. From nobody Mon Dec 15 06:38:41 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585181A1B5A for ; Mon, 15 Dec 2014 06:38:40 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8FkO_yhujcw for ; Mon, 15 Dec 2014 06:38:39 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0901A1AB4 for ; Mon, 15 Dec 2014 06:38:38 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M0gcI-1Xess82Kpq-00us4N; Mon, 15 Dec 2014 15:38:34 +0100 Message-ID: <548EF269.5000209@gmx.de> Date: Mon, 15 Dec 2014 15:38:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brett Tate , Rifaat Shekh-Yusef , http-auth@ietf.org References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jQOWnpL3QgDuoDFoI8TwNFr6euk46MUL4imuwem9B0R/Uoo90Xo nk5jCCOmVxLh9QDo+kJ5bDQpLgRVWN7IRvf8iMlaBHINVJQrGM6YR88oc38Lo6K77D/P/4N Vm72xdXosIYGQxCdL4mdym470T9Azkzj8xCUaVALRAPRd5ZT4cO3yP+heDSDSMKuHeNSFp0 K62cuAJSh0EGxzbhE3vAQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/1EiIn5XzUKqhn0JvyT1Ao71Q-vg Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 14:38:40 -0000 On 2014-12-15 14:56, Brett Tate wrote: > ... >> 3.9 Examples >> >> 3.9.1 Example with SHA-256 and MD5 >> >> Maybe also point out that you could also send...: >> >> WWW-Authenticate: Digest realm="http-auth@example.org", >> qop="auth, auth-int", >> algorithm="SHA-256", >> nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", >> opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS", >> Digest realm="http-auth@example.org", >> qop="auth, auth-int", >> algorithm="MD5", >> nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", >> opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" > > It is not allowed. Yes, it is. There is no wiggle room here, the syntax is defined by RFC 7235. Best regards, Julian From nobody Mon Dec 15 07:04:44 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605E31A6FCF for ; Mon, 15 Dec 2014 07:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeiZRXmYbKQm for ; Mon, 15 Dec 2014 07:04:31 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB421A1ABC for ; Mon, 15 Dec 2014 07:04:30 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id i8so8635133qcq.39 for ; Mon, 15 Dec 2014 07:04:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=xmeriXURV541lm9H3N43znPczTcbS+ArPNZm+eZHWRc=; b=Wsh4rC6MH/wfpbWO0+OUbRdSVPzHV4jFIYaHWcwyN/fXo5fdL3l2g2wQp/x4ledSmo vkwOQh1NdX7rIDEonL1YGmxegEO5GvlP8DqADCiTT/XyxOvEbtAQTdqyRxczgq3xyZn1 scDPLqF2lHqeHrt+ZdY8WCnj71Ib4+IFHUfhwyh8e17lbsMLdPFGBqHkHHhfPvt96i/9 NvCXDAJxsTeXWniPtVuQyio4v7gxHUuhVs9ouQrv/OpIho8fP0AXsTG69aVOJ6KH6qId WhZtUO5dKPLjbCwWvZBg8hMx8ID89czd8FfXbL1iu8qAz+jfSY8NUtF74DavixeyYaXl NuDw== X-Gm-Message-State: ALoCoQkutMzu30oNlupUI2JtqDZxiUAk5z+vwtgi85IAMn88T0U/0gIAMz3X5uvabzFqlsNwbkIP X-Received: by 10.224.137.131 with SMTP id w3mr5137017qat.95.1418655870082; Mon, 15 Dec 2014 07:04:30 -0800 (PST) From: Brett Tate References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> <548EF269.5000209@gmx.de> In-Reply-To: <548EF269.5000209@gmx.de> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGSVmlRjw6lmMHoV78JN3V4yMoSMwKcxgTDANZVfHICVcfQsQLOu6L+nMeFAaA= Date: Mon, 15 Dec 2014 10:04:28 -0500 Message-ID: <3bcd3c137ab52de9088d1cb4d6b98759@mail.gmail.com> To: Julian Reschke , http-auth@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/mrI7L3vSmj4RVk_LAfcoo4wxSQo Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 15:04:35 -0000 Thanks. I hadn't noticed that RFC 2617 (and RFC 7235) allows such a combination while RFC 3261 disallows it. > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, December 15, 2014 9:39 AM > To: Brett Tate; Rifaat Shekh-Yusef; http-auth@ietf.org > Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt > > On 2014-12-15 14:56, Brett Tate wrote: > > ... > >> 3.9 Examples > >> > >> 3.9.1 Example with SHA-256 and MD5 > >> > >> Maybe also point out that you could also send...: > >> > >> WWW-Authenticate: Digest realm="http-auth@example.org", > >> qop="auth, auth-int", > >> algorithm="SHA-256", > >> nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", > >> > >> opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS", > >> Digest realm="http-auth@example.org", > >> qop="auth, auth-int", > >> algorithm="MD5", > >> nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", > >> opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" > > > > It is not allowed. > > Yes, it is. > > There is no wiggle room here, the syntax is defined by RFC 7235. > > Best regards, Julian > From nobody Mon Dec 15 08:05:51 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283671A7021 for ; Mon, 15 Dec 2014 08:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-zfgUNjLYe0 for ; Mon, 15 Dec 2014 08:05:49 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CD71A7020 for ; Mon, 15 Dec 2014 08:05:48 -0800 (PST) X-AuditID: 1209190d-f79006d000000cfe-cd-548f06da0e9b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 75.3D.03326.AD60F845; Mon, 15 Dec 2014 11:05:46 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id sBFG5kp6020333; Mon, 15 Dec 2014 11:05:46 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBFG5htN031384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Dec 2014 11:05:45 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBFG5hHI024811; Mon, 15 Dec 2014 11:05:43 -0500 (EST) Date: Mon, 15 Dec 2014 11:05:43 -0500 (EST) From: Benjamin Kaduk To: Julian Reschke In-Reply-To: <548DF91B.5040501@gmx.de> Message-ID: References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA0B.6080201@greenbytes.de> <548DF91B.5040501@gmx.de> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixG6nonuLrT/EoOGtqcWH/XOYLDY/fMNq sfNFK5sDs8fOWXfZPT58jPNYsuQnUwBzFJdNSmpOZllqkb5dAlfGvzNLmQpuiVW87etgbmCc J9jFyMkhIWAi0fzoGAuELSZx4d56ti5GLg4hgcVMEt//P4FyNjJKbP41hwnCOcQkcaVnEzOE 08Ao8fXDbaAMOweLgLbE8XCQSWwCKhIz32xkA7FFBLQkbt/by9jFyMHBLJAkcfwWmCks4CbR 8kwcpIJTQE3i8vSJ7CBhXgFHieN/FCFmf2OU6Pk8jQmkRlRAR2L1/ilgd/IKCEqcnPkEzGYG mr58+jaWCYyCs5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrpJebWaKXmlK6iREU tpySvDsY3x1UOsQowMGoxMMbwdgXIsSaWFZcmXuIUZKDSUmU9xZDf4gQX1J+SmVGYnFGfFFp TmrxIUYJDmYlEd5Z74DKeVMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQk eDlZgYYKFqWmp1akZeaUIKSZODhBhvMADTcCqeEtLkjMLc5Mh8ifYlSUEuf9zgKUEABJZJTm wfXC0sorRnGgV4R5A0HaeYApCa77FdBgJqDBlxl7QAaXJCKkpBoYNz0K2/mEudQ2bZ1vW1T+ 8rxFgQl3rBw9T8k0LNtTYPDw3OLDJ25WbvR4ontgq0HCxaAdPkFqSqsfvf94SmCf2v+fXuV9 VpEOmcpzVl/fpvJ/0Y2Zu37GnD+iw2x6Otaf6dFubTH7T+Jai8Um69S/sjI/m7GjVk9Z2S/l qXqSw5YrU85ta3gUqsRSnJFoqMVcVJwIAIitlBgGAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Y4qc_uiZK5sAKxcPjAK5R562bEA Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 16:05:51 -0000 On Sun, 14 Dec 2014, Julian Reschke wrote: > On 2014-12-14 20:29, Benjamin Kaduk wrote: > > > nonce > > > A server-specified data string which should be uniquely generated > > > each time a 401 response is made. It is recommended that this > > > > > > RECOMMENDED? > > > > > > Would there be a problem if it is a differen format? If no, why a > > > normative > > > requirement here? > > > > I believe there would not be a problem. > > I don't see normative text, here. > > It is useful to give concrete examples of how this might be done, since > > many developers do not have a good understanding of randomness and why it > > is needed and how it should be used. > > The question was about the format, not the randomness... I agree that the question was about the format. But, if I take 20 octets from /dev/random and then just remove all the octets which are not allowed in this HTTP context, I no longer have 160 bits of entropy. If I take 20 octets from /dev/random and replace all the disallowed octets with '?', I also no longer have 160 bits of entropy. A base64 or hex encoding of random data will preserve the entropy, unambiguously. Leaving implementors to their own devices leaves a lot of room for failure. > > > The contents of the nonce are implementation dependent. The > > > > > > s/are/is/? > > > > No. "are" agrees with "contents"; both are plural. > > Is "contents" plural? > > /me leaves it to the native English speakers Yes, "contents" is plural. > > > opaque > > > A string of data, specified by the server, which SHOULD be > > > returned by the client unchanged in the Authorization header field > > > of subsequent requests with URIs in the same protection space. It > > > is RECOMMENDED that this string be base64 or hexadecimal data. > > > > > > (see above) > > > > Okay, this one is normative, sure. > > I don't have a strong preference for or against the 2119 language, but > > would lean towards using the normative language. > > But what is the requirement good for= This one is less clear than the nonce that there should be normative text. Here, the argument basically boils down to "an implementation which messes up characters from the base64 or hex character sets will be completely broken for ~everything". So, if the opaque is generated from that set, it is most likely to interoperate. Using characters outside that set might run into some funky implementation which is not very interoperable. > > > The request includes some or all of the following parameters: > > > > > > "some or all" reads weird... > > > > But how else would you say it? Just "some" could be read as saying that > > "all" is forbidden. > > "The request can include parameters from the list below" I would not object to that wording. -Ben From nobody Mon Dec 15 15:27:09 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790571A88C6; Mon, 15 Dec 2014 15:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fKewM0csS49; Mon, 15 Dec 2014 15:25:48 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC981A8AFC; Mon, 15 Dec 2014 15:25:46 -0800 (PST) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBFNPXmq022819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2014 18:25:34 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com sBFNPXmq022819 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418685936; bh=pSUKlt9Rp0eAuOB7Nm14ZNfxExk=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IWdD9ekU1PZAcMyez2yH3uT+uUjKttjJ84s3MX3DduIyCfM1tes7n4gT8jQ2RmD3u n6V2OYTkb8JVZOIiG8YKxQJfj9cfD7QlNdRnWLA4dI7BaAJ6ToSgJzT9HZ7SoazvNn 6OfNz8yubx7+/Tb128kQ8HOPb60NPCa+OT2mLR6g= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com sBFNPXmq022819 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd05.lss.emc.com (RSA Interceptor); Mon, 15 Dec 2014 18:25:11 -0500 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBFNPG4W013039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 18:25:17 -0500 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub22.corp.emc.com (128.222.70.134) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 15 Dec 2014 18:25:16 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 18:25:16 -0500 From: "Black, David" To: "stephen.farrell@cs.tcd.ie" , "paul.hoffman@vpnc.org" , "mike@phresheez.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 Thread-Index: AdAYvlv0aser5OsbSxuh2NmwD9vCCw== Date: Mon, 15 Dec 2014 23:25:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/QCnIGUhLALkAA9NzWRRXWT9aqmI X-Mailman-Approved-At: Mon, 15 Dec 2014 15:26:56 -0800 Cc: "Black, David" , "http-auth@ietf.org" , "ietf@ietf.org" Subject: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:25:51 -0000 This is a combined Gen-ART and OPS-Dir review. Boilerplate for both follow= s ... I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at: . Please resolve these comments along with any other Last Call comments you may receive. I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. Document: draft-ietf-httpauth-hoba-07 Reviewer: David Black Review Date: Dec XX, 2014 IETF LC End Date: Dec 24, 2014 Summary: This draft is on the right track, but has open issues described in the review. This draft specifies a signature-based authentication mechanism for HTTP that is based on asymmetric (public-private) key pairs without using certificates. A different key pair is used by each user for each for each host ("web-origin", see [RFC6454]), and each signature is based on a server-generated challenge. The draft is generally well-written and clear on the authentication mechanics, but has weaknesses in specifying the environment that surrounds use of this mechanism. Some of these issues are basic things that anyone working on web technology or applied crypto "just knows", but even the obvious needs to be stated when it's integral to security. -- Major issues: -- [1] Challenge size and predictability In the ABNF: challenge =3D 1*base64urlchars I did not see any other discussion of minimum length of challenge or amount of entropy in the challenge. For the latter, do the challenges need to be unpredictable? I would think so. I think a requirement on minimum challenge size and a recommendation on minimum amount of entropy would be good ideas. [2] Challenge verification and reuse This sentence on p.6 strikes me as subtly dangerous: The challenge however is sent over the network so as to make it simpler for a server to be stateless. (One form of stateless challenge might be a ciphertext that the server decrypts and checks, but that is an implementation detail.) The draft elsewhere asserts or assumes that challenge reuse can be prevented by the server or be time-bounded by max-age, and relies on those reuse limits for security properties, e.g., as in this sentence near the end of Section 6.1: Note that replay of registration (and other HOBA) messages is quite possible. That however can be counteracted if challenge freshness is ensured. The sentence quoted from p.6 appears to allow (or even encourage) stateless servers to implement rather weak checks on not only challenge reuse, but also challenge validity (e.g., what if the challenge validity test were "challenge mod 1024 =3D=3D 7" ?). Allowing such weak checks could enable an attacker to choose or influence the choice of challenge values, which could be useful (e.g., for differential cryptanalysis attack on the hash function), as the attacker (client) already controls the nonce. As part of this, the server needs to check whether a challenge presented on one connection or session has been reused on another. I think the following sentence in section 3 is intended to prevent this, but it's weakened by the "stateless" language above: The challenge MUST be unique for every HTTP 401 response in order to prevent replay attacks from passive observers. Explicit server checks for challenge reuse ought to be REQUIRED, and the above use of "stateless" needs to be qualified. [3] Web origin checks I did not see text mandating that TLS (server certificate), HTTP (accessed URL) and HOBA (signature input) use the same web origin, and stating that the server has to check/enforce this. Did I miss something? I realize that this is an obvious requirement, but it does need to be stated. [4] TLS requirement level TLS is only a "SHOULD" requirement for HOBA, not a "MUST" requirement - first paragraph in Section 8.1 (Privacy Considerations). If TLS is not a "MUST" requirement, at least a discussion of man-in-the- middle (MITM) attacks seems to be in order. There's no need for an extensi= ve discussion of all of the security properties of TLS, but MITM attacks are definitely worth a mention, and that could be complemented by a pointer to suitable HTTP/TLS security considerations text elsewhere. [5] Section 5.3 - unrecognized key Paragraphs 4 and 5 in this section don't seem to belong here, and appear to be written in a somewhat loose fashion, particularly around user verificati= on. A server that does what is suggested here could have significant security weaknesses. I strongly recommend replacing those two paragraphs with a short sentence t= hat says: - if a kid is unrecognized or the server otherwise determines that the CPK is not to be used for this HTTP authentication, - then the Registration (see 6.1) and/or Associating Additional Keys to an Exiting Account (see 6.2) processes MAY be used instead of treating this situation as an authentication failure. and moving all discussion of user verification into Sections 6.1 and 6.2. -- Minor issues: -- [A] ABNF encoding of alg In section 2, I see: alg =3D 1*2DIGIT o alg: specifies the signature algorithm being used encoded as an ASCII character as defined in Section 9.3. Section 9.3 specifies a single digit. How does that become 1*2DIGIT ? I suggest: "as an ASCII character" -> "as one or two ASCII digits based on the IANA registry established by Section 9.3" This may seem like a nit, but any imprecision in signature algorithm input can lead to interoperability problems. [B] Section 5.3 - CPK vs. kid In the authentication phase, the server extracts the CPK from the signing phase and decides if it recognizes the CPK. If the server recognizes the CPK, the server may finish the client authentication process. That seems wrong. IIUC, the HOBA client sends: HOBA-RES =3D kid "." challenge "." nonce "." sig If so, I don't understand how the server extracts a CPK from that. I suspect that what was intended is that the server extracts a key identifi= er (kid) and then determines a) whether it knows a CPK for that kid and b) whe= ther it allows use of that kid/CPK for this authentication. At least a) seems t= o be indicated by this text in Section 3: The server MUST check the cryptographic correctness of the signature based on a public key it knows for the kid in the signatures, [C] RSA signature algorithm Section 7 says: RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. Section 8.2 of RFC 3447 specifies RSASSA-PKCS1-v1_5. At a minimum, that algorithm name should be stated here (which is a nit). The minor issue is whether that is the signature algorithm that's wanted, on which I'll defer to the crypto experts on that (e.g., I seem to recall a negative saag comment on PKCS 1.5 mechanisms in the past couple of months). [D] Javascript local storage. The first paragraph of Section 8.2 on this topic concludes with: It's not clear that we introduce unique threats from which clear text passwords don't already suffer. That's at odds with the use of "all" in this sentence in the abstract: HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. One of those two paragraphs needs some editing. -- Nits/editorial comments: -- This is buried near the end of section 6.1 Note that replay of registration (and other HOBA) messages is quite possible. That however can be counteracted if challenge freshness is ensured. That's not a good place for these two sentences. HOBA registration messages don't contain a challenge, and the general discussion of replay attacks belongs under Security Considerations, not Registration. In Section 9.4 and 9.5, I see the following proposed as part of IANA registry contents: an unformatted string, at the user's/UA's whim I get the point, but it's still not appropriate for an IANA registry - remove ", at the user's/UA's whim". Appendix A appears to assume that human-memorable passwords are stored in the clear in server databases. It should also briefly discuss the use of one-way functions, especially computationally intensive ones, to generate stored password verifiers. HOBA is still superior by comparison, as the one-way functions only increase the difficulty of dictionary attack, whereas dictionary attack on HOBA keys is pointless when sufficiently large keys are used. idnits 2.13.01 found the references to W3C's web site (www.w3.org) in Section 4, e.g., 389 One element is required for HOBA-js: localStorage (see http:// 390 www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key 391 storage. I think idnits can be ignored, even though the "right way" to fix this is t= o move each URL to a reference and cite the reference in Section 4. OTOH, idnits did not complain about the normative reference to RFC 20 ;-). --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- Most of these questions are n/a because this draft describes an extension to HTTP authentication, and RFC 5706's concerns would apply primarily to HTTP and HTTP authentication. A.1.1 Has deployment been discussed? Yes, section 6 discusses how a user would deploy this for her access to web servers. A.1.4. Have the Requirements on other protocols and functional components been discussed? Yes, the discussion of how this functions within HTTP is sufficient. Major issues [3] and [4] fall into this category, but in both cases, I think they're probably text oversights that are easy to fix. A.2.7 Is security management discussed? =20 Not really, but this is an Experimental RFC. I would expect that the experimental use of HOBA will yield insight into server key database structure/management, key lifecycle management (e.g., revocation), account management techniques/processes, etc. A.3. Documentation I do not expect significant operational impact. Section 10 notes the existence of two implementations of HOBA-JS and one implementation of HOBA-http. That's a good start for an experiment. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Mon Dec 15 15:28:14 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1991A6F8B; Mon, 15 Dec 2014 15:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ffgRYXgYWyK; Mon, 15 Dec 2014 15:28:03 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432581A8BC2; Mon, 15 Dec 2014 15:27:55 -0800 (PST) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBFNRoI3026920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2014 18:27:50 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sBFNRoI3026920 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418686071; bh=bz8fCf/iiQxoqp+5hLD7MBsH9mw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=hppZNT0ftDcerayOwNme42UfKdtMko7rs2WnwWbTBpkjb2B+XiZ1FZOwoDCbV5kvD O+AFgRUmW9W3q9CZLTweRoheIsc53U5yrWSxhUheNOkgY/v54xwIl3ebLldf6OmHB9 rPSn0Cr5SAWxL090+VhVrc9oxq4PQ1q0IcZQHzO8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sBFNRoI3026920 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd06.lss.emc.com (RSA Interceptor); Mon, 15 Dec 2014 18:27:35 -0500 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBFNRcWc013712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 18:27:38 -0500 Received: from MXHUB106.corp.emc.com (10.253.58.23) by mxhub29.corp.emc.com (128.222.70.169) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 15 Dec 2014 18:27:37 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB106.corp.emc.com ([10.253.58.23]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 18:27:37 -0500 From: "Black, David" To: "stephen.farrell@cs.tcd.ie" , "paul.hoffman@vpnc.org" , "mike@phresheez.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 Thread-Index: AdAYvlv0aser5OsbSxuh2NmwD9vCCwAAEAow Date: Mon, 15 Dec 2014 23:27:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/sl-INVK1MYUpBexnlBWifm9yqCU Cc: "http-auth@ietf.org" , "ietf@ietf.org" Subject: Re: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:28:08 -0000 > Document: draft-ietf-httpauth-hoba-07 > Reviewer: David Black > Review Date: Dec XX, 2014 > IETF LC End Date: Dec 24, 2014 Got everything except the header - review date is Dec 15, 2014. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, December 15, 2014 6:25 PM > To: stephen.farrell@cs.tcd.ie; paul.hoffman@vpnc.org; mike@phresheez.com; > General Area Review Team (gen-art@ietf.org); ops-dir@ietf.org > Cc: ietf@ietf.org; http-auth@ietf.org; Black, David > Subject: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 >=20 > This is a combined Gen-ART and OPS-Dir review. Boilerplate for both foll= ows > ... >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at: >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > I have reviewed this document as part of the Operational directorate's on= going > effort to review all IETF documents being processed by the IESG. These > comments > were written primarily for the benefit of the operational area directors. > Document editors and WG chairs should treat these comments just like any = other > last call comments. >=20 > Document: draft-ietf-httpauth-hoba-07 > Reviewer: David Black > Review Date: Dec XX, 2014 > IETF LC End Date: Dec 24, 2014 >=20 > Summary: This draft is on the right track, but has open issues > described in the review. >=20 > This draft specifies a signature-based authentication mechanism for HTTP > that is based on asymmetric (public-private) key pairs without using > certificates. A different key pair is used by each user for each for > each host ("web-origin", see [RFC6454]), and each signature is based > on a server-generated challenge. >=20 > The draft is generally well-written and clear on the authentication > mechanics, but has weaknesses in specifying the environment that > surrounds use of this mechanism. Some of these issues are basic things > that anyone working on web technology or applied crypto "just knows", > but even the obvious needs to be stated when it's integral to security. >=20 > -- Major issues: -- >=20 > [1] Challenge size and predictability >=20 > In the ABNF: >=20 > challenge =3D 1*base64urlchars >=20 > I did not see any other discussion of minimum length of challenge > or amount of entropy in the challenge. For the latter, do the challenges > need to be unpredictable? I would think so. >=20 > I think a requirement on minimum challenge size and a recommendation on > minimum amount of entropy would be good ideas. >=20 > [2] Challenge verification and reuse >=20 > This sentence on p.6 strikes me as subtly dangerous: >=20 > The challenge however is sent over > the network so as to make it simpler for a server to be stateless. > (One form of stateless challenge might be a ciphertext that the > server decrypts and checks, but that is an implementation detail.) >=20 > The draft elsewhere asserts or assumes that challenge reuse can be > prevented by the server or be time-bounded by max-age, and relies on > those reuse limits for security properties, e.g., as in this sentence > near the end of Section 6.1: >=20 > Note that replay of registration (and other HOBA) messages is quite > possible. That however can be counteracted if challenge freshness is > ensured. >=20 > The sentence quoted from p.6 appears to allow (or even encourage) > stateless servers to implement rather weak checks on not only challenge > reuse, but also challenge validity (e.g., what if the challenge validity > test were "challenge mod 1024 =3D=3D 7" ?). >=20 > Allowing such weak checks could enable an attacker to choose or influence > the choice of challenge values, which could be useful (e.g., for > differential cryptanalysis attack on the hash function), as the > attacker (client) already controls the nonce. >=20 > As part of this, the server needs to check whether a challenge presented > on one connection or session has been reused on another. I think the > following sentence in section 3 is intended to prevent this, but it's > weakened by the "stateless" language above: >=20 > The challenge MUST be > unique for every HTTP 401 response in order to prevent replay > attacks from passive observers. >=20 > Explicit server checks for challenge reuse ought to be REQUIRED, and > the above use of "stateless" needs to be qualified. >=20 > [3] Web origin checks >=20 > I did not see text mandating that TLS (server certificate), HTTP (accesse= d > URL) and HOBA (signature input) use the same web origin, and stating that > the server has to check/enforce this. Did I miss something? >=20 > I realize that this is an obvious requirement, but it does need to be > stated. >=20 > [4] TLS requirement level >=20 > TLS is only a "SHOULD" requirement for HOBA, not a "MUST" requirement - > first paragraph in Section 8.1 (Privacy Considerations). >=20 > If TLS is not a "MUST" requirement, at least a discussion of man-in-the- > middle (MITM) attacks seems to be in order. There's no need for an exten= sive > discussion of all of the security properties of TLS, but MITM attacks are > definitely worth a mention, and that could be complemented by a pointer t= o > suitable HTTP/TLS security considerations text elsewhere. >=20 > [5] Section 5.3 - unrecognized key >=20 > Paragraphs 4 and 5 in this section don't seem to belong here, and appear = to > be written in a somewhat loose fashion, particularly around user verifica= tion. > A server that does what is suggested here could have significant security > weaknesses. >=20 > I strongly recommend replacing those two paragraphs with a short sentence= that > says: > - if a kid is unrecognized or the server otherwise determines > that the CPK is not to be used for this HTTP authentication, > - then the Registration (see 6.1) and/or Associating Additional Keys to > an Exiting Account (see 6.2) processes MAY be used instead of > treating this situation as an authentication failure. >=20 > and moving all discussion of user verification into Sections 6.1 and 6.2. >=20 > -- Minor issues: -- >=20 > [A] ABNF encoding of alg >=20 > In section 2, I see: >=20 > alg =3D 1*2DIGIT >=20 > o alg: specifies the signature algorithm being used encoded as an > ASCII character as defined in Section 9.3. >=20 > Section 9.3 specifies a single digit. How does that become 1*2DIGIT ? > I suggest: "as an ASCII character" -> "as one or two ASCII digits based > on the IANA registry established by Section 9.3" >=20 > This may seem like a nit, but any imprecision in signature algorithm > input can lead to interoperability problems. >=20 > [B] Section 5.3 - CPK vs. kid >=20 > In the authentication phase, the server extracts the CPK from the > signing phase and decides if it recognizes the CPK. If the server > recognizes the CPK, the server may finish the client authentication > process. >=20 > That seems wrong. IIUC, the HOBA client sends: >=20 > HOBA-RES =3D kid "." challenge "." nonce "." sig >=20 > If so, I don't understand how the server extracts a CPK from that. >=20 > I suspect that what was intended is that the server extracts a key identi= fier > (kid) and then determines a) whether it knows a CPK for that kid and b) > whether > it allows use of that kid/CPK for this authentication. At least a) seems= to > be indicated by this text in Section 3: >=20 > The server MUST check the cryptographic correctness of the signature > based on a public key it knows for the kid in the signatures, >=20 > [C] RSA signature algorithm >=20 > Section 7 says: >=20 > RSA is defined in > Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. >=20 > Section 8.2 of RFC 3447 specifies RSASSA-PKCS1-v1_5. At a minimum, that > algorithm name should be stated here (which is a nit). The minor issue i= s > whether that is the signature algorithm that's wanted, on which I'll defe= r > to the crypto experts on that (e.g., I seem to recall a negative saag > comment on PKCS 1.5 mechanisms in the past couple of months). >=20 > [D] Javascript local storage. >=20 > The first paragraph of Section 8.2 on this topic concludes with: >=20 > It's not clear that we > introduce unique threats from which clear text passwords don't > already suffer. >=20 > That's at odds with the use of "all" in this sentence in the abstract: >=20 > HOBA is an > alternative to HTTP authentication schemes that require passwords and > therefore avoids all problems related to passwords, such as leakage > of server-side password databases. >=20 > One of those two paragraphs needs some editing. >=20 > -- Nits/editorial comments: -- >=20 > This is buried near the end of section 6.1 >=20 > Note that replay of registration (and other HOBA) messages is quite > possible. That however can be counteracted if challenge freshness is > ensured. >=20 > That's not a good place for these two sentences. HOBA registration > messages don't contain a challenge, and the general discussion of > replay attacks belongs under Security Considerations, not Registration. >=20 > In Section 9.4 and 9.5, I see the following proposed as part of IANA > registry contents: >=20 > an unformatted string, at the user's/UA's whim >=20 > I get the point, but it's still not appropriate for an IANA registry > - remove ", at the user's/UA's whim". >=20 > Appendix A appears to assume that human-memorable passwords are stored i= n > the clear in server databases. It should also briefly discuss the use > of one-way functions, especially computationally intensive ones, to > generate stored password verifiers. HOBA is still superior by comparison= , > as the one-way functions only increase the difficulty of dictionary > attack, whereas dictionary attack on HOBA keys is pointless when > sufficiently large keys are used. >=20 > idnits 2.13.01 found the references to W3C's web site (www.w3.org) in > Section 4, e.g., >=20 > 389 One element is required for HOBA-js: localStorage (see http:// > 390 www.w3.org/TR/webstorage/) from HTML5 can be used for persistent k= ey > 391 storage. >=20 > I think idnits can be ignored, even though the "right way" to fix this is= to > move each URL to a reference and cite the reference in Section 4. >=20 > OTOH, idnits did not complain about the normative reference to RFC 20 ;-)= . >=20 > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- >=20 > Most of these questions are n/a because this draft describes an extension > to HTTP authentication, and RFC 5706's concerns would apply primarily to > HTTP and HTTP authentication. >=20 > A.1.1 Has deployment been discussed? >=20 > Yes, section 6 discusses how a user would deploy this for her access to w= eb > servers. >=20 > A.1.4. Have the Requirements on other protocols and functional > components been discussed? >=20 > Yes, the discussion of how this functions within HTTP is sufficient. >=20 > Major issues [3] and [4] fall into this category, but in both cases, > I think they're probably text oversights that are easy to fix. >=20 > A.2.7 Is security management discussed? >=20 > Not really, but this is an Experimental RFC. I would expect that the > experimental use of HOBA will yield insight into server key database > structure/management, key lifecycle management (e.g., revocation), > account management techniques/processes, etc. >=20 > A.3. Documentation >=20 > I do not expect significant operational impact. >=20 > Section 10 notes the existence of two implementations of HOBA-JS and > one implementation of HOBA-http. That's a good start for an experiment. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From nobody Tue Dec 16 05:30:44 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AB51A1B4F; Tue, 16 Dec 2014 05:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2ZgDBPtW-mt; Tue, 16 Dec 2014 05:30:27 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id DD1941A1AEA; Tue, 16 Dec 2014 05:30:26 -0800 (PST) Received: from [192.168.1.26] (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 6DCCA15A01E4; Tue, 16 Dec 2014 14:30:25 +0100 (CET) Message-ID: <549033EE.2070302@greenbytes.de> Date: Tue, 16 Dec 2014 14:30:22 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: ietf@ietf.org References: <20141210142247.26304.1220.idtracker@ietfa.amsl.com> In-Reply-To: <20141210142247.26304.1220.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/T1zHsddqum8TKBlYadNPTc6N-Yo Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 13:30:31 -0000 Hi there, see below my feedback on draft-ietf-httpauth-hoba-07. Best regards, Julian -- feedback here -- 1. Introduction HTTP Origin-Bound Authentication (HOBA) is an authentication design that can be used as an HTTP authentication scheme [RFC7235] and for Javascript-based authentication embedded in HTML. The main goal of HOBA is to offer an easy-to-implement authentication scheme that is not based on passwords, but that can easily replace HTTP or HTML forms-based password authentication. Deployment of HOBA can reduce or eliminate password entries in databases, with potentially significant security benefits. "HTTP or HTML forms-based password authentication" reads weird. Maybe "HTTP authentication [RFC7235] or authentication based on HTML forms and cookies [ref]"? HOBA is an HTTP authentication mechanism that complies with the framework for such schemes [RFC7235]. As a JavaScript design, HOBA demonstrates a way for clients and servers to interact using the same credentials that are used by the HTTP authentication scheme. Also confusing. Maybe state upfront that you define two different protocols (sharing algorithms), one as HTTP auth scheme, one using JS. When done, use terminology conistently ("HOBA", HOBA HTTP auth scheme", "HOBA JS whatever"). [I see you later defined HOBA-http and HOBA-js; maybe do this earlier] Current username/password authentication methods such as HTTP Basic, HTTP Digest, and web forms have been in use for many years but are Maybe add citations for these schemes? ... HOBA session management is identical to username/password session management, with a server-side session management tool or script inserting a session cookie into the output to the browser. HOBA still requires TLS to prevent session cookie hijacking. At this point you absolutely need to cite the Cookie spec. HOBA keys are "bare keys", so there is no need for the semantic overhead of PKIX certificates, particularly with respect to naming and trust anchors. The client public key ("CPK") structures in HOBA do not have any publicly-visible identifier for the user who possesses the corresponding private key, nor the web-origin with which the client is using the CPK. Expand "PKIX". HOBA also defines some services that are required for modern HTTP authentication: Avoid lowercase BCP14 terms. Also, don't understand "modern" here ;-) ... 1.1. Interfacing to Applications (Cookies) HOBA can be used as a drop-in replacement for password-based user authentication schemes used in common web applications. The simplest way is to (re-)direct the UA to a HOBA "Login" URL and for the response to a successful HTTP request containing a HOBA signature to set a session cookie [RFC6265]. Further interactions with the web application will then be secured via the session cookie, as is commonly done today. Does this apply to the HTTP authentication scheme, too? 1.2. Terminology ... This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] s/[RFC5234]/[RFC5234]./ Account: The term "account" is (loosely) used to refer to whatever data structure(s) the server maintains that are associated with an identity. That will contain of at least one CPK and a web-origin; it will also optionally include an HTTP "realm" as defined in the HTTP authentication specification. [RFC7235]. It might also involve many s/. [RFC7235]./[RFC7235]./ ... 2. The HOBA Authentication Scheme HOBA-TBS = len ":" nonce len ":" alg len ":" origin len ":" [ realm ] len ":" kid len ":" challenge len = 1*DIGIT nonce = 1*base64urlchars alg = 1*2DIGIT origin = scheme "://" authority ":" port realm = unreserved kid = 1*base64urlchars challenge = 1*base64urlchars ; Characters for Base64URL encoding from Table 2 of RFC 4648 base64urlchars = %x30-39 ; Digits / %x41-5A ; Uppercase letters / %x61-7A ; Lowercase letters / "-" / "_" / "=" ; Special characters Figure 1: To-be-signed data for HOBA ...specify a proper ABNF production for "unreserved". ...say where scheme, authority etc come from. ...maybe clarify that all of these characters are in US-ASCII (wrt to encoding into octets) ... o nonce: is a random value chosen by the UA and MUST be base64url encoded before being included in the HOBA-TBS value. (base64url encoding is defined in [RFC4648].) UAs MUST be able to use at least 32 bits of randomness in generating a nonce. UAs SHOULD be able to use 64 or more bits of randomness for nonces. "MUST be able to use"... doesn't sound testable. ... The HOBA "client result" is a dot-separated string that includes the signature and is sent in the HTTP Authorized header field value using "Authorized"? 3. Introduction to the HOBA-http Mechanism ... o A "max-age" attribute MUST be included that specifies the number of seconds from the time the HTTP response is emitted for which responses to this challenge can be accepted for example "max-age: 10" would indicatge ten seconds. If max-age is set to zero, then that means that only one signature will be accepted for this challenge. s/indicatge/indicate/ o A "realm" attribute MAY be included to indicate the scope of protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. The "realm" attribute MUST NOT appear more than once. ... additional mechanisms to validate the signature. If the validation fails, or if the server chooses reject the signature for any reason whatsoever, the server aborts the transaction via a 401 Unauthorized HTTP response. "..fails the request with a 401..." (I'd prefer not to speak of transactions here) Note that a HOBA signature is good for however long a non-zero max- age attribute allows. This means that replay is possible within the s/attribute/parameter/ ... 4. Introduction to the HOBA-js Mechanism ... One element is required for HOBA-js: localStorage (see http:// www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key Add proper reference. storage. For example, an implementation would store a dictionary account identifier, public key and private key tuples in the origin's localStorage for subsequent authentication requests. How this information is actually stored in localStorage is an implementation detail. This type of key storage relies on the security properties of the same-origin policy that localStorage enforces. See the security considerations for discussion about attacks on localStorage. Note that IndexedDB (See http://www.w3.org/TR/IndexedDB/) is an alternative to localStorage that can also be used here. And here. Because of JavaScript's same-origin policy, scripts from subdomains do not have access to the same localStorage that scripts in their parent domains do. For larger or more complex sites, this could be an issue that requires enrollment into subdomains, which could be a hassle for users. One way to get around this is to use session cookies because they can be used across subdomains. That is, with HOBA-js, the user might log in using a single well-known domain, and then the server uses session cookies to navigate around a site. Another element will be highly desirable for HOBA-js when it becomes available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In lieu of WebCrypto, JavaScript crypto libraries can be employed with the known deficiencies of their pseudo-random number generators and the general immaturity of those libraries. And here. 5.3. Authentication Phase ... If this stage of the process involves additional information for authentication, such as asking the user which account she wants to use (in the case where a UA is used for multiple accounts on a site), the server can prompt the user for account identifying information or the user could choose based on HTML offered by the server before the 401 is triggered. None of this is standardized: it all follows the s/401/401 response/ server's security policy and session flow. At the end of this, the server probably assigns or updates a session cookie for the client. 6. Other Parts of the HOBA Process ... There are many use cases for these URLs to redirect to other URLs: a site that does registration through a federated site, a site that only does registration under HTTPS, and so on. Like any HTTP client, HOBA-http clients have to be able to handle redirection of these URLs. However, as that would potentially cause security issues when s/URLs/requests/ 6.1. Registration Normally, a registration (also called "joining") is expected to happen after a UA receives a WWW-Authenticate for a web-origin and s/WWW-Authenticate/401 response/ (right?) ... The registration message for HOBA-http is sent as a POST message to the URL ".well-known/hoba/register" with an HTML form (x-www-form- encoded) described below; The registration message for HOBA-js can be Need citation for payload format. Why does this need to be an HTML form, btw? ... o did: a UTF8 string that specifies the device identifier. This can be used to help a user be confident that authentication has worked, e.g., following authentication some web content might say "You last logged in from device 'did' at time T." An example would be good to people note that many characters (plus all non-ASCII characters) need to be percent-escaped in this payload format. 6.1.1. Hobareg Definition ... For this reason the server MUST add a header to the response message s/header/header field/ when the registration has succeded to indicate the new state. The header to be used is "Hobareg" and the value when registration has succeeded is to be "regok". When registration is inwork (e.g. on an HTTP response for an interstitial page) the server MAY add this header with a value of "reginwork". See Section 9.6 for the relevant IANA registration of this header field. Could this use the Authentication-Info header field currently defined in DIGEST? ... o Only one single value is allowed in a Hobareg header field. Should more than one (a list) be encountered, that should be interpreted as being the same as "inwork." Misleading; just state that any ABNF-invalid value is to be interpreted as "inwork". ... o Since Hobareg is only meant for responses it ought not appear in a PUT request. Drop the part about PUT; not allowed in request means not allowed in requests... ... o Intermediaries should never insert, delete or modify a Hobareg header field. SHOULD? or even MUST? 6.2. Associating Additional Keys to an Exiting Account I'll assume you meant to say "Existing" :-) 6.3. Logging Out The user can tell the server it wishes to log out. With HOBA-http, this is done by sending any HOBA-authenticated HTTP message to the URL ".well-known/hoba/logout" on the site in question. The UA SHOULD also delete session cookies associated with the session so that the user's state is no longer "logged in." Nope. Don't define this for GET (or any "safe" method). POST would work. 8.1. Privacy considerations HOBA does impact to some extent on privacy and could be considered to s/on// represent a super-cookie to the server, or to any entity on the path from UA to HTTP server that can see the HOBA signature. This is because we need to send a key identifier as part of the signature and that will not vary for a given key. For this reason, and others, it is strongly RECOMMENDED to only use HOBA over server-authenticated TLS and to migrate web sites using HOBA to only use "https" URLs. UAs SHOULD provide users a way to manage their CPKs. Ideally, there would be a way for a user to maintain their HOBA details for a site while at the same time deleting other site information such as cookies or non-HOBA HTML5 LocalStorage. However, as this is likely to be complex and appropriate user interfaces counter intutitive, we exepect that UAs that implement HOBA will likely treat HOBA s/exepect/expect/ information as just some more site data, that would disappear should the user choose to "forget" that site. 9.6. Hobareg HTTP Header s/Header/Header Field/ 12.1. Normative References 12.2. Informative References [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. This is likely normative. [bonneau] Bonneau, , "The science of guessing: analyzing an anonymized corpus of 70 million passwords.", Security and Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012. , 2012. This reference looks broken (interpunction-wise). Appendix A. Problems with Passwords ... Using memorizable passwords on unencrypted channels also poses risks to the users. If a web site uses either the HTTP Plain s/Plain/Basic/ ? (also add ref) Appendix B. Example The following values show an example of HOBA-http authentication to the origin https://example.com:443 Carriage-returns have been added s/443/443./ From nobody Tue Dec 16 05:31:56 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2731A1B0C; Tue, 16 Dec 2014 05:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcZs6rtx2Oeo; Tue, 16 Dec 2014 05:31:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6EB1A1AEA; Tue, 16 Dec 2014 05:31:49 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LqQzp-1XNfnP2yqP-00e65R; Tue, 16 Dec 2014 14:31:47 +0100 Message-ID: <5490343F.9070006@gmx.de> Date: Tue, 16 Dec 2014 14:31:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: ietf@ietf.org References: <20141210142247.26304.1220.idtracker@ietfa.amsl.com> In-Reply-To: <20141210142247.26304.1220.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:JLxdjGj3AoezCUWNonYnElHLfouSM2v/lM0cOg8pBgLAnIgo7UV oEBHVpozjYr3brP+dFbC6nuiSeuVzCWupvZLmAR3aCDZgl6LF9Np3b+jMGXSDc2CZMk/Fuk roGAvTYIoV4BebnpCLFyVUa47GLiNxeB46xn6rXOOR6OsqMN1Y61YB2fNmPyD+NNzeOoTMj PbPIt5c9/k28uKkjbFFMQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Ujj1PjW8M4Ly3luwI-WG7BkGJc8 Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 13:31:53 -0000 Hi there, see below my feedback on draft-ietf-httpauth-hoba-07. Best regards, Julian -- feedback here -- 1. Introduction HTTP Origin-Bound Authentication (HOBA) is an authentication design that can be used as an HTTP authentication scheme [RFC7235] and for Javascript-based authentication embedded in HTML. The main goal of HOBA is to offer an easy-to-implement authentication scheme that is not based on passwords, but that can easily replace HTTP or HTML forms-based password authentication. Deployment of HOBA can reduce or eliminate password entries in databases, with potentially significant security benefits. "HTTP or HTML forms-based password authentication" reads weird. Maybe "HTTP authentication [RFC7235] or authentication based on HTML forms and cookies [ref]"? HOBA is an HTTP authentication mechanism that complies with the framework for such schemes [RFC7235]. As a JavaScript design, HOBA demonstrates a way for clients and servers to interact using the same credentials that are used by the HTTP authentication scheme. Also confusing. Maybe state upfront that you define two different protocols (sharing algorithms), one as HTTP auth scheme, one using JS. When done, use terminology conistently ("HOBA", HOBA HTTP auth scheme", "HOBA JS whatever"). [I see you later defined HOBA-http and HOBA-js; maybe do this earlier] Current username/password authentication methods such as HTTP Basic, HTTP Digest, and web forms have been in use for many years but are Maybe add citations for these schemes? ... HOBA session management is identical to username/password session management, with a server-side session management tool or script inserting a session cookie into the output to the browser. HOBA still requires TLS to prevent session cookie hijacking. At this point you absolutely need to cite the Cookie spec. HOBA keys are "bare keys", so there is no need for the semantic overhead of PKIX certificates, particularly with respect to naming and trust anchors. The client public key ("CPK") structures in HOBA do not have any publicly-visible identifier for the user who possesses the corresponding private key, nor the web-origin with which the client is using the CPK. Expand "PKIX". HOBA also defines some services that are required for modern HTTP authentication: Avoid lowercase BCP14 terms. Also, don't understand "modern" here ... 1.1. Interfacing to Applications (Cookies) HOBA can be used as a drop-in replacement for password-based user authentication schemes used in common web applications. The simplest way is to (re-)direct the UA to a HOBA "Login" URL and for the response to a successful HTTP request containing a HOBA signature to set a session cookie [RFC6265]. Further interactions with the web application will then be secured via the session cookie, as is commonly done today. Does this apply to the HTTP authentication scheme, too? 1.2. Terminology ... This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] s/[RFC5234]/[RFC5234]./ Account: The term "account" is (loosely) used to refer to whatever data structure(s) the server maintains that are associated with an identity. That will contain of at least one CPK and a web-origin; it will also optionally include an HTTP "realm" as defined in the HTTP authentication specification. [RFC7235]. It might also involve many s/. [RFC7235]./[RFC7235]./ ... 2. The HOBA Authentication Scheme HOBA-TBS = len ":" nonce len ":" alg len ":" origin len ":" [ realm ] len ":" kid len ":" challenge len = 1*DIGIT nonce = 1*base64urlchars alg = 1*2DIGIT origin = scheme "://" authority ":" port realm = unreserved kid = 1*base64urlchars challenge = 1*base64urlchars ; Characters for Base64URL encoding from Table 2 of RFC 4648 base64urlchars = %x30-39 ; Digits / %x41-5A ; Uppercase letters / %x61-7A ; Lowercase letters / "-" / "_" / "=" ; Special characters Figure 1: To-be-signed data for HOBA ...specify a proper ABNF production for "unreserved". ...say where scheme, authority etc come from. ...maybe clarify that all of these characters are in US-ASCII (wrt to encoding into octets) ... o nonce: is a random value chosen by the UA and MUST be base64url encoded before being included in the HOBA-TBS value. (base64url encoding is defined in [RFC4648].) UAs MUST be able to use at least 32 bits of randomness in generating a nonce. UAs SHOULD be able to use 64 or more bits of randomness for nonces. "MUST be able to use"... doesn't sound testable. ... The HOBA "client result" is a dot-separated string that includes the signature and is sent in the HTTP Authorized header field value using "Authorized"? 3. Introduction to the HOBA-http Mechanism ... o A "max-age" attribute MUST be included that specifies the number of seconds from the time the HTTP response is emitted for which responses to this challenge can be accepted for example "max-age: 10" would indicatge ten seconds. If max-age is set to zero, then that means that only one signature will be accepted for this challenge. s/indicatge/indicate/ o A "realm" attribute MAY be included to indicate the scope of protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. The "realm" attribute MUST NOT appear more than once. ... additional mechanisms to validate the signature. If the validation fails, or if the server chooses reject the signature for any reason whatsoever, the server aborts the transaction via a 401 Unauthorized HTTP response. "..fails the request with a 401..." (I'd prefer not to speak of transactions here) Note that a HOBA signature is good for however long a non-zero max- age attribute allows. This means that replay is possible within the s/attribute/parameter/ ... 4. Introduction to the HOBA-js Mechanism ... One element is required for HOBA-js: localStorage (see http:// www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key Add proper reference. storage. For example, an implementation would store a dictionary account identifier, public key and private key tuples in the origin's localStorage for subsequent authentication requests. How this information is actually stored in localStorage is an implementation detail. This type of key storage relies on the security properties of the same-origin policy that localStorage enforces. See the security considerations for discussion about attacks on localStorage. Note that IndexedDB (See http://www.w3.org/TR/IndexedDB/) is an alternative to localStorage that can also be used here. And here. Because of JavaScript's same-origin policy, scripts from subdomains do not have access to the same localStorage that scripts in their parent domains do. For larger or more complex sites, this could be an issue that requires enrollment into subdomains, which could be a hassle for users. One way to get around this is to use session cookies because they can be used across subdomains. That is, with HOBA-js, the user might log in using a single well-known domain, and then the server uses session cookies to navigate around a site. Another element will be highly desirable for HOBA-js when it becomes available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In lieu of WebCrypto, JavaScript crypto libraries can be employed with the known deficiencies of their pseudo-random number generators and the general immaturity of those libraries. And here. 5.3. Authentication Phase ... If this stage of the process involves additional information for authentication, such as asking the user which account she wants to use (in the case where a UA is used for multiple accounts on a site), the server can prompt the user for account identifying information or the user could choose based on HTML offered by the server before the 401 is triggered. None of this is standardized: it all follows the s/401/401 response/ server's security policy and session flow. At the end of this, the server probably assigns or updates a session cookie for the client. 6. Other Parts of the HOBA Process ... There are many use cases for these URLs to redirect to other URLs: a site that does registration through a federated site, a site that only does registration under HTTPS, and so on. Like any HTTP client, HOBA-http clients have to be able to handle redirection of these URLs. However, as that would potentially cause security issues when s/URLs/requests/ 6.1. Registration Normally, a registration (also called "joining") is expected to happen after a UA receives a WWW-Authenticate for a web-origin and s/WWW-Authenticate/401 response/ (right?) ... The registration message for HOBA-http is sent as a POST message to the URL ".well-known/hoba/register" with an HTML form (x-www-form- encoded) described below; The registration message for HOBA-js can be Need citation for payload format. Why does this need to be an HTML form, btw? ... o did: a UTF8 string that specifies the device identifier. This can be used to help a user be confident that authentication has worked, e.g., following authentication some web content might say "You last logged in from device 'did' at time T." An example would be good to people note that many characters (plus all non-ASCII characters) need to be percent-escaped in this payload format. 6.1.1. Hobareg Definition ... For this reason the server MUST add a header to the response message s/header/header field/ when the registration has succeded to indicate the new state. The header to be used is "Hobareg" and the value when registration has succeeded is to be "regok". When registration is inwork (e.g. on an HTTP response for an interstitial page) the server MAY add this header with a value of "reginwork". See Section 9.6 for the relevant IANA registration of this header field. Could this use the Authentication-Info header field currently defined in DIGEST? ... o Only one single value is allowed in a Hobareg header field. Should more than one (a list) be encountered, that should be interpreted as being the same as "inwork." Misleading; just state that any ABNF-invalid value is to be interpreted as "inwork". ... o Since Hobareg is only meant for responses it ought not appear in a PUT request. Drop the part about PUT; not allowed in request means not allowed in requests... ... o Intermediaries should never insert, delete or modify a Hobareg header field. SHOULD? or even MUST? 6.2. Associating Additional Keys to an Exiting Account I'll assume you meant to say "Existing" 6.3. Logging Out The user can tell the server it wishes to log out. With HOBA-http, this is done by sending any HOBA-authenticated HTTP message to the URL ".well-known/hoba/logout" on the site in question. The UA SHOULD also delete session cookies associated with the session so that the user's state is no longer "logged in." Nope. Don't define this for GET (or any "safe" method). POST would work. 8.1. Privacy considerations HOBA does impact to some extent on privacy and could be considered to s/on// represent a super-cookie to the server, or to any entity on the path from UA to HTTP server that can see the HOBA signature. This is because we need to send a key identifier as part of the signature and that will not vary for a given key. For this reason, and others, it is strongly RECOMMENDED to only use HOBA over server-authenticated TLS and to migrate web sites using HOBA to only use "https" URLs. UAs SHOULD provide users a way to manage their CPKs. Ideally, there would be a way for a user to maintain their HOBA details for a site while at the same time deleting other site information such as cookies or non-HOBA HTML5 LocalStorage. However, as this is likely to be complex and appropriate user interfaces counter intutitive, we exepect that UAs that implement HOBA will likely treat HOBA s/exepect/expect/ information as just some more site data, that would disappear should the user choose to "forget" that site. 9.6. Hobareg HTTP Header s/Header/Header Field/ 12.1. Normative References 12.2. Informative References [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. This is likely normative. [bonneau] Bonneau, , "The science of guessing: analyzing an anonymized corpus of 70 million passwords.", Security and Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012. , 2012. This reference looks broken (interpunction-wise). Appendix A. Problems with Passwords ... Using memorizable passwords on unencrypted channels also poses risks to the users. If a web site uses either the HTTP Plain s/Plain/Basic/ ? (also add ref) Appendix B. Example The following values show an example of HOBA-http authentication to the origin https://example.com:443 Carriage-returns have been added s/443/443./ From nobody Wed Dec 17 14:08:46 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550231A87C5 for ; Wed, 17 Dec 2014 14:08:34 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyeLe6ZRWYqX for ; Wed, 17 Dec 2014 14:08:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F081A8785 for ; Wed, 17 Dec 2014 14:08:28 -0800 (PST) Received: from [192.168.2.160] ([93.217.74.159]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M2XkX-1XkNkI1b53-00sQPi; Wed, 17 Dec 2014 23:08:25 +0100 Message-ID: <5491FECE.8080704@gmx.de> Date: Wed, 17 Dec 2014 23:08:14 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Yoav Nir , IETF HTTP Auth References: <20141202111608.27803.85751.idtracker@ietfa.amsl.com> <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> In-Reply-To: <60D2DF51-5CD9-4A55-8031-4F974C0F8DF9@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EcUyWTVh63jZVVrc2ubn8wvv/2HfB0BxM1fE+BA+jXc0qw/G4dC RYatjUybl5RusihpFi3iGCa0V9ZdZUuLWkIbRQZeRcSLLx94t1049GwDaOuGZ52X9fp0stP Zh5hGolIYokT9fOlSNq/s3kkUWjNerLya1ihEgitn+6sHY0XKml3v9bKsB5rLirwZhq0xUd iy7Rp1zCDQiYBQm21FFlg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/btFpigZTDYUBRAIQ_hLjVsQadX4 Subject: Re: [http-auth] Working Group Last Call for draft-ietf-httpauth-basicauth-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:08:36 -0000 On 2014-12-02 12:19, Yoav Nir wrote: > Thank you, Julian > > This begins a 2-week WGLC for this document. > > Please take the time to read through and post any comments to the list. > > Cheers > > Matt & Yoav > ... ...and the WGLC ended yesterday. My current edits are over here: Those are all editorial, mostly based on WGLC feedback (thanks). In the LC, there were also requests to change prose to use more BCP14 terms, and also to make the use of the charset parameter required; I did not make any changes with respect to this, because: - I believe our use of BCP14 terms is consistent with the HTTP specs, and - The whole premise of introducing the charset parameter was to leave existing conforming implementations conforming; thus it was always meant to be truly OPTIONAL. Finally, while reviewing DIGEST, I noticed that there are security considerations in RFC 2617 that should have been in RFC 7235, namely: and I believe the best way to address this is to track this as a TODO for RFC7235bis (which I intend to get to in due time). Chairs: should I submit what I currently have, or are more changes needed? Best regards, Julian From nobody Fri Dec 19 08:04:55 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5551A89B4; Fri, 19 Dec 2014 08:04:37 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8AZC-AuYlse; Fri, 19 Dec 2014 08:04:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DF31A89FF; Fri, 19 Dec 2014 08:03:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219160350.11594.56775.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 08:03:50 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/zwWfp-G8_WIhokRg5TWkUe-i7Do Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-update-04.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 16:04:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : The 'Basic' HTTP Authentication Scheme Author : Julian F. Reschke Filename : draft-ietf-httpauth-basicauth-update-04.txt Pages : 15 Date : 2014-12-19 Abstract: This document defines the "Basic" Hypertext Transfer Protocol (HTTP) Authentication Scheme, which transmits credentials as userid/password pairs, obfuscated by the use of Base64 encoding. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-update-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Dec 20 07:33:18 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803451A8942 for ; Sat, 20 Dec 2014 07:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng7Ag6KBff1P for ; Sat, 20 Dec 2014 07:33:06 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D201A88C2 for ; Sat, 20 Dec 2014 07:33:05 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so2183441lbv.0 for ; Sat, 20 Dec 2014 07:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OjFOx5nxg1Uc7MIpI9nRseyXqM6Lsth61EDhmxzjamI=; b=WaYygDdMTA6mhxRG/ls9Gukkti5l3NsQgHLansBXsBIT3keEVbEizIQyEop6aKvAWT k02REXVR0EhawbZYzsBMJK0ZPrH8KFHfxnkFZBKdo1fLTGu9oeNbASTXnnXeV/0L/LIq S812VOnNQcB/DJKg044mcu3j2KLcRQ2DQiktCwms5+MdLK9rtmXXwTSze518tONHyzXR ti4kI52hiyxpnYQuDR3n7DVmCvN/8msKILAFUfHnn/TJRdg4lkmy42M7XdKRxgkLMGRY bhj/27uadejU+2hLmUBUC8qy6g/tZmbnPaNzc+DyZCFKsuF1dRKGv9Yt1t7CDywVhRQ+ htzA== MIME-Version: 1.0 X-Received: by 10.112.91.43 with SMTP id cb11mr13032438lbb.63.1419089583671; Sat, 20 Dec 2014 07:33:03 -0800 (PST) Received: by 10.114.27.162 with HTTP; Sat, 20 Dec 2014 07:33:03 -0800 (PST) In-Reply-To: <548DBA0B.6080201@greenbytes.de> References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA0B.6080201@greenbytes.de> Date: Sat, 20 Dec 2014 10:33:03 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=001a11348fd68a0f6e050aa78a56 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/9x5LhhbNUtQpB2iM-2oOkBswtIY Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 15:33:15 -0000 --001a11348fd68a0f6e050aa78a56 Content-Type: text/plain; charset=ISO-8859-1 Hi Julian, Thanks you very much for this detailed review. Please, see my reply inline... Regards, Rifaat On Sun, Dec 14, 2014 at 11:25 AM, Julian Reschke < julian.reschke@greenbytes.de> wrote: > Hi there, > > it's the first time I read this in a long time; apologies for the lack of > structure; and also that most of these should have been made during WGLC. > > > > Abstract > > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that may be used with the > authentication mechanism. > > s/may/can/ > > Also maybe: ...that can used with the *HTTP* authentication mechanism. > > 1 Introduction > > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that may be used with the > authentication mechanism. > > (see above) > > The details of the challenge-response authentication mechanism are > specified in the [RFC7235] document. > > ...in "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235]. > > The combination of this document with Basic [BASIC] and [RFC7235] > obsolete RFC2617. > > s/Basic/the definition of the "Basic" authentication scheme/ > s/RFC2617/RFC 2617/ > > 2.2 Algorithm Variants > > When used with the Digest mechanism, each one of the algorithms has > two variants: Session variant and non-Session variant. > > The non-Session variant is denoted by "", e.g. "SHA-256", > and the Session variant is denoted by "-sess", e.g. "SHA- > 256-sess". > > This comes very early; maybe it would be better mentioned later on. > > Yeah; I moved it to section 3.3 under the algorithm parameter. > 2.3 ABNF > > This specification uses the Augmented Backus-Naur Form (ABNF) > notation of [RFC5234]. > > Actually, you'll also need webdav/rfc7230.html#abnf.extension> (see below later). > > > realm > A string to be displayed to users so they know which username and > password to use. This string should contain at least the name of > the host performing the authentication and might additionally > indicate the collection of users who might have access. An example > might be "registered_users@gotham.news.com". (See section 2.2 of > [RFC7235] for more details). > > s/section/Section/ > > For the host name part, see . > > domain > A quoted, space-separated list of URIs, as specified in RFC 3986 > [RFC3986], that define the protection space. If a URI is an > abs_path, it is relative to the canonical root URL of the web- > origin. An absolute-URI in this list may refer to a different > server than the web-origin. The client can use this list to > determine the set of URIs for which the same authentication > information may be sent: any URI that has a URI in this list as a > > s/may/can/ or MAY > > prefix (after both have been made absolute) may be assumed to be > in the same protection space. If this parameter is omitted or its > value is empty, the client SHOULD assume that the protection space > consists of all URIs on the web-origin. All URIs in this list > SHOULD use the same scheme (https or http); mixing them is a bad > idea. > > web_origin and canonical root need definitions. > > I will point to RFC6454 for web-origin. Is there a document that defines canonical root? > Why is mixing them a "bad idea"? - maybe this could be explained better. > > This text was copied from RFC2617; I am not sure why they considered mixing http and https URIs a "bad idea". Anybody knows the reason behind this statement? > This parameter is not meaningful in Proxy-Authenticate header > fields, for which the protection space is always the entire proxy; > if present it should be ignored. > > MUST? SHOULD? > > I will change it to MUST > nonce > A server-specified data string which should be uniquely generated > each time a 401 response is made. It is recommended that this > > RECOMMENDED? > > Would there be a problem if it is a differen format? If no, why a > normative requirement here? > > It probably can be a different format; that is probably the reason the text is not normative and using recommended, instead of RECOMMENDED. > string be base64 or hexadecimal data. Specifically, since the > string is passed in the header field lines as a quoted string, the > double-quote character is not allowed. > > well, unless suitably escaped. > > The contents of the nonce are implementation dependent. The > > s/are/is/? > > quality of the implementation depends on a good choice. A nonce > might, for example, be constructed as the base 64 encoding of > > time-stamp H(time-stamp ":" ETag ":" secret-data) > > where time-stamp is a server-generated time, which preferably > > s/value/values/ > > includes micro or nano seconds, or other non-repeating value, ETag > is the value of the HTTP ETag header field associated with the > requested entity, and secret-data is data known only to the > server. With a nonce of this form a server would recalculate the > hash portion after receiving the client authentication header > field and reject the request if it did not match the nonce from > that header field or if the time-stamp value is not recent enough. > In this way the server can limit the time of the nonce's validity. > The inclusion of the ETag prevents a replay request for an updated > version of the resource. Including the IP address of the client in > the nonce would appear to offer the server the ability to limit > the reuse of the nonce to the same client that originally got it. > However, that would break proxy farms, where requests from a > single user often go through different proxies in the farm. Also, > IP address spoofing is not that hard. > > Do you need a proxy *farm* for this problem? > > I think that this is just one example. Are you suggesting that we remove that text? > An implementation might choose not to accept a previously used > nonce or a previously used digest, in order to protect against a > replay attack. Or, an implementation might choose to use one-time > nonces or digests for POST or PUT requests and a time-stamp for > GET requests. For more details on the issues involved see section > 5 of this document. > > s/section/Section/ > > ...why are these lowercase; aren't they generated by xml2rfc? If not, they > should, because otherwise they break too easily. > > I use nroff. > The nonce is opaque to the client. > > opaque > A string of data, specified by the server, which SHOULD be > returned by the client unchanged in the Authorization header field > of subsequent requests with URIs in the same protection space. It > is recommended that this string be base64 or hexadecimal data. > > (see above) > > Changed RECOMMENED to recommended. > stale > A case-insensitive flag indicating that the previous request from > the client was rejected because the nonce value was stale. If > stale is TRUE, the client MAY wish to simply retry the request > > "MAY wish" doesn't seem like a case for a BCP14 keyword. > > with a new encrypted response, without re-prompting the user for a > new username and password. The server SHOULD only set stale to > TRUE if it receives a request for which the nonce is invalid. If > stale is FALSE, or anything other than TRUE, or the stale > parameter is not present, the username and/or password are > invalid, and new values MUST be obtained. > > algorithm > A string indicating a pair of algorithms used to produce the > digest and a checksum. If this is not present it is assumed to be > "MD5". If the algorithm is not understood, the challenge should be > ignored (and a different one used, if there is more than one). > > Avoid lowercase BCP14 keywords. Either uppercase or choose something else > (here and later on). > > > userhash > This is an OPTIONAL parameter that is used by the server to > indicate that it supports username hashing. Valid values are: > "true" or "false". > > Defaults to false, I assume. > > Yes > > 3.4 The Authorization Request Header > > s/header/header field/ > > The client is expected to retry the request, passing an > Authorization header field line with Digest scheme, which is > defined according to the framework above. The values of the opaque > and algorithm fields must be those supplied in the WWW- > Authenticate response header field for the entity being requested. > > The request includes some or all of the following parameters: > > "some or all" reads weird... > > uri > The URI from request-target of the Request-Line; duplicated here > because proxies are allowed to change the Request-Line in transit. > > The request-target of the Request-Line isn't necessarily a URI... > > What do you suggest I do instead? > qop > Indicates what "quality of protection" the client has applied to > the message. Its value MUST be one of the alternatives the server > indicated it supports in the WWW-Authenticate header field. These > values affect the computation of the response. Note that this is a > single token, not a quoted list of alternatives as in WWW- > Authenticate. > > Can it use quoted-string nevertheless? > > nc > This parameter MUST be used by all implementations compliant with > this version of the Digest scheme. The "nc" parameter stands for > > I wonder why we need to say "compliant with this version"? > > I will reomve it > userhash > This OPTIONAL parameter is used by the client to indicate that the > username has been hashed. Valid values are: "true" or "false". > > Default? > > If a parameter or its value is improper, or required parameters are > missing, the proper response is 400 Bad Request. If the request- > > Is this a requirement? I think so. > Could it be a more specifc 4xx code? > What would be the benefit of changing this now? > digest is invalid, then a login failure should be logged, since > repeated login failures from a single client may indicate an attacker > attempting to guess passwords. The server implementation should be > > SHOULD? > > careful with the information being logged so that it won't put a > cleartext password (e.g. entered into the username field) into the > log. > > The definition of response above indicates the encoding for its > > s/of/of the/ > > value. The following definitions show how the value is computed. > > > > This creates a 'session key' for the authentication of subsequent > > double quotes? > > requests and responses which is different for each "authentication > session", thus limiting the amount of material hashed with any one > key. (Note: see further discussion of the authentication session in > section 3.6.) Because the server need only use the hash of the user > > s/need/needs/ > > credentials in order to create the A1 value, this construction could > be used in conjunction with a third party authentication service so > that the web server would not need the actual password value. The > specification of such a protocol is beyond the scope of this > specification. > > Also note that if integrity protection is applied (qop=auth-int), the > H(entity-body) is the hash of the entity body, not the message body - > it is computed before any transfer encoding is applied by the sender > and after it has been removed by the recipient. Note that this > includes multipart boundaries and embedded header fields in each part > of any multipart content-type. > > (reduce amout of "note that"...) > > 3.4.6 Various Considerations > > The "Method" value is the HTTP request method, in all-uppercase US- > ASCII letters, as specified in section 3.1.1 of [RFC7230]. The > > Hm, no. The registered methods happen to be all-uppercase, but method > names are case-sensitive. > > ok > Implementers should be aware of how authenticated transactions > > ...need to be... > > interact with shared caches. The HTTP/1.1 protocol specifies that > > s/The HTTP/1.1 protocol/HTTP/ > > when a shared cache (see [RFC7234]) has received a request containing > an Authorization header field and a response from relaying that > request, it MUST NOT return that response as a reply to any other > request, unless one of two Cache-Control (see section 3.2 of > [RFC7234]) directive was present in the response. If the original > response included the "must-revalidate" Cache-Control directive, the > cache MAY use the entity of that response in replying to a subsequent > request, but MUST first revalidate it with the origin server, using > the request header fields from the new request to allow the origin > server to authenticate the new request. Alternatively, if the > original response included the "public" Cache-Control directive, the > response entity MAY be returned in reply to any subsequent request. > > Do we need to replicate this information here? (Asking because the Basic > spec does not) > > I do not mind removing it, if it is explained somewhere else. I can just point to it here. > 3.5 The Authentication-Info Header > > The Authentication-Info header field is a generic field that MAY be > used by a server to communicate some information regarding the > successful authentication of a client response. The following is the > syntax of the header: > > Authentication-Info = auth-info > > auth-info = *auth-param > > This needs to be "#auth-param" and invoke the list ABNF extension from RFC > 7230. > > The auth-param is defined in [RFC7235]. > > ok > (I still believe we should extract this into a separate spec) > > 3.5.1 Digest Usage of Authentication-Info > > The Digest authentication scheme MAY add the Authentication-Info > header field in the confirmation request with some or all of the > following parameters: > > "Some or all" reads weird. > > > 3.6 Digest Operation > > Upon receiving the Authorization header field, the server MAY check > its validity by looking up the password that corresponds to the > submitted username. Then, the server MUST perform the same digest > operation (e.g. MD5, SHA-256) performed by the client, and compare > the result to the given response value. > > Note that the HTTP server does not actually need to know the user's > cleartext password. As long as H(A1) is available to the server, the > validity of an Authorization header field MAY be verified. > > s/MAY/can/ > > Because the client is required to return the value of the opaque > > s/required/REQUIRED/ > > parameter given to it by the server for the duration of a session, > the opaque data MAY be used to transport authentication session state > > s/MAY/can/ > > information. (Note that any such use can also be accomplished more > easily and safely by including the state in the nonce.) For example, > a server could be responsible for authenticating content that > actually sits on another server. It would achieve this by having the > first 401 response include a domain parameter whose value includes a > URI on the second server, and an opaque parameter whose value > contains the state information. The client will retry the request, at > which time the server might respond with a 301/302 redirection, > > Do not exclude 307/308. Just say "HTTP Redirection (Section 6.4 of > [RFC7231])" > > ok > As with the basic scheme, proxies MUST be completely transparent in > > s/basic/"Basic"/ > > Is it wise to cite that hear? > > I will remove it. > the Digest access authentication scheme. That is, they MUST forward > the WWW-Authenticate, Authentication-Info and Authorization header > fields untouched. If a proxy wants to authenticate a client before a > request is forwarded to the server, it can be done using the Proxy- > Authenticate and Proxy-Authorization header fields described in > section 3.8 below. > > > 3.7 Security Protocol Negotiation > > It is useful for a server to be able to know which security schemes a > client is capable of handling. > > It is possible that a server MAY want to require Digest as its > > s/MAY want/wants/ > > authentication method, even if the server does not know that the > client supports it. A client is encouraged to fail gracefully if the > server specifies only authentication schemes it cannot handle. > > When a server receives a request to access a resource, the server > might challenge the client by responding with "401 Unauthorized" > status code, and include one or more WWW-Authenticate header fields. > > s/status code/response/ > > If the server challenges with multiple Digest header fields, then > each one of these header fields MUST use a different digest > > You could have multiple challenges in a single header field instance. > > Can you please elaborate? > algorithm. The server MUST add these Digest header fields to the > response in order of preference, starting with the most preferred > header field, followed by the less preferred header fields. > > most preferred algorithm? > > When the client receives the response it SHOULD use the topmost > header field that it supports, unless a local policy dictates > > First challenge. > > otherwise. The client SHOULD ignore any challenge it does not > understand. > > MUST, I believe. > > Yes > Also, this sounds like requirements that are generic to WWW-A, not > specific to Digest, no? > > Yes. it is. Is it specified somewhere else? > > 3.8 Proxy-Authenticate and Proxy-Authorization > > The digest authentication scheme MAY also be used for authenticating > > s/MAY/can/ > > users to proxies, proxies to proxies, or proxies to origin servers by > use of the Proxy-Authenticate and Proxy-Authorization header fields. > These header fields are instances of the Proxy-Authenticate and > Proxy- Authorization header fields specified in sections 4.2 and 4.3 > > s/Proxy- Authorization/Proxy-Authorization/ > > of the HTTP/1.1 specification [RFC7235] and their behavior is subject > to restrictions described there. The transactions for proxy > authentication are very similar to those already described. Upon > receiving a request which requires authentication, the proxy/server > MUST issue the "407 Proxy Authentication Required" response with a > "Proxy-Authenticate" header field. The digest-challenge used in the > Proxy-Authenticate header field is the same as that for the WWW- > Authenticate header field as defined above in section 3.2.1. > > I don't see a Section 3.2.1. > > It should be 3.3. > > 3.9 Examples > > 3.9.1 Example with SHA-256 and MD5 > > > The following example assumes that an access protected document is > being requested from the server via a GET request. The URI of the > document is http://www.nowhere.org/dir/index.html". Both client and > server know that the username for this document is "Mufasa" and the > password is "Circle of Life" ( with one space between each of the > three words). > > Need to use RFC 2606 hostnames. > > ok > The first time the client requests the document, no Authorization > header field is sent, so the server responds with: > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: Digest > realm="http-auth@example.org", > qop="auth, auth-int", > algorithm="SHA-256", > nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", > opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" > WWW-Authenticate: Digest > realm="http-auth@example.org", > qop="auth, auth-int", > algorithm="MD5", > nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", > opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" > > The client MAY prompt the user for their username and password, after > > s/MAY/can/ or /will/ > > Maybe also point out that you could also send...: > > WWW-Authenticate: Digest realm="http-auth@example.org", > qop="auth, auth-int", > algorithm="SHA-256", > nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", > opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS", > Digest realm="http-auth@example.org", > qop="auth, auth-int", > algorithm="MD5", > nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", > opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" > > Later: > > > Authorization:Digest username="Mufasa", > > insert an SP after the colon. > > realm="http-auth@example.org", > uri="/dir/index.html", > algorithm=MD5, > nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", > nc=00000001, > cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ", > qop=auth, > response="8ca523f5e9506fed4657c9700eebdbec", > opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" > > > If the client chooses to use the SHA-256 algorithm for calculating > the response, the client responds with a new request including the > following Authorization header field: > > > Authorization:Digest username="Mufasa", > realm="http-auth@example.org", > uri="/dir/index.html", > algorithm=SHA-256, > nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", > nc=00000001, > cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ", > qop=auth, > response="753927fa0e85d155564e2e272a28d1802ca10daf449 > 6794697cf8db5856cb6c1", > opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" > > 3.9.2 Example with SHA-512-256, Charset, and Userhash > > The following example assumes that an access protected document is > being requested from the server via a GET request. The URI for the > request is "http://api.example.org/doe.json". Both client and server > know the userhash of the username, support the UTF-8 charset, and use > > s/UTF-8 charset/UTF-8 character encoding scheme/ > > the SHA-512-256 algorithm. The username for the request is "Jason > Doe" and the password is "Secret, or not?". > > It would be good to have non-ASCII characters in the example. > > The first time the client requests the document, no Authorization > header field is sent, so the server responds with: > > > HTTP/2.0 401 Unauthorized > > HTTP/2.0???? > Should be 1.1. > WWW-Authenticate: Digest > realm="api@example.org", > qop=auth, > algorithm=SHA-512-256, > nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", > opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", > charset=UTF-8, > userhash=true > > > The client MAY prompt the user for the required credentials and send > a new request with following Authorization header field: > > Authorization: Digest > username="488869477bf257147b804c45308cd62ac4e25eb717 > b12b298c79e62dcea254ec", > realm="api@example.org", > uri="/doe.json", > algorithm=SHA-512-256, > nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", > nc=00000001, > cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v", > qop=auth, > response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d > 6c861229025f607a79dd", > opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", > userhash=true > > If the client can not provide a hashed username for any reason, the > client MAY try a request with this Authorization header field: > > Authorization: Digest > username*=UTF-8''J%C3%A4s%C3%B8n%20Doe, > realm="api@example.org", > uri="/doe.json", > algorithm=SHA-512-256, > nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", > nc=00000001, > cnonce="NTg6RKcb9boFIAS3KrFK9BGeh+iDa/sm6jUMp2wds69v", > qop=auth, > response="ae66e67d6b427bd3f120414a82e4acff38e8ecd9101d6 > c861229025f607a79dd", > opaque="HRPCssKJSGjCrkzDg8OhwpzCiGPChXYjwrI2QmXDnsOS", > userhash=false > > Wait, you can't do that. You'll need to formally state that some or all of > your auth-params can be sent using the RFC 5987 encoding (and upfront, not > in the example here). > ok > For the username, recipients MUST support all characters defined in > the "UsernameCasePreserved" profile defined in in Section 3.3 of > [PRECIS], with the exception of the colon (":") character. > > This is copied from Basic. Yes, I mentioned that I will use the same text you provided with Digest. > Is it true for Digest as well? > I thought that was the conclusion based on the following: http://www.ietf.org/mail-archive/web/http-auth/current/msg02005.html > If the user agent does not support the encoding indicated by the > server, it MUST fail the request. > > That sounds like a deployment problem. Also it reads weird given the fact > that only one value ("UTF-8") is allowed. > > Any suggestion on how to reword that? > > 5.6 Weakness Created by Multiple Authentication Schemes > > An HTTP/1.1 server MAY return multiple challenges with a 401 > (Authenticate) response, and each challenge MAY use a different auth- > scheme. A user agent MUST choose to use the strongest auth- scheme it > > s/auth- scheme/auth-scheme/ > > understands and request credentials from the user based upon that > challenge. > > Note that many browsers will only recognize Basic and will require > that it be the first auth-scheme presented. Servers should only > > s/should/SHOULD/ > > include Basic if it is minimally acceptable. > > When the server offers choices of authentication schemes using the > WWW-Authenticate header field, the strength of the resulting > authentication is only as good as that of the of the weakest of the > authentication schemes. See section 5.7 below for discussion of > particular attack scenarios that exploit multiple authentication > schemes. > > > > 5.8 Man in the Middle > > Both Basic and Digest authentication are vulnerable to "man in the > middle" (MITM) attacks, for example, from a hostile or compromised > proxy. Clearly, this would present all the problems of eavesdropping. > But it also offers some additional opportunities to the attacker. > > The Digest spec shouldn't talk about "Basic". And it seems that there's a > security consideration I dropped from 2617 and which I need to include into > the Basic spec. > > Yep; I will remove that. > 5.12 Spoofing by Counterfeit Servers > > Basic Authentication is vulnerable to spoofing by counterfeit > servers. If a user can be led to believe that she is connecting to a > > ...this section doesn't belong here. > > Agree. I will remove it. > > 6.2 Digest Scheme Registration > > This specification registers the Digest scheme with the > Authentication Scheme Registry. > > Authentication Scheme Name: Digest > > Pointer to specification text: RFCXXX > > s/RFCXXXX/this specification/ > > > > 7 Acknowledgments > > The authors of this document would like to thank the authors of > RFC2617, as this document heavily borrows text from their document to > provide a complete description of the digest scheme and its > operations. > > s/RFC2617/RFC 2617/ > > > 8 References > > 8.1 Normative References > > [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol > (LDAP): Authentication Methods and Security Mechanisms", > RFC 4513, June 2006. > > doesn't seem to be normative. > > > [BASIC] Reschke, J., "The 'Basic' HTTP Authentication Scheme", > draft-ietf-httpauth-basicauth-update (Work in Progress), > September 2013. > > Needs update. Also shouldn't be normative. > > > Best regards, Julian > --001a11348fd68a0f6e050aa78a56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Julian,

Thanks you very much for thi= s detailed review.
Please, see my reply inline...

<= /div>
Regards,
=A0Rifaat


On Sun, Dec 14, 2014 at 11:25 AM,= Julian Reschke <julian.reschke@greenbytes.de> wr= ote:
Hi there,

it's the first time I read this in a long time; apologies for the lack = of structure; and also that most of these should have been made during WGLC= .



Abstract

=A0 =A0HTTP provides a simple challenge-response authentication mechanism =A0 =A0that may be used by a server to challenge a client request and by a<= br> =A0 =A0client to provide authentication information. This document defines<= br> =A0 =A0the HTTP Digest Authentication scheme that may be used with the
=A0 =A0authentication mechanism.

 s/may/can/

Also maybe: ...that can used with the *HTTP* authentication mechanism.

1 Introduction

=A0 =A0HTTP provides a simple challenge-response authentication mechanism =A0 =A0that may be used by a server to challenge a client request and by a<= br> =A0 =A0client to provide authentication information. This document defines<= br> =A0 =A0the HTTP Digest Authentication scheme that may be used with the
=A0 =A0authentication mechanism.

 (see above)

=A0 =A0The details of the challenge-response authentication mechanism are =A0 =A0specified in the [RFC7235] document.

...in "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [R= FC7235].

=A0 =A0The combination of this document with Basic [BASIC] and [RFC7235] =A0 =A0obsolete RFC2617.

s/Basic/the definition of the "Basic" authentication scheme/
s/RFC2617/RFC 2617/

2.2 Algorithm Variants

=A0 =A0When used with the Digest mechanism, each one of the algorithms has<= br> =A0 =A0two variants: Session variant and non-Session variant.

=A0 =A0The non-Session variant is denoted by "<algorithm>",= e.g. "SHA-256",
=A0 =A0and the Session variant is denoted by "<algorithm>-sess&q= uot;, e.g. "SHA-
=A0 =A0256-sess".

This comes very early; maybe it would be better mentioned later on.


Yeah; I moved it to section 3.3 under = the algorithm parameter.


=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> 2.3 ABNF

=A0 =A0This specification uses the Augmented Backus-Naur Form (ABNF)
=A0 =A0notation of [RFC5234].

Actually, you'll also need <http://greenbytes.de/tec= h/webdav/rfc7230.html#abnf.extension> (see below later= ).


=A0 =A0realm
=A0 =A0 =A0 A string to be displayed to users so they know which username a= nd
=A0 =A0 =A0 password to use. This string should contain at least the name o= f
=A0 =A0 =A0 the host performing the authentication and might additionally =A0 =A0 =A0 indicate the collection of users who might have access. An exam= ple
=A0 =A0 =A0 might be "registered_users@gotham.news.com". (S= ee section 2.2 of
=A0 =A0 =A0 [RFC7235] for more details).

s/section/Section/

For the host name part, see <https://tools.ietf.org/html/rfc2606>.<= br>
=A0 =A0domain
=A0 =A0 =A0 A quoted, space-separated list of URIs, as specified in RFC 398= 6
=A0 =A0 =A0 [RFC3986], that define the protection space. If a URI is an
=A0 =A0 =A0 abs_path, it is relative to the canonical root URL of the web-<= br> =A0 =A0 =A0 origin. An absolute-URI in this list may refer to a different =A0 =A0 =A0 server than the web-origin. The client can use this list to
=A0 =A0 =A0 determine the set of URIs for which the same authentication
=A0 =A0 =A0 information may be sent: any URI that has a URI in this list as= a

s/may/can/ or MAY

=A0 =A0 =A0 prefix (after both have been made absolute) may be assumed to b= e
=A0 =A0 =A0 in the same protection space. If this parameter is omitted or i= ts
=A0 =A0 =A0 value is empty, the client SHOULD assume that the protection sp= ace
=A0 =A0 =A0 consists of all URIs on the web-origin. All URIs in this list =A0 =A0 =A0 SHOULD use the same scheme (https or http); mixing them is a ba= d
=A0 =A0 =A0 idea.

web_origin and canonical root need definitions.


I will point to RFC6454 for web-origin= .
Is there a document that defines canonical root?

=
=A0
Why is mixing them a "bad idea"? - maybe this could be explained = better.


This text was copied from RFC2617; I a= m not sure why they considered mixing http and https URIs a "bad idea&= quot;.
Anybody knows the reason behind this statement?
=
=A0
=A0 =A0 =A0 This parameter is not meaningful in Proxy-Authenticate header =A0 =A0 =A0 fields, for which the protection space is always the entire pro= xy;
=A0 =A0 =A0 if present it should be ignored.

MUST? SHOULD?


I will change it to MUST
=A0
=A0 =A0nonce
=A0 =A0 =A0 A server-specified data string which should be uniquely generat= ed
=A0 =A0 =A0 each time a 401 response is made. It is recommended that this
RECOMMENDED?

Would there be a problem if it is a differen format? If no, why a normative= requirement here?


It probably can be a different format;= that is probably the reason the text is not normative and using recommende= d, instead of RECOMMENDED.


=A0
=A0 =A0 =A0 string be base64 or hexadecimal data. Specifically, since the =A0 =A0 =A0 string is passed in the header field lines as a quoted string, = the
=A0 =A0 =A0 double-quote character is not allowed.

well, unless suitably escaped.

=A0 =A0 =A0 The contents of the nonce are implementation dependent. The

s/are/is/?

=A0 =A0 =A0 quality of the implementation depends on a good choice. A nonce=
=A0 =A0 =A0 might, for example, be constructed as the base 64 encoding of
=A0 =A0 =A0 =A0 =A0 =A0 time-stamp H(time-stamp ":" ETag ":&= quot; secret-data)

=A0 =A0 =A0 where time-stamp is a server-generated time, which preferably
s/value/values/

=A0 =A0 =A0 includes micro or nano seconds, or other non-repeating value, E= Tag
=A0 =A0 =A0 is the value of the HTTP ETag header field associated with the<= br> =A0 =A0 =A0 requested entity, and secret-data is data known only to the
=A0 =A0 =A0 server. With a nonce of this form a server would recalculate th= e
=A0 =A0 =A0 hash portion after receiving the client authentication header =A0 =A0 =A0 field and reject the request if it did not match the nonce from=
=A0 =A0 =A0 that header field or if the time-stamp value is not recent enou= gh.
=A0 =A0 =A0 In this way the server can limit the time of the nonce's va= lidity.
=A0 =A0 =A0 The inclusion of the ETag prevents a replay request for an upda= ted
=A0 =A0 =A0 version of the resource. Including the IP address of the client= in
=A0 =A0 =A0 the nonce would appear to offer the server the ability to limit=
=A0 =A0 =A0 the reuse of the nonce to the same client that originally got i= t.
=A0 =A0 =A0 However, that would break proxy farms, where requests from a =A0 =A0 =A0 single user often go through different proxies in the farm. Als= o,
=A0 =A0 =A0 IP address spoofing is not that hard.

Do you need a proxy *farm* for this problem?


I think that this is just one example.= Are you suggesting that we remove that text?

=A0<= /div>
=A0 =A0 =A0 An implementation might choose not to accept a previously used<= br> =A0 =A0 =A0 nonce or a previously used digest, in order to protect against = a
=A0 =A0 =A0 replay attack. Or, an implementation might choose to use one-ti= me
=A0 =A0 =A0 nonces or digests for POST or PUT requests and a time-stamp for=
=A0 =A0 =A0 GET requests. For more details on the issues involved see secti= on
=A0 =A0 =A0 5 of this document.

s/section/Section/

...why are these lowercase; aren't they generated by xml2rfc? If not, t= hey should, because otherwise they break too easily.


I use nroff.

= =A0
=A0 =A0 =A0 The nonce is opaque to the client.

=A0 =A0opaque
=A0 =A0 =A0 A string of data, specified by the server, which SHOULD be
=A0 =A0 =A0 returned by the client unchanged in the Authorization header fi= eld
=A0 =A0 =A0 of subsequent requests with URIs in the same protection space. = It
=A0 =A0 =A0 is recommended that this string be base64 or hexadecimal data.<= br>
(see above)


Changed RECOMMENED to recommended.

=A0
=A0 =A0stale
=A0 =A0 =A0 A case-insensitive flag indicating that the previous request fr= om
=A0 =A0 =A0 the client was rejected because the nonce value was stale. If =A0 =A0 =A0 stale is TRUE, the client MAY wish to simply retry the request<= br>
"MAY wish" doesn't seem like a case for a BCP14 keyword.

=A0 =A0 =A0 with a new encrypted response, without re-prompting the user fo= r a
=A0 =A0 =A0 new username and password. The server SHOULD only set stale to<= br> =A0 =A0 =A0 TRUE if it receives a request for which the nonce is invalid. I= f
=A0 =A0 =A0 stale is FALSE, or anything other than TRUE, or the stale
=A0 =A0 =A0 parameter is not present, the username and/or password are
=A0 =A0 =A0 invalid, and new values MUST be obtained.

=A0 =A0algorithm
=A0 =A0 =A0 A string indicating a pair of algorithms used to produce the =A0 =A0 =A0 digest and a checksum. If this is not present it is assumed to = be
=A0 =A0 =A0 "MD5". If the algorithm is not understood, the challe= nge should be
=A0 =A0 =A0 ignored (and a different one used, if there is more than one).<= br>
Avoid lowercase BCP14 keywords. Either uppercase or choose something else (= here and later on).


=A0 =A0userhash
=A0 =A0 =A0 This is an OPTIONAL parameter that is used by the server to
=A0 =A0 =A0 indicate that it supports username hashing. Valid values are: =A0 =A0 =A0 "true" or "false".

Defaults to false, I assume.

Yes

=A0

3.4 The Authorization Request Header

s/header/header field/

=A0 =A0 =A0 The client is expected to retry the request, passing an
=A0 =A0 =A0 Authorization header field line with Digest scheme, which is =A0 =A0 =A0 defined according to the framework above. The values of the opa= que
=A0 =A0 =A0 and algorithm fields must be those supplied in the WWW-
=A0 =A0 =A0 Authenticate response header field for the entity being request= ed.

=A0 =A0 =A0 The request includes some or all of the following parameters:
"some or all" reads weird...

=A0 =A0uri
=A0 =A0 =A0 The URI from request-target of the Request-Line; duplicated her= e
=A0 =A0 =A0 because proxies are allowed to change the Request-Line in trans= it.

The request-target of the Request-Line isn't necessarily a URI...


What do you suggest I do instead?


=A0
=A0 =A0qop
=A0 =A0 =A0 Indicates what "quality of protection" the client has= applied to
=A0 =A0 =A0 the message. Its value MUST be one of the alternatives the serv= er
=A0 =A0 =A0 indicated it supports in the WWW-Authenticate header field. The= se
=A0 =A0 =A0 values affect the computation of the response. Note that this i= s a
=A0 =A0 =A0 single token, not a quoted list of alternatives as in WWW-
=A0 =A0 =A0 Authenticate.

Can it use quoted-string nevertheless?

=A0 =A0nc
=A0 =A0 =A0 This parameter MUST be used by all implementations compliant wi= th
=A0 =A0 =A0 this version of the Digest scheme. The "nc" parameter= stands for

I wonder why we need to say "compliant with this version"?


I will reomve it

<= div>=A0
=A0 =A0userhash
=A0 =A0 =A0 This OPTIONAL parameter is used by the client to indicate that = the
=A0 =A0 =A0 username has been hashed. Valid values are: "true" or= "false".

Default?

=A0 =A0If a parameter or its value is improper, or required parameters are<= br> =A0 =A0missing, the proper response is 400 Bad Request. If the request-

Is this a requirement?
I think so.=A0
=A0
Could it be a more specifc 4xx code?
<= div>What would be the benefit of changing this now?

=A0
=A0 =A0digest is invalid, then a login failure should be logged, since
=A0 =A0repeated login failures from a single client may indicate an attacke= r
=A0 =A0attempting to guess passwords. The server implementation should be
SHOULD?

=A0 =A0careful with the information being logged so that it won't put a=
=A0 =A0cleartext password (e.g. entered into the username field) into the =A0 =A0log.

=A0 =A0The definition of response above indicates the encoding for its

s/of/of the/

=A0 =A0value. The following definitions show how the value is computed.



=A0 =A0This creates a 'session key' for the authentication of subse= quent

double quotes?

=A0 =A0requests and responses which is different for each "authenticat= ion
=A0 =A0session", thus limiting the amount of material hashed with any = one
=A0 =A0key. (Note: see further discussion of the authentication session in<= br> =A0 =A0section 3.6.) Because the server need only use the hash of the user<= br>
s/need/needs/

=A0 =A0credentials in order to create the A1 value, this construction could=
=A0 =A0be used in conjunction with a third party authentication service so<= br> =A0 =A0that the web server would not need the actual password value. The =A0 =A0specification of such a protocol is beyond the scope of this
=A0 =A0specification.

=A0 =A0Also note that if integrity protection is applied (qop=3Dauth-int), = the
=A0 =A0H(entity-body) is the hash of the entity body, not the message body = -
=A0 =A0it is computed before any transfer encoding is applied by the sender=
=A0 =A0and after it has been removed by the recipient. Note that this
=A0 =A0includes multipart boundaries and embedded header fields in each par= t
=A0 =A0of any multipart content-type.

(reduce amout of "note that"...)

3.4.6 Various Considerations

=A0 =A0The "Method" value is the HTTP request method, in all-uppe= rcase US-
=A0 =A0ASCII letters, as specified in section 3.1.1 of [RFC7230]. The

Hm, no. The registered methods happen to be all-uppercase, but method names= are case-sensitive.

ok

=A0
=A0 =A0Implementers should be aware of how authenticated transactions

...need to be...

=A0 =A0interact with shared caches. The HTTP/1.1 protocol specifies that
s/The HTTP/1.1 protocol/HTTP/

=A0 =A0when a shared cache (see [RFC7234]) has received a request containin= g
=A0 =A0an Authorization header field and a response from relaying that
=A0 =A0request, it MUST NOT return that response as a reply to any other =A0 =A0request, unless one of two Cache-Control (see section 3.2 of
=A0 =A0[RFC7234]) directive was present in the response. If the original =A0 =A0response included the "must-revalidate" Cache-Control dire= ctive, the
=A0 =A0cache MAY use the entity of that response in replying to a subsequen= t
=A0 =A0request, but MUST first revalidate it with the origin server, using<= br> =A0 =A0the request header fields from the new request to allow the origin =A0 =A0server to authenticate the new request. Alternatively, if the
=A0 =A0original response included the "public" Cache-Control dire= ctive, the
=A0 =A0response entity MAY be returned in reply to any subsequent request.<= br>
Do we need to replicate this information here? (Asking because the Basic sp= ec does not)


I do not mind removing it, if it is ex= plained somewhere else. I can just point to it here.

=A0
3.5 The Authentication-Info Header

=A0 =A0The Authentication-Info header field is a generic field that MAY be<= br> =A0 =A0used by a server to communicate some information regarding the
=A0 =A0successful authentication of a client response. The following is the=
=A0 =A0syntax of the header:

=A0 =A0 =A0 =A0 =A0 =A0Authentication-Info =3D auth-info

=A0 =A0 =A0 =A0 =A0 =A0auth-info =3D *auth-param

This needs to be "#auth-param" and invoke the list ABNF extension= from RFC 7230.

=A0 =A0The auth-param is defined in [RFC7235].

ok

=A0
(I still believe we should extract this into a separate spec)

3.5.1 Digest Usage of Authentication-Info

=A0 =A0The Digest authentication scheme MAY add the Authentication-Info
=A0 =A0header field in the confirmation request with some or all of the
=A0 =A0following parameters:

"Some or all" reads weird.


3.6 Digest Operation

=A0 =A0Upon receiving the Authorization header field, the server MAY check<= br> =A0 =A0its validity by looking up the password that corresponds to the
=A0 =A0submitted username. Then, the server MUST perform the same digest =A0 =A0operation (e.g. MD5, SHA-256) performed by the client, and compare =A0 =A0the result to the given response value.

=A0 =A0Note that the HTTP server does not actually need to know the user= 9;s
=A0 =A0cleartext password. As long as H(A1) is available to the server, the=
=A0 =A0validity of an Authorization header field MAY be verified.

s/MAY/can/

=A0 =A0Because the client is required to return the value of the opaque

s/required/REQUIRED/

=A0 =A0parameter given to it by the server for the duration of a session, =A0 =A0the opaque data MAY be used to transport authentication session stat= e

s/MAY/can/

=A0 =A0information. (Note that any such use can also be accomplished more =A0 =A0easily and safely by including the state in the nonce.) For example,=
=A0 =A0a server could be responsible for authenticating content that
=A0 =A0actually sits on another server. It would achieve this by having the=
=A0 =A0first 401 response include a domain parameter whose value includes a=
=A0 =A0URI on the second server, and an opaque parameter whose value
=A0 =A0contains the state information. The client will retry the request, a= t
=A0 =A0which time the server might respond with a 301/302 redirection,

Do not exclude 307/308. Just say "HTTP Redirection (Section 6.4 of [RF= C7231])"

ok
=A0
=A0 =A0As with the basic scheme, proxies MUST be completely transparent in<= br>
s/basic/"Basic"/

Is it wise to cite that hear?

I will remove it.

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> =A0 =A0the Digest access authentication scheme. That is, they MUST forward<= br> =A0 =A0the WWW-Authenticate, Authentication-Info and Authorization header =A0 =A0fields untouched. If a proxy wants to authenticate a client before a=
=A0 =A0request is forwarded to the server, it can be done using the Proxy-<= br> =A0 =A0Authenticate and Proxy-Authorization header fields described in
=A0 =A0section 3.8 below.


3.7 Security Protocol Negotiation

=A0 =A0It is useful for a server to be able to know which security schemes = a
=A0 =A0client is capable of handling.

=A0 =A0It is possible that a server MAY want to require Digest as its

s/MAY want/wants/

=A0 =A0authentication method, even if the server does not know that the
=A0 =A0client supports it. A client is encouraged to fail gracefully if the=
=A0 =A0server specifies only authentication schemes it cannot handle.

=A0 =A0When a server receives a request to access a resource, the server =A0 =A0might challenge the client by responding with "401 Unauthorized= "
=A0 =A0status code, and include one or more WWW-Authenticate header fields.=

s/status code/response/

=A0 =A0If the server challenges with multiple Digest header fields, then =A0 =A0each one of these header fields MUST use a different digest

You could have multiple challenges in a single header field instance.

Can you please elaborate?

= =A0
=A0 =A0algorithm. The server MUST add these Digest header fields to the
=A0 =A0response in order of preference, starting with the most preferred =A0 =A0header field, followed by the less preferred header fields.

most preferred algorithm?

=A0 =A0When the client receives the response it SHOULD use the topmost
=A0 =A0header field that it supports, unless a local policy dictates

First challenge.

=A0 =A0otherwise. The client SHOULD ignore any challenge it does not
=A0 =A0understand.

MUST, I believe.

Yes
=A0
Also, this sounds like requirements that are generic to WWW-A, not specific= to Digest, no?

Yes. it is. Is it specified somewhere else?
=A0

3.8 Proxy-Authenticate and Proxy-Authorization

=A0 =A0The digest authentication scheme MAY also be used for authenticating=

s/MAY/can/

=A0 =A0users to proxies, proxies to proxies, or proxies to origin servers b= y
=A0 =A0use of the Proxy-Authenticate and Proxy-Authorization header fields.=
=A0 =A0These header fields are instances of the Proxy-Authenticate and
=A0 =A0Proxy- Authorization header fields specified in sections 4.2 and 4.3=

s/Proxy- Authorization/Proxy-Authorization/

=A0 =A0of the HTTP/1.1 specification [RFC7235] and their behavior is subjec= t
=A0 =A0to restrictions described there. The transactions for proxy
=A0 =A0authentication are very similar to those already described. Upon
=A0 =A0receiving a request which requires authentication, the proxy/server<= br> =A0 =A0MUST issue the "407 Proxy Authentication Required" respons= e with a
=A0 =A0"Proxy-Authenticate" header field. The digest-challenge us= ed in the
=A0 =A0Proxy-Authenticate header field is the same as that for the WWW-
=A0 =A0Authenticate header field as defined above in section 3.2.1.

I don't see a Section 3.2.1.

It should be 3.3.

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
3.9 Examples

3.9.1 Example with SHA-256 and MD5


=A0 =A0The following example assumes that an access protected document is =A0 =A0being requested from the server via a GET request. The URI of the =A0 =A0document is http://www.nowhere.org/dir/index.html". Both cl= ient and
=A0 =A0server know that the username for this document is "Mufasa"= ; and the
=A0 =A0password is "Circle of Life" ( with one space between each= of the
=A0 =A0three words).

Need to use RFC 2606 hostnames.

ok

=A0
=A0 =A0The first time the client requests the document, no Authorization =A0 =A0header field is sent, so the server responds with:

=A0 =A0 =A0 =A0 HTTP/1.1 401 Unauthorized
=A0 =A0 =A0 =A0 WWW-Authenticate: Digest
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 realm=3D"http-auth@example.org",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 qop=3D"auth, auth-int",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithm=3D"SHA-256",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nonce=3D"7ypf/xlj9XXwfDPEoM4URr= v/xwf94BcCAzFZH4GiTo0v",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 opaque=3D"FQhe/qaU925kfnzjCev0c= iny7QMkPqMAFRtzCUYo5tdS"
=A0 =A0 =A0 =A0 WWW-Authenticate: Digest
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 realm=3D"http-auth@example.org",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 qop=3D"auth, auth-int",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithm=3D"MD5",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nonce=3D"7ypf/xlj9XXwfDPEoM4URr= v/xwf94BcCAzFZH4GiTo0v",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 opaque=3D"FQhe/qaU925kfnzjCev0c= iny7QMkPqMAFRtzCUYo5tdS"

=A0 =A0The client MAY prompt the user for their username and password, afte= r

s/MAY/can/ or /will/

Maybe also point out that you could also send...:

=A0 =A0 =A0 =A0 WWW-Authenticate: Digest realm=3D"http-auth@example.org",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 qop=3D"auth, auth-int",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithm=3D"SHA-256",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nonce=3D"7ypf/xlj9XXwfDPEoM4URr= v/xwf94BcCAzFZH4GiTo0v",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 opaque=3D"FQhe/qaU925kfnzjCev0c= iny7QMkPqMAFRtzCUYo5tdS",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Digest realm=3D"http-auth@example.org",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 qop=3D"auth, auth-int",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithm=3D"MD5",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nonce=3D"7ypf/xlj9XXwfDPEoM4URr= v/xwf94BcCAzFZH4GiTo0v",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 opaque=3D"FQhe/qaU925kfnzjCev0c= iny7QMkPqMAFRtzCUYo5tdS"

Later:


=A0 =A0 =A0 =A0 Authorization:Digest username=3D"Mufasa",

insert an SP after the colon.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 realm=3D"http-auth@example.org",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uri=3D"/dir/index.html",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithm=3DMD5,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nonce=3D"7ypf/xlj9XXwfDPEoM4URr= v/xwf94BcCAzFZH4GiTo0v",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nc=3D00000001,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cnonce=3D"f2/wE4q74E6zIJEtWaHKa= f5wv/H5QzzpXusqGemxURZJ",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 qop=3Dauth,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 response=3D"8ca523f5e9506fed465= 7c9700eebdbec",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 opaque=3D"FQhe/qaU925kfnzjCev0c= iny7QMkPqMAFRtzCUYo5tdS"


=A0 =A0If the client chooses to use the SHA-256 algorithm for calculating =A0 =A0the response, the client responds with a new request including the =A0 =A0following Authorization header field:


=A0 =A0 =A0 =A0 Authorization:Digest username=3D"Mufasa",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 realm=3D"http-auth@example.org",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uri=3D"/dir/index.html",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithm=3DSHA-256,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nonce=3D"7ypf/xlj9XXwfDPEoM4URr= v/xwf94BcCAzFZH4GiTo0v",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nc=3D00000001,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cnonce=3D"f2/wE4q74E6zIJEtWaHKa= f5wv/H5QzzpXusqGemxURZJ",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 qop=3Dauth,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 response=3D"753927fa0e85d155564= e2e272a28d1802ca10daf449
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A06794697cf8db5856cb6c1",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 opaque=3D"FQhe/qaU925kfnzjCev0c= iny7QMkPqMAFRtzCUYo5tdS"

3.9.2 Example with SHA-512-256, Charset, and Userhash

=A0 =A0The following example assumes that an access protected document is =A0 =A0being requested from the server via a GET request. The URI for the =A0 =A0request is "http://api.example.org/doe.json". Both client a= nd server
=A0 =A0know the userhash of the username, support the UTF-8 charset, and us= e

s/UTF-8 charset/UTF-8 character encoding scheme/

=A0 =A0the SHA-512-256 algorithm. The username for the request is "Jas= on
=A0 =A0Doe" and the password is "Secret, or not?".

 It would be good to have non-ASCII characters in the example.

=A0 =A0The first time the client requests the document, no Authorization =A0 =A0header field is sent, so the server responds with:


=A0 =A0 =A0 =A0 HTTP/2.0 401 Unauthorized

HTTP/2.0????
=A0
Should be 1.1.

=A0 =A0 =A0 =A0 WWW-Authenticate: Digest
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 realm=3D"api@example.org",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 qop=3Dauth,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithm=3DSHA-512-256,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nonce=3D"5TsQWLVdgBdmrQ0XsxbDOD= V+57QdFR34I9HAbC/RVvkK",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 opaque=3D"HRPCssKJSGjCrkzDg8Ohw= pzCiGPChXYjwrI2QmXDnsOS",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 charset=3DUTF-8,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 userhash=3Dtrue


=A0 =A0The client MAY prompt the user for the required credentials and send=
=A0 =A0a new request with following Authorization header field:

=A0 =A0 =A0 =A0 Authorization: Digest
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 username=3D"488869477bf257147b8= 04c45308cd62ac4e25eb717
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b12b298c79e62dcea254ec",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 realm=3D"api@example.org",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uri=3D"/doe.json",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithm=3DSHA-512-256,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nonce=3D"5TsQWLVdgBdmrQ0XsxbDOD= V+57QdFR34I9HAbC/RVvkK",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nc=3D00000001,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cnonce=3D"NTg6RKcb9boFIAS3KrFK9= BGeh+iDa/sm6jUMp2wds69v",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 qop=3Dauth,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 response=3D"ae66e67d6b427bd3f12= 0414a82e4acff38e8ecd9101d
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A06c861229025f607a79dd",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 opaque=3D"HRPCssKJSGjCrkzDg8Ohw= pzCiGPChXYjwrI2QmXDnsOS",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 userhash=3Dtrue

=A0 =A0If the client can not provide a hashed username for any reason, the<= br> =A0 =A0client MAY try a request with this Authorization header field:

=A0 =A0 =A0 =A0 Authorization: Digest
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 username*=3DUTF-8''J%C3%A4s%C3%<= /u>B8n%20Doe,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 realm=3D"api@example.org",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 uri=3D"/doe.json",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithm=3DSHA-512-256,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nonce=3D"5TsQWLVdgBdmrQ0XsxbDOD= V+57QdFR34I9HAbC/RVvkK",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nc=3D00000001,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cnonce=3D"NTg6RKcb9boFIAS3KrFK9= BGeh+iDa/sm6jUMp2wds69v",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 qop=3Dauth,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 response=3D"ae66e67d6b427bd3f12= 0414a82e4acff38e8ecd9101d6
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0c861229025f607a79dd",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 opaque=3D"HRPCssKJSGjCrkzDg8Ohw= pzCiGPChXYjwrI2QmXDnsOS",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 userhash=3Dfalse

Wait, you can't do that. You'll need to formally state that some or= all of your auth-params can be sent using the RFC 5987 encoding (and upfro= nt, not in the example here).

ok
<= div>=A0
=A0 =A0For the username, recipients MUST support all characters defined in<= br> =A0 =A0the "UsernameCasePreserved" profile defined in in Section = 3.3 of
=A0 =A0[PRECIS], with the exception of the colon (":") character.=

This is copied from Basic.
Yes, I mentioned that I will u= se the same text you provided with Digest.
=A0
Is it true for Digest as well?
=A0
I tho= ught that was the conclusion based on the following:=A0


=A0
=A0 =A0If the user agent does not support the encoding indicated by the
=A0 =A0server, it MUST fail the request.

That sounds like a deployment problem. Also it reads weird given the fact t= hat only one value ("UTF-8") is allowed.

Any suggestion on how to reword that?

<= /div>
=A0

5.6 Weakness Created by Multiple Authentication Schemes

=A0 =A0An HTTP/1.1 server MAY return multiple challenges with a 401
=A0 =A0(Authenticate) response, and each challenge MAY use a different auth= -
=A0 =A0scheme. A user agent MUST choose to use the strongest auth- scheme i= t

s/auth- scheme/auth-scheme/

=A0 =A0understands and request credentials from the user based upon that =A0 =A0challenge.

=A0 =A0 =A0 Note that many browsers will only recognize Basic and will requ= ire
=A0 =A0 =A0 that it be the first auth-scheme presented. Servers should only=

s/should/SHOULD/

=A0 =A0 =A0 include Basic if it is minimally acceptable.

=A0 =A0When the server offers choices of authentication schemes using the =A0 =A0WWW-Authenticate header field, the strength of the resulting
=A0 =A0authentication is only as good as that of the of the weakest of the<= br> =A0 =A0authentication schemes. See section 5.7 below for discussion of
=A0 =A0particular attack scenarios that exploit multiple authentication
=A0 =A0schemes.



5.8 Man in the Middle

=A0 =A0Both Basic and Digest authentication are vulnerable to "man in = the
=A0 =A0middle" (MITM) attacks, for example, from a hostile or compromi= sed
=A0 =A0proxy. Clearly, this would present all the problems of eavesdropping= .
=A0 =A0But it also offers some additional opportunities to the attacker.
The Digest spec shouldn't talk about "Basic". And it seems th= at there's a security consideration I dropped from 2617 and which I nee= d to include into the Basic spec.

Yep; I will remove that.

=A0=
5.12 Spoofing by Counterfeit Servers

=A0 =A0Basic Authentication is vulnerable to spoofing by counterfeit
=A0 =A0servers. If a user can be led to believe that she is connecting to a=

...this section doesn't belong here.


Agree. I will remove it.
=A0

6.2=A0 Digest Scheme Registration

=A0 =A0This specification registers the Digest scheme with the
=A0 =A0Authentication Scheme Registry.

=A0 =A0 =A0 Authentication Scheme Name: Digest

=A0 =A0 =A0 Pointer to specification text: RFCXXX

s/RFCXXXX/this specification/



7 Acknowledgments

=A0 =A0The authors of this document would like to thank the authors of
=A0 =A0RFC2617, as this document heavily borrows text from their document t= o
=A0 =A0provide a complete description of the digest scheme and its
=A0 =A0operations.

s/RFC2617/RFC 2617/


8 References

8.1 Normative References

=A0 =A0[RFC4513]=A0 Harrison, R., Ed., "Lightweight Directory Access P= rotocol
=A0 =A0 =A0 =A0 =A0 =A0 =A0 (LDAP): Authentication Methods and Security Mec= hanisms",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 RFC 4513, June 2006.

doesn't seem to be normative.


=A0 =A0[BASIC]=A0 =A0 Reschke, J., "The 'Basic' HTTP Authentic= ation Scheme",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-ietf-httpauth-basicauth-update (Wo= rk in Progress),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 September 2013.

Needs update. Also shouldn't be normative.


Best regards, Julian

--001a11348fd68a0f6e050aa78a56-- From nobody Sat Dec 20 07:42:41 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92B31A8947 for ; Sat, 20 Dec 2014 07:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bzPdOGM80iU for ; Sat, 20 Dec 2014 07:42:36 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415EC1A88C2 for ; Sat, 20 Dec 2014 07:42:36 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id u10so2204711lbd.34 for ; Sat, 20 Dec 2014 07:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iQb0mqVaG67pSOBQMXS/Ec8upZs912+Ael/oLFz8aPo=; b=SFEDgNj1F0FHNH+lCOv8ey7bJCiPzbIfieVxxICTz6+8K0TptNLVNo21yE7tfVgHxK 6URSOyZSbFVebbZpmaRvVxrMUuyngBtssUg4+nWbYtcUR/rQHu910dWX9SeeDAr0So5g QBM26/ENq3nfGfcQdSSnxEUHw1S9SbigHTnehGuvW1As0lX5zF2UySzoFP+blNaXHp5J NJVAsgeWmty0M5pVyfoF9YN5I9auGNUjQXzPQC1neev4OaoHfpd2K+q4ub7TtU5eJzY0 YasSmmYIvuq/VnUiQ0EPGh6Pvn1NBS1y4Wj6dQhVbK1WfpAy/WYb7h+HXeaVIUeugKE6 rFzw== MIME-Version: 1.0 X-Received: by 10.112.171.136 with SMTP id au8mr13293757lbc.71.1419090154613; Sat, 20 Dec 2014 07:42:34 -0800 (PST) Received: by 10.114.27.162 with HTTP; Sat, 20 Dec 2014 07:42:34 -0800 (PST) In-Reply-To: References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA2D.2010808@gmx.de> Date: Sat, 20 Dec 2014 10:42:34 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Brett Tate Content-Type: multipart/alternative; boundary=001a11c377a491f0c3050aa7ac75 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/88Gd866p9ugWsxPxwf25Cy40WAI Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 15:42:40 -0000 --001a11c377a491f0c3050aa7ac75 Content-Type: text/plain; charset=ISO-8859-1 Hi Brett, Thanks for your review and comments. Please, see my reply inline... Regards, Rifaat On Mon, Dec 15, 2014 at 8:56 AM, Brett Tate wrote: > Hi, > > Concerning the quoted-string ambiguity, I agree that the ambiguity still > exists. > > Draft-ietf-httpauth-digest-09 did not address my quoted string general > comment. > > http://www.ietf.org/mail-archive/web/http-auth/current/msg01949.html > > Was it not addressed because of working group discussion at IETF 91? If > so, I have the same comment. The draft is not clear concerning when > quoted strings MUST/SHOULD/MAY be used. For historical reasons, the > resolution from a sender perspective should be backward compatible with > RFC 2617 which used ABNF to clearly indicate the mandate. > > Yes, it was discussed. Here is a quote from the minutes: -- Quoted Strings Issue: Julian: I think the slide is probably correctly. However, do we know for sure if this is required for historical reasons? Better not to put edge cases into the spec if we don't need them Additional comments inline. > > > > qop > > Indicates what "quality of protection" the client has applied to > > the message. Its value MUST be one of the alternatives the server > > indicated it supports in the WWW-Authenticate header field. These > > values affect the computation of the response. Note that this is > a > > single token, not a quoted list of alternatives as in WWW- > > Authenticate. > > > > Can it use quoted-string nevertheless? > > Not if the draft/device wants to remain backward compatible with RFC 2617. > > Agree > > > nc > > This parameter MUST be used by all implementations compliant with > > this version of the Digest scheme. The "nc" parameter stands for > > > > I wonder why we need to say "compliant with this version"? > > I also think that the sentence should be reworded. A compliant > implementation does not need to include the nc when interoperating with a > device which did not include a qop parameter. > > I will remove that. > > > of the HTTP/1.1 specification [RFC7235] and their behavior is > subject > > to restrictions described there. The transactions for proxy > > authentication are very similar to those already described. Upon > > receiving a request which requires authentication, the proxy/server > > MUST issue the "407 Proxy Authentication Required" response with a > > "Proxy-Authenticate" header field. The digest-challenge used in the > > Proxy-Authenticate header field is the same as that for the WWW- > > Authenticate header field as defined above in section 3.2.1. > > > > I don't see a Section 3.2.1. > > It and the use of "digest-challenge" are cut/paste errors from RFC 2617. > The sentence should be updated the reflect the draft. > > > > 3.9 Examples > > > > 3.9.1 Example with SHA-256 and MD5 > > > > Maybe also point out that you could also send...: > > > > WWW-Authenticate: Digest realm="http-auth@example.org", > > qop="auth, auth-int", > > algorithm="SHA-256", > > nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", > > opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS", > > Digest realm="http-auth@example.org", > > qop="auth, auth-int", > > algorithm="MD5", > > nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", > > opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" > > It is not allowed. > --001a11c377a491f0c3050aa7ac75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Brett,

Thanks for your review and co= mments.
Please, see my reply inline...

R= egards,
=A0Rifaat

=
On Mon, Dec 15, 2014 at 8:56 AM, Brett Tate = <brett@broadsoft.com> wrote:
Hi,

Concerning the quoted-string ambiguity, I agree that the ambiguity still exists.

Draft-ietf-httpauth-digest-09 did not address my quoted string general
comment.

http://www.ietf.org/mail-archive/web/http-auth/curr= ent/msg01949.html

Was it not addressed because of working group discussion at IETF 91?=A0 If<= br> so, I have the same comment.=A0 The draft is not clear concerning when
quoted strings MUST/SHOULD/MAY be used.=A0 For historical reasons, the
resolution from a sender perspective should be backward compatible with
RFC 2617 which used ABNF to clearly indicate the mandate.


Yes, it was discussed.
Here = is a quote from the minutes:

-- Quoted Strings Issu=
e:=20

   Julian: I think the slide is probably correctly. However, do we know for=
 sure if this is required for historical reasons?
           Better not to put edge cases into the spec if we don't need =
them
=A0


Additional comments inline.


>=A0 =A0 =A0qop
>=A0 =A0 =A0 =A0 Indicates what "quality of protection" the cl= ient has applied to
>=A0 =A0 =A0 =A0 the message. Its value MUST be one of the alternatives = the server
>=A0 =A0 =A0 =A0 indicated it supports in the WWW-Authenticate header fi= eld. These
>=A0 =A0 =A0 =A0 values affect the computation of the response. Note tha= t this is
a
>=A0 =A0 =A0 =A0 single token, not a quoted list of alternatives as in W= WW-
>=A0 =A0 =A0 =A0 Authenticate.
>
> Can it use quoted-string nevertheless?

Not if the draft/device wants to remain backward compatible with RFC= 2617.

Agree

=A0

>=A0 =A0 =A0nc
>=A0 =A0 =A0 =A0 This parameter MUST be used by all implementations comp= liant with
>=A0 =A0 =A0 =A0 this version of the Digest scheme. The "nc" p= arameter stands for
>
> I wonder why we need to say "compliant with this version"?
I also think that the sentence should be reworded.=A0 A compliant implementation does not need to include the nc when interoperating with a device which did not include a qop parameter.


I will remove = that.
=A0

>=A0 =A0 =A0of the HTTP/1.1 specification [RFC7235] and their behavior i= s
subject
>=A0 =A0 =A0to restrictions described there. The transactions for proxy<= br> >=A0 =A0 =A0authentication are very similar to those already described. = Upon
>=A0 =A0 =A0receiving a request which requires authentication, the proxy= /server
>=A0 =A0 =A0MUST issue the "407 Proxy Authentication Required"= response with a
>=A0 =A0 =A0"Proxy-Authenticate" header field. The digest-chal= lenge used in the
>=A0 =A0 =A0Proxy-Authenticate header field is the same as that for the = WWW-
>=A0 =A0 =A0Authenticate header field as defined above in section 3.2.1.=
>
> I don't see a Section 3.2.1.

It and the use of "digest-challenge" are cut/paste errors = from RFC 2617.
The sentence should be updated the reflect the draft.


> 3.9 Examples
>
> 3.9.1 Example with SHA-256 and MD5
>
> Maybe also point out that you could also send.= ..:
>
>=A0 =A0 =A0 =A0 =A0 WWW-Authenticate: Digest realm=3D"http-auth@example.org",
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 qop=3D"auth, auth-int", >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithm=3D"SHA-256", >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nonce=3D"7ypf/xlj9XXwfDPEoM4UR= rv/xwf94BcCAzFZH4GiTo0v",
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 opaque=3D"FQhe/qaU925kfnzjCev0= ciny7QMkPqMAFRtzCUYo5tdS",
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Digest realm=3D"http-auth@example.org",
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 qop=3D"auth, auth-int", >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithm=3D"MD5",
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nonce=3D"7ypf/xlj9XXwfDPEoM4UR= rv/xwf94BcCAzFZH4GiTo0v",
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 opaque=3D"FQhe/qaU925kfnzjCev0= ciny7QMkPqMAFRtzCUYo5tdS"

It is not allowed.

--001a11c377a491f0c3050aa7ac75-- From nobody Sat Dec 20 09:22:32 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6701A8775 for ; Sat, 20 Dec 2014 09:22:28 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8TC0gb9JMPe for ; Sat, 20 Dec 2014 09:22:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49F61A1B2C for ; Sat, 20 Dec 2014 09:22:25 -0800 (PST) Received: from [192.168.2.160] ([84.187.56.90]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lrek1-1XuJoA0Y9t-013L5h; Sat, 20 Dec 2014 18:22:23 +0100 Message-ID: <5495B04B.1000903@gmx.de> Date: Sat, 20 Dec 2014 18:22:19 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA0B.6080201@greenbytes.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:mXfUs1/3JzKY/fB2VjojfI07m8QNfpNOH8GWWAB0nrZc9tn7yJ9 saigW2Dqnf1HI1P2YbcJcoeZUQ/81tIpSoWdBRo2GymVteY5OrglsG4cTcpEcJiOSm9aVla 58YvIRSuDriL25vvvehKxXBNh10iI1okByVjltdAhNpGZn9eYsiSi2ri/L40jST/DVMkqij 9iuE0qv/UFqceXfkqK2Yw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/_YCj1tXs_WEXaiC-57Mxrn2ImzY Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 17:22:29 -0000 On 2014-12-20 16:33, Rifaat Shekh-Yusef wrote: > ... > prefix (after both have been made absolute) may be assumed to be > in the same protection space. If this parameter is omitted or its > value is empty, the client SHOULD assume that the protection > space > consists of all URIs on the web-origin. All URIs in this list > SHOULD use the same scheme (https or http); mixing them is a bad > idea. > > web_origin and canonical root need definitions. > > > I will point to RFC6454 for web-origin. > Is there a document that defines canonical root? has one; do you need this *and* web_origin? > nonce > A server-specified data string which should be uniquely generated > each time a 401 response is made. It is recommended that this > > RECOMMENDED? > > Would there be a problem if it is a differen format? If no, why a > normative requirement here? > > > It probably can be a different format; that is probably the reason the > text is not normative and using recommended, instead of RECOMMENDED. Please do not use lowercased BCP14 terms and assume that people will read them differently from the uppercased variants. > includes micro or nano seconds, or other non-repeating value, > ETag > is the value of the HTTP ETag header field associated with the > requested entity, and secret-data is data known only to the > server. With a nonce of this form a server would recalculate the > hash portion after receiving the client authentication header > field and reject the request if it did not match the nonce from > that header field or if the time-stamp value is not recent > enough. > In this way the server can limit the time of the nonce's > validity. > The inclusion of the ETag prevents a replay request for an > updated > version of the resource. Including the IP address of the > client in > the nonce would appear to offer the server the ability to limit > the reuse of the nonce to the same client that originally got it. > However, that would break proxy farms, where requests from a > single user often go through different proxies in the farm. Also, > IP address spoofing is not that hard. > > Do you need a proxy *farm* for this problem? > > > I think that this is just one example. Are you suggesting that we remove > that text? I'd just rephrase it to talk about proxies in general. > An implementation might choose not to accept a previously used > nonce or a previously used digest, in order to protect against a > replay attack. Or, an implementation might choose to use one-time > nonces or digests for POST or PUT requests and a time-stamp for > GET requests. For more details on the issues involved see section > 5 of this document. > > s/section/Section/ > > ...why are these lowercase; aren't they generated by xml2rfc? If > not, they should, because otherwise they break too easily. > > > I use nroff. I'd recommend to switch to xml2rfc; I can help with the conversion if you like. > The nonce is opaque to the client. > > opaque > A string of data, specified by the server, which SHOULD be > returned by the client unchanged in the Authorization header > field > of subsequent requests with URIs in the same protection space. It > is recommended that this string be base64 or hexadecimal data. > > (see above) > > > Changed RECOMMENED to recommended. Please no, see above. Just state that base64 or hex are good choices. > ... > 3.4 The Authorization Request Header > > s/header/header field/ > > The client is expected to retry the request, passing an > Authorization header field line with Digest scheme, which is > defined according to the framework above. The values of the > opaque > and algorithm fields must be those supplied in the WWW- > Authenticate response header field for the entity being > requested. > > The request includes some or all of the following parameters: > > "some or all" reads weird... > > uri > The URI from request-target of the Request-Line; duplicated here > because proxies are allowed to change the Request-Line in > transit. > > The request-target of the Request-Line isn't necessarily a URI... > > > What do you suggest I do instead? Dunno about what's used in practice. Either adjust the terminology to allow an absolute path, or otherwise use the term "effect request URI" from RFC 7230. > If a parameter or its value is improper, or required parameters are > missing, the proper response is 400 Bad Request. If the request- > > Is this a requirement? > > I think so. > > Could it be a more specifc 4xx code? > > What would be the benefit of changing this now? I don't know, but then clients that assume 400 instead of 4xx are broken anyway. I'd just state a "4xx" code. > 3.7 Security Protocol Negotiation > > It is useful for a server to be able to know which security > schemes a > client is capable of handling. > > It is possible that a server MAY want to require Digest as its > > s/MAY want/wants/ > > authentication method, even if the server does not know that the > client supports it. A client is encouraged to fail gracefully if the > server specifies only authentication schemes it cannot handle. > > When a server receives a request to access a resource, the server > might challenge the client by responding with "401 Unauthorized" > status code, and include one or more WWW-Authenticate header fields. > > s/status code/response/ > > If the server challenges with multiple Digest header fields, then > each one of these header fields MUST use a different digest > > You could have multiple challenges in a single header field instance. > > Can you please elaborate? The syntax allows it, so you should talk more generally about multiple challenges in a response, independently in how many header fields they appear. > algorithm. The server MUST add these Digest header fields to the > response in order of preference, starting with the most preferred > header field, followed by the less preferred header fields. > > most preferred algorithm? > > When the client receives the response it SHOULD use the topmost > header field that it supports, unless a local policy dictates > > First challenge. > > otherwise. The client SHOULD ignore any challenge it does not > understand. > > MUST, I believe. > > Yes > > Also, this sounds like requirements that are generic to WWW-A, not > specific to Digest, no? > > Yes. it is. Is it specified somewhere else? I would think it's said in 7235. > ... > For the username, recipients MUST support all characters defined in > the "UsernameCasePreserved" profile defined in in Section 3.3 of > [PRECIS], with the exception of the colon (":") character. > > This is copied from Basic. > > Yes, I mentioned that I will use the same text you provided with Digest. > > Is it true for Digest as well? > > I thought that was the conclusion based on the following: > http://www.ietf.org/mail-archive/web/http-auth/current/msg02005.html Yup, sorry for being unclear. My question was about the colon character. Is it disallowed in Digest? > If the user agent does not support the encoding indicated by the > server, it MUST fail the request. > > That sounds like a deployment problem. Also it reads weird given the > fact that only one value ("UTF-8") is allowed. > > Any suggestion on how to reword that? In Basic, this parameter is purely advisory. I believe the same should be true for Digest. Best regards, Julian From nobody Mon Dec 22 05:47:40 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BDF1A8F3F for ; Mon, 22 Dec 2014 05:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.638 X-Spam-Level: X-Spam-Status: No, score=0.638 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfWsOIZvWQGj for ; Mon, 22 Dec 2014 05:47:36 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9B36A1A8F38 for ; Mon, 22 Dec 2014 05:47:36 -0800 (PST) Received: from bach.greenbytes.de (unknown [217.91.35.233]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id D119915A06FF; Mon, 22 Dec 2014 14:47:35 +0100 (CET) From: =?windows-1252?Q?Michael_K=F6ller?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Dec 2014 14:47:35 +0100 Message-Id: <42CB92A9-7342-401B-9005-BE5D1FDACC09@greenbytes.de> To: http-auth@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/qfv4ZjjIfKd6dc4ZzKhvJ2k653w Cc: Julian Reschke Subject: [http-auth] Last Call review: Basic Authentication Scheme X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 13:47:37 -0000 Hi, Today Julian asked me to review the Basic authentication Last Call = draft. Apologies if my remarks may already have been discussed on this list. I = just subscribed today for the purpose of this mail, so I=92m most = probably not up to date with current discussion not yet reflected in the = document. There=92s one sentence that might qualify as a bug? Chapter 2.2 defines = the term =82authentication scope=91. It reads: > Given the absolute URI ([RFC3986], Section 4.3) of an authenticated = request, the authentication scope of that request is obtained by = removing all characters after the last slash ("/") character. I assume this definition fails to address slashes within the query part = of the URI. So the authorization scope should be obtained by removing = all characters after the last slash in the path of the absolute request = URI. Regards, Michael= From nobody Mon Dec 22 10:59:57 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B9D1A3BA3 for ; Mon, 22 Dec 2014 10:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9QpsM7tO9lK for ; Mon, 22 Dec 2014 10:59:52 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ECC61A2119 for ; Mon, 22 Dec 2014 10:59:51 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gd6so4528233lab.1 for ; Mon, 22 Dec 2014 10:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kF1YGuLweFW8idL6935ykzbT9ioPnsGBjez109ZeKXg=; b=uPF8h8QXFdRhMNMJtsc0nTolyiBltNOzCRJtjgAyRGdwrMv4ajciSpmgA19eDvDuFr EY4k5x2fnCIiN5L6CPaTi1eQU7fV/rVg9Z0vXcvLfIVz78s7+mdP9T6SOv3yCtArSDaF hm6y+XnPu7v0PZxo1e439uHfxp0FeVQdKBiRU7LcG2MWBieYX972ygiZzCkkNVIKtaSj S1tkkP4e/T/1t5gpHQ7NswEOCwtb/N+zcOABJ3nap5sI9doDX7tcOCpxOrvdvYLniPYA RSwctONlosc7KJ9EbcW2MF8OJDkVE3yfEzkLsfeIL1AmQFaHxrrZ7MY2G2ejqCMXr8KS aYjQ== MIME-Version: 1.0 X-Received: by 10.152.4.233 with SMTP id n9mr23657109lan.61.1419274789714; Mon, 22 Dec 2014 10:59:49 -0800 (PST) Received: by 10.114.27.162 with HTTP; Mon, 22 Dec 2014 10:59:49 -0800 (PST) In-Reply-To: <5495B04B.1000903@gmx.de> References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA0B.6080201@greenbytes.de> <5495B04B.1000903@gmx.de> Date: Mon, 22 Dec 2014 13:59:49 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=089e013d1198ae0129050ad2a975 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/HguO9O6jIkVynqJBxP2672G6a_k Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 18:59:56 -0000 --089e013d1198ae0129050ad2a975 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Dec 20, 2014 at 12:22 PM, Julian Reschke wrote: > On 2014-12-20 16:33, Rifaat Shekh-Yusef wrote: > >> ... >> prefix (after both have been made absolute) may be assumed to >> be >> in the same protection space. If this parameter is omitted or >> its >> value is empty, the client SHOULD assume that the protection >> space >> consists of all URIs on the web-origin. All URIs in this list >> SHOULD use the same scheme (https or http); mixing them is a >> bad >> idea. >> >> web_origin and canonical root need definitions. >> >> >> I will point to RFC6454 for web-origin. >> Is there a document that defines canonical root? >> > > has one; > do you need this *and* web_origin? Would pointing to RFC6454 not be enough for Web Origin? > > > nonce >> A server-specified data string which should be uniquely >> generated >> each time a 401 response is made. It is recommended that this >> >> RECOMMENDED? >> >> Would there be a problem if it is a differen format? If no, why a >> normative requirement here? >> >> >> It probably can be a different format; that is probably the reason the >> text is not normative and using recommended, instead of RECOMMENDED. >> > > Please do not use lowercased BCP14 terms and assume that people will read > them differently from the uppercased variants. > > I looked at RFC2119; it states that "These words are *often* capitalized.", which implies that even lower case is to be considered normative. For that reason I agree with your statement above. How about using "advised" instead of "recommended"? > includes micro or nano seconds, or other non-repeating value, >> ETag >> is the value of the HTTP ETag header field associated with the >> requested entity, and secret-data is data known only to the >> server. With a nonce of this form a server would recalculate >> the >> hash portion after receiving the client authentication header >> field and reject the request if it did not match the nonce from >> that header field or if the time-stamp value is not recent >> enough. >> In this way the server can limit the time of the nonce's >> validity. >> The inclusion of the ETag prevents a replay request for an >> updated >> version of the resource. Including the IP address of the >> client in >> the nonce would appear to offer the server the ability to limit >> the reuse of the nonce to the same client that originally got >> it. >> However, that would break proxy farms, where requests from a >> single user often go through different proxies in the farm. >> Also, >> IP address spoofing is not that hard. >> >> Do you need a proxy *farm* for this problem? >> >> >> I think that this is just one example. Are you suggesting that we remove >> that text? >> > > I'd just rephrase it to talk about proxies in general. > > ok > An implementation might choose not to accept a previously used >> nonce or a previously used digest, in order to protect against >> a >> replay attack. Or, an implementation might choose to use >> one-time >> nonces or digests for POST or PUT requests and a time-stamp for >> GET requests. For more details on the issues involved see >> section >> 5 of this document. >> >> s/section/Section/ >> >> ...why are these lowercase; aren't they generated by xml2rfc? If >> not, they should, because otherwise they break too easily. >> >> >> I use nroff. >> > > I'd recommend to switch to xml2rfc; I can help with the conversion if you > like. > > The nonce is opaque to the client. >> >> opaque >> A string of data, specified by the server, which SHOULD be >> returned by the client unchanged in the Authorization header >> field >> of subsequent requests with URIs in the same protection space. >> It >> is recommended that this string be base64 or hexadecimal data. >> >> (see above) >> >> >> Changed RECOMMENED to recommended. >> > > Please no, see above. Just state that base64 or hex are good choices. > > > ... > >> 3.4 The Authorization Request Header >> >> s/header/header field/ >> >> The client is expected to retry the request, passing an >> Authorization header field line with Digest scheme, which is >> defined according to the framework above. The values of the >> opaque >> and algorithm fields must be those supplied in the WWW- >> Authenticate response header field for the entity being >> requested. >> >> The request includes some or all of the following parameters: >> >> "some or all" reads weird... >> >> uri >> The URI from request-target of the Request-Line; duplicated >> here >> because proxies are allowed to change the Request-Line in >> transit. >> >> The request-target of the Request-Line isn't necessarily a URI... >> >> >> What do you suggest I do instead? >> > > Dunno about what's used in practice. Either adjust the terminology to > allow an absolute path, or otherwise use the term "effect request URI" from > RFC 7230. > > ok > If a parameter or its value is improper, or required parameters >> are >> missing, the proper response is 400 Bad Request. If the request- >> >> Is this a requirement? >> >> I think so. >> >> Could it be a more specifc 4xx code? >> >> What would be the benefit of changing this now? >> > > I don't know, but then clients that assume 400 instead of 4xx are broken > anyway. I'd just state a "4xx" code. > > ok > 3.7 Security Protocol Negotiation >> >> It is useful for a server to be able to know which security >> schemes a >> client is capable of handling. >> >> It is possible that a server MAY want to require Digest as its >> >> s/MAY want/wants/ >> >> authentication method, even if the server does not know that the >> client supports it. A client is encouraged to fail gracefully if >> the >> server specifies only authentication schemes it cannot handle. >> >> When a server receives a request to access a resource, the server >> might challenge the client by responding with "401 Unauthorized" >> status code, and include one or more WWW-Authenticate header >> fields. >> >> s/status code/response/ >> >> If the server challenges with multiple Digest header fields, then >> each one of these header fields MUST use a different digest >> >> You could have multiple challenges in a single header field instance. >> >> Can you please elaborate? >> > > The syntax allows it, so you should talk more generally about multiple > challenges in a response, independently in how many header fields they > appear. > > I see. I will adjust the text. > algorithm. The server MUST add these Digest header fields to the >> response in order of preference, starting with the most preferred >> header field, followed by the less preferred header fields. >> >> most preferred algorithm? >> >> When the client receives the response it SHOULD use the topmost >> header field that it supports, unless a local policy dictates >> >> First challenge. >> >> otherwise. The client SHOULD ignore any challenge it does not >> understand. >> >> MUST, I believe. >> >> Yes >> >> Also, this sounds like requirements that are generic to WWW-A, not >> specific to Digest, no? >> >> Yes. it is. Is it specified somewhere else? >> > > I would think it's said in 7235. > > I could not find such a text in 7235. > > ... >> For the username, recipients MUST support all characters defined >> in >> the "UsernameCasePreserved" profile defined in in Section 3.3 of >> [PRECIS], with the exception of the colon (":") character. >> >> This is copied from Basic. >> >> Yes, I mentioned that I will use the same text you provided with Digest. >> >> Is it true for Digest as well? >> >> I thought that was the conclusion based on the following: >> http://www.ietf.org/mail-archive/web/http-auth/current/msg02005.html >> > > Yup, sorry for being unclear. My question was about the colon character. > Is it disallowed in Digest? > > I think so ,because the colon character is used to concatenate the username, realm, and password when calculating A1. > > If the user agent does not support the encoding indicated by the >> server, it MUST fail the request. >> >> That sounds like a deployment problem. Also it reads weird given the >> fact that only one value ("UTF-8") is allowed. >> >> Any suggestion on how to reword that? >> > > In Basic, this parameter is purely advisory. I believe the same should be > true for Digest. > > ok Thanks, Rifaat > > Best regards, Julian > --089e013d1198ae0129050ad2a975 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sat, Dec 20, 2014 at 12:22 PM, Julian Reschke <= julian.reschke@g= mx.de> wrote:
On 2014-12-20 16:33, Rifaat= Shekh-Yusef wrote:
...
=A0 =A0 =A0 =A0 =A0 =A0prefix (after both have been made absolute) may be a= ssumed to be
=A0 =A0 =A0 =A0 =A0 =A0in the same protection space. If this parameter is o= mitted or its
=A0 =A0 =A0 =A0 =A0 =A0value is empty, the client SHOULD assume that the pr= otection
=A0 =A0 space
=A0 =A0 =A0 =A0 =A0 =A0consists of all URIs on the web-origin. All URIs in = this list
=A0 =A0 =A0 =A0 =A0 =A0SHOULD use the same scheme (https or http); mixing t= hem is a bad
=A0 =A0 =A0 =A0 =A0 =A0idea.

=A0 =A0 web_origin and canonical root need definitions.


I will point to RFC6454 for web-origin.
Is there a document that defines canonical root?

<http://greenbytes.de/tech/webdav/rfc7235.html#r= fc.section.2.2> has one;
=A0
do you need this *and* web_origin?

= Would pointing to RFC6454 not be enough for Web Origin?

=A0


=A0 =A0 =A0 =A0 nonce
=A0 =A0 =A0 =A0 =A0 =A0A server-specified data string which should be uniqu= ely generated
=A0 =A0 =A0 =A0 =A0 =A0each time a 401 response is made. It is recommended = that this

=A0 =A0 RECOMMENDED?

=A0 =A0 Would there be a problem if it is a differen format? If no, why a =A0 =A0 normative requirement here?


It probably can be a different format; that is probably the reason the
text is not normative and using recommended, instead of RECOMMENDED.

 Please do not use lowercased BCP14 terms and assume that people will read t= hem differently from the uppercased variants.


I looked at RFC2119; it states = that "These word= s are often capitalized.", which implies that even lower case is to be= considered normative. For that reason I agree with your statement above.

How about using "advised" instead of &quo= t;recommended"?

=A0
=A0 =A0 =A0 =A0 =A0 =A0includes micro or nano seconds, or other non-repeati= ng value,
=A0 =A0 ETag
=A0 =A0 =A0 =A0 =A0 =A0is the value of the HTTP ETag header field associate= d with the
=A0 =A0 =A0 =A0 =A0 =A0requested entity, and secret-data is data known only= to the
=A0 =A0 =A0 =A0 =A0 =A0server. With a nonce of this form a server would rec= alculate the
=A0 =A0 =A0 =A0 =A0 =A0hash portion after receiving the client authenticati= on header
=A0 =A0 =A0 =A0 =A0 =A0field and reject the request if it did not match the= nonce from
=A0 =A0 =A0 =A0 =A0 =A0that header field or if the time-stamp value is not = recent
=A0 =A0 enough.
=A0 =A0 =A0 =A0 =A0 =A0In this way the server can limit the time of the non= ce's
=A0 =A0 validity.
=A0 =A0 =A0 =A0 =A0 =A0The inclusion of the ETag prevents a replay request = for an
=A0 =A0 updated
=A0 =A0 =A0 =A0 =A0 =A0version of the resource. Including the IP address of= the
=A0 =A0 client in
=A0 =A0 =A0 =A0 =A0 =A0the nonce would appear to offer the server the abili= ty to limit
=A0 =A0 =A0 =A0 =A0 =A0the reuse of the nonce to the same client that origi= nally got it.
=A0 =A0 =A0 =A0 =A0 =A0However, that would break proxy farms, where request= s from a
=A0 =A0 =A0 =A0 =A0 =A0single user often go through different proxies in th= e farm. Also,
=A0 =A0 =A0 =A0 =A0 =A0IP address spoofing is not that hard.

=A0 =A0 Do you need a proxy *farm* for this problem?


I think that this is just one example. Are you suggesting that we remove that text?

 I'd just rephrase it to talk about proxies in general.

ok

=A0
=A0 =A0 =A0 =A0 =A0 =A0An implementation might choose not to accept a previ= ously used
=A0 =A0 =A0 =A0 =A0 =A0nonce or a previously used digest, in order to prote= ct against a
=A0 =A0 =A0 =A0 =A0 =A0replay attack. Or, an implementation might choose to= use one-time
=A0 =A0 =A0 =A0 =A0 =A0nonces or digests for POST or PUT requests and a tim= e-stamp for
=A0 =A0 =A0 =A0 =A0 =A0GET requests. For more details on the issues involve= d see section
=A0 =A0 =A0 =A0 =A0 =A05 of this document.

=A0 =A0 s/section/Section/

=A0 =A0 ...why are these lowercase; aren't they generated by xml2rfc? I= f
=A0 =A0 not, they should, because otherwise they break too easily.


I use nroff.

 I'd recommend to switch to xml2rfc; I can help with the conversion if y= ou like.

=A0 =A0 =A0 =A0 =A0 =A0The nonce is opaque to the client.

=A0 =A0 =A0 =A0 opaque
=A0 =A0 =A0 =A0 =A0 =A0A string of data, specified by the server, which SHO= ULD be
=A0 =A0 =A0 =A0 =A0 =A0returned by the client unchanged in the Authorizatio= n header
=A0 =A0 field
=A0 =A0 =A0 =A0 =A0 =A0of subsequent requests with URIs in the same protect= ion space. It
=A0 =A0 =A0 =A0 =A0 =A0is recommended that this string be base64 or hexadec= imal data.

=A0 =A0 (see above)


Changed RECOMMENED to recommended.

 Please no, see above. Just state that base64 or hex are good choices.

> ...
=A0 =A0 3.4 The Authorization Request Header

=A0 =A0 s/header/header field/

=A0 =A0 =A0 =A0 =A0 =A0The client is expected to retry the request, passing= an
=A0 =A0 =A0 =A0 =A0 =A0Authorization header field line with Digest scheme, = which is
=A0 =A0 =A0 =A0 =A0 =A0defined according to the framework above. The values= of the
=A0 =A0 opaque
=A0 =A0 =A0 =A0 =A0 =A0and algorithm fields must be those supplied in the W= WW-
=A0 =A0 =A0 =A0 =A0 =A0Authenticate response header field for the entity be= ing
=A0 =A0 requested.

=A0 =A0 =A0 =A0 =A0 =A0The request includes some or all of the following pa= rameters:

=A0 =A0 "some or all" reads weird...

=A0 =A0 =A0 =A0 uri
=A0 =A0 =A0 =A0 =A0 =A0The URI from request-target of the Request-Line; dup= licated here
=A0 =A0 =A0 =A0 =A0 =A0because proxies are allowed to change the Request-Li= ne in
=A0 =A0 transit.

=A0 =A0 The request-target of the Request-Line isn't necessarily a URI.= ..


What do you suggest I do instead?

 Dunno about what's used in practice. Either adjust the terminology to a= llow an absolute path, or otherwise use the term "effect request URI&q= uot; from RFC 7230.

ok

=A0
=A0 =A0 =A0 =A0 If a parameter or its value is improper, or required parame= ters are
=A0 =A0 =A0 =A0 missing, the proper response is 400 Bad Request. If the req= uest-

=A0 =A0 Is this a requirement?

I think so.

=A0 =A0 Could it be a more specifc 4xx code?

What would be the benefit of changing this now?

 I don't know, but then clients that assume 400 instead of 4xx are broke= n anyway. I'd just state a "4xx" code.

ok

=A0
=A0 =A0 3.7 Security Protocol Negotiation

=A0 =A0 =A0 =A0 It is useful for a server to be able to know which security=
=A0 =A0 schemes a
=A0 =A0 =A0 =A0 client is capable of handling.

=A0 =A0 =A0 =A0 It is possible that a server MAY want to require Digest as = its

=A0 =A0 s/MAY want/wants/

=A0 =A0 =A0 =A0 authentication method, even if the server does not know tha= t the
=A0 =A0 =A0 =A0 client supports it. A client is encouraged to fail graceful= ly if the
=A0 =A0 =A0 =A0 server specifies only authentication schemes it cannot hand= le.

=A0 =A0 =A0 =A0 When a server receives a request to access a resource, the = server
=A0 =A0 =A0 =A0 might challenge the client by responding with "401 Una= uthorized"
=A0 =A0 =A0 =A0 status code, and include one or more WWW-Authenticate heade= r fields.

=A0 =A0 s/status code/response/

=A0 =A0 =A0 =A0 If the server challenges with multiple Digest header fields= , then
=A0 =A0 =A0 =A0 each one of these header fields MUST use a different digest=

=A0 =A0 You could have multiple challenges in a single header field instanc= e.

Can you please elaborate?

 The syntax allows it, so you should talk more generally about multiple chal= lenges in a response, independently in how many header fields they appear.<= span>

I see. I will adjust the text.

<= /div>
=A0
=A0 =A0 =A0 =A0 algorithm. The server MUST add these Digest header fields t= o the
=A0 =A0 =A0 =A0 response in order of preference, starting with the most pre= ferred
=A0 =A0 =A0 =A0 header field, followed by the less preferred header fields.=

=A0 =A0 most preferred algorithm?

=A0 =A0 =A0 =A0 When the client receives the response it SHOULD use the top= most
=A0 =A0 =A0 =A0 header field that it supports, unless a local policy dictat= es

=A0 =A0 First challenge.

=A0 =A0 =A0 =A0 otherwise. The client SHOULD ignore any challenge it does n= ot
=A0 =A0 =A0 =A0 understand.

=A0 =A0 MUST, I believe.

Yes

=A0 =A0 Also, this sounds like requirements that are generic to WWW-A, not<= br> =A0 =A0 specific to Digest, no?

Yes. it is. Is it specified somewhere else?

 I would think it's said in 7235.

I could not find such a text in 7235.

<= /div>

=A0

...
=A0 =A0 =A0 =A0 For the username, recipients MUST support all characters de= fined in
=A0 =A0 =A0 =A0 the "UsernameCasePreserved" profile defined in in= Section 3.3 of
=A0 =A0 =A0 =A0 [PRECIS], with the exception of the colon (":") c= haracter.

=A0 =A0 This is copied from Basic.

Yes, I mentioned that I will use the same text you provided with Digest.
=A0 =A0 Is it true for Digest as well?

I thought that was the conclusion based on the following:
http://www.ietf.org/mail-archive/web/http-au= th/current/msg02005.html

Yup, sorry for being unclear. My question was about the colon character. Is= it disallowed in Digest?

I think so ,because the colon character is use= d to concatenate the username, realm, and password when calculating A1.

=A0

=A0 =A0 =A0 =A0 If the user agent does not support the encoding indicated b= y the
=A0 =A0 =A0 =A0 server, it MUST fail the request.

=A0 =A0 That sounds like a deployment problem. Also it reads weird given th= e
=A0 =A0 fact that only one value ("UTF-8") is allowed.

Any suggestion on how to reword that?

 In Basic, this parameter is purely advisory. I believe the same should be t= rue for Digest.

ok


Thanks,
=A0Rifaat

=A0

Best regards, Julian

--089e013d1198ae0129050ad2a975-- From nobody Wed Dec 24 00:10:05 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD351ACE37; Wed, 24 Dec 2014 00:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN4ssAzfzJme; Wed, 24 Dec 2014 00:09:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A05E1A89EB; Wed, 24 Dec 2014 00:09:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141224080929.21137.49171.idtracker@ietfa.amsl.com> Date: Wed, 24 Dec 2014 00:09:29 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/FVPwj-wWW6vpegql2LlSMDLZAQI Cc: iesg-secretary@ietf.org Subject: [http-auth] Last Call Expired: X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 08:09:35 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Wed Dec 24 03:15:13 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831C61A8858; Wed, 24 Dec 2014 03:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAnTo8ES2wo5; Wed, 24 Dec 2014 03:15:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D951A1BD4; Wed, 24 Dec 2014 03:15:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 644FEBF1D; Wed, 24 Dec 2014 11:14:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndwwM7sAQyvb; Wed, 24 Dec 2014 11:14:57 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.42.31.173]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8804CBF07; Wed, 24 Dec 2014 11:14:57 +0000 (GMT) Message-ID: <549AA031.4040302@cs.tcd.ie> Date: Wed, 24 Dec 2014 11:14:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: drafts-lastcall@iana.org References: <20141210142247.26304.96086.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/JxKpDLUQfGIqYVllnSHQbNJfKeA Cc: httpauth-chairs@tools.ietf.org, "http-auth@ietf.org" , draft-ietf-httpauth-hoba@tools.ietf.org, iesg@ietf.org Subject: Re: [http-auth] [IANA #798267] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 11:15:07 -0000 Hi Amanda, Thanks for the review - responses inline and a proto-08 version (handling the various IETF LC comments) is at [1] with a diff vs. 07 at [2]. I'll plan to publish that as an official -08 in a few days if there are no comments. On 22/12/14 22:25, Amanda Baber via RT wrote: > (BEGIN IANA LAST CALL COMMENTS) > > IESG/Authors/WG Chairs: > > IANA has reviewed draft-ietf-httpauth-hoba. Authors should review > the comments and/or questions below. Please report any inaccuracies > and respond to any questions as soon as possible. > > IANA's reviewer has the following comments/questions: > > IANA has a question about one of the actions requested in the IANA > considerations section of this document. > > IANA understands that, upon approval of this document, there are six > actions which need to be completed. > > First, in the HTTP Authentication Schemes registry under the > Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry > heading at > > https://www.iana.org/assignments/http-authschemes/ > > a new authentication scheme will be registered as follows: > > Authentication Schemem Name: HOBA Reference: Section 3 of [ RFC-to-be > ] Notes: [ none ] > > Second, in the Well-Known URI registry located at: > > https://www.iana.org/assignments/well-known-uris/ > > a new well-known URI will be registered as follows: > > URI Suffix: hoba Change Controller: IETF Reference: Section 6 of [ > RFC-to-be ] Related Information: [ none ] > > IANA Note -> As this document requests registrations in an Expert > Review or Specification Required (see RFC 5226) registry, we will > initiate the required Expert Review via a separate request. Expert > review will need to be completed before your document can be approved > for publication as an RFC. Hmm, that's odd. I disagree with "will need to be completed" - this is an IETF stream consensus document and the IETF LC trumps expert review. I'll happily take comments of course when those are received in time. > > Third, a new registry is to be created called the HOBA Signature > Algorithms registry. > > IANA understands that the registry will consist of a number, meaning > and reference. > > IANA Question -> per RFC 5226, what is the registration procedure for > this registry? -07 says "specification required" what's not clear there? > > IANA Question -> Where should this new registry be located? Does it > belong at an existing URL, under an existing heading at > http://www.iana.org/protocols? If not, please supply a title for the > new category (for example, "HTTP Origin-Bound Authentication (HOBA) > Parameters"). Sure a new category is fine. Added that text. > > IANA Question -> Does this registry have a maximum value? Yes, 99. Added text. > > These are the initial registrations: > > Number: 0 Meaning: RSA-SHA256 Reference: [ RFC-to-be ] > > Number: 1 Meaning: RSA-SHA1 Reference: [ RFC-to-be ] > > Fourth, a new registry is to be created called the HOBA Key > Identifier Types registry. > > IANA understands that the registry will consist of a number, meaning > and reference. > > IANA Question -> per RFC 5226, what is the registration procedure for > this registry? Specification required as stated in -07. > > IANA Question -> Where should this new registry be located? As per above. > > IANA Question -> Does this registry have a maximum value? No. > > These are the initial registrations: > > Number: 0 Meaning: a hashed public key [ RFC6698 ] Reference: [ > RFC-to-be ] > > Number: 1 Meaning: a URI [ RFC3986 ] Reference: [ RFC-to-be ] > > Number: 2 Meaning: an unformatted string, at the user's/UA's whim > Reference: [ RFC-to-be ] > > Fifth, a new registry is to be created called the HOB Device > Identifier Types registry. > > IANA understands that the registry will consist of a number, meaning > and reference. > > IANA Question -> per RFC 5226, what is the registration procedure for > this registry? Specification required as stated in -07. > > IANA Question -> Where should this new registry be located? See above. > > IANA Question -> Does this registry have a maximum value? No. > > These are the initial registrations: > > Number: 0 Meaning: an unformatted string, at the user's/UA's whim > Reference: [ RFC-to-be ] > > Sixth, in the Permanent Message Header Field Names subregistry of the > Message Headers registry located at: > > https://www.iana.org/assignments/message-headers/ > > a new message header field name will be registered as follows: > > Header Field Name: Hobareg Template: Protocol: HTTP Status: > Reference: [ RFC-to-be ] > > IANA Note -> As this document requests registrations in an Expert > Review or Specification Required (see RFC 5226) registry, we will > initiate the required Expert Review via a separate request. Expert > review will need to be completed before your document can be approved > for publication as an RFC. See above. I disagree with your interpretation of the expert's role here (still:-) Thanks, S. > > Note: The actions requested in this document will not be completed > until the document has been approved for publication as an RFC. This > message is only to confirm what actions will be performed. > > Thanks, > > Amanda Baber IANA Request Specialist ICANN > > (END IANA LAST CALL COMMENTS) > > > On Wed Dec 10 14:23:12 2014, iesg-secretary@ietf.org wrote: >> >> The IESG has received a request from the Hypertext Transfer >> Protocol Authentication WG (httpauth) to consider the following >> document: - 'HTTP Origin-Bound Authentication (HOBA)' >> as Experimental RFC >> >> The IESG plans to make a decision in the next few weeks, and >> solicits final comments on this action. Please send substantive >> comments to the ietf@ietf.org mailing lists by 2014-12-24. >> Exceptionally, comments may be sent to iesg@ietf.org instead. In >> either case, please retain the beginning of the Subject line to >> allow automated sorting. >> >> Abstract >> >> >> HTTP Origin-Bound Authentication (HOBA) is a digital signature >> based design for an HTTP authentication method. The design can >> also be used in Javascript-based authentication embedded in HTML. >> HOBA is an alternative to HTTP authentication schemes that require >> passwords and therefore avoids all problems related to passwords, >> such as leakage of server-side password databases. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> > > > From nobody Wed Dec 24 03:15:27 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A611A8A13; Wed, 24 Dec 2014 03:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUr0YPux7ngF; Wed, 24 Dec 2014 03:15:16 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508191A9072; Wed, 24 Dec 2014 03:15:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 89E05BF20; Wed, 24 Dec 2014 11:15:12 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fs1KXe-WC4zW; Wed, 24 Dec 2014 11:15:08 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.42.31.173]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 94EEABF07; Wed, 24 Dec 2014 11:15:08 +0000 (GMT) Message-ID: <549AA03C.5070107@cs.tcd.ie> Date: Wed, 24 Dec 2014 11:15:08 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Black, David" , "paul.hoffman@vpnc.org" , "mike@phresheez.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/IFLs46TKyU_ahm1xa3lW5EhvANk Cc: "http-auth@ietf.org" , "ietf@ietf.org" Subject: Re: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 11:15:21 -0000 Hi David, Sorry for the slow response, end of year rush and all that... And thanks for the review, responses inline and a proto-08 version (handling the various IETF LC comments) is at [1] with a diff vs. 07 at [2]. I'll plan to publish that as an official -08 in a few days if there are no comments. Cheers, S. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-07.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt On 15/12/14 23:25, Black, David wrote: > This is a combined Gen-ART and OPS-Dir review. Boilerplate for both follows ... > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at: > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These comments > were written primarily for the benefit of the operational area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > Document: draft-ietf-httpauth-hoba-07 > Reviewer: David Black > Review Date: Dec XX, 2014 > IETF LC End Date: Dec 24, 2014 > > Summary: This draft is on the right track, but has open issues > described in the review. > > This draft specifies a signature-based authentication mechanism for HTTP > that is based on asymmetric (public-private) key pairs without using > certificates. A different key pair is used by each user for each for > each host ("web-origin", see [RFC6454]), and each signature is based > on a server-generated challenge. > > The draft is generally well-written and clear on the authentication > mechanics, but has weaknesses in specifying the environment that > surrounds use of this mechanism. Some of these issues are basic things > that anyone working on web technology or applied crypto "just knows", > but even the obvious needs to be stated when it's integral to security. > > -- Major issues: -- > > [1] Challenge size and predictability > > In the ABNF: > > challenge = 1*base64urlchars > > I did not see any other discussion of minimum length of challenge > or amount of entropy in the challenge. For the latter, do the challenges > need to be unpredictable? I would think so. > > I think a requirement on minimum challenge size and a recommendation on > minimum amount of entropy would be good ideas. Fair point. And you're right that this is assumed and ought be explicit, so good catch. OLD: o challenge: MUST be a base64url encoded challenge value that the server chose to send to the client NEW: o challenge: MUST be a base64url encoded challenge value that the server chose to send to the client. The challenge MUST be chosen so that it is infeasible to guess, and SHOULD be indistinguishable from (the base64url encoding of) an at least 128-bit long random string. > > [2] Challenge verification and reuse > > This sentence on p.6 strikes me as subtly dangerous: > > The challenge however is sent over > the network so as to make it simpler for a server to be stateless. > (One form of stateless challenge might be a ciphertext that the > server decrypts and checks, but that is an implementation detail.) > > The draft elsewhere asserts or assumes that challenge reuse can be > prevented by the server or be time-bounded by max-age, and relies on > those reuse limits for security properties, e.g., as in this sentence > near the end of Section 6.1: > > Note that replay of registration (and other HOBA) messages is quite > possible. That however can be counteracted if challenge freshness is > ensured. > > The sentence quoted from p.6 appears to allow (or even encourage) > stateless servers to implement rather weak checks on not only challenge > reuse, but also challenge validity (e.g., what if the challenge validity > test were "challenge mod 1024 == 7" ?). > > Allowing such weak checks could enable an attacker to choose or influence > the choice of challenge values, which could be useful (e.g., for > differential cryptanalysis attack on the hash function), as the > attacker (client) already controls the nonce. > > As part of this, the server needs to check whether a challenge presented > on one connection or session has been reused on another. I think the > following sentence in section 3 is intended to prevent this, but it's > weakened by the "stateless" language above: > > The challenge MUST be > unique for every HTTP 401 response in order to prevent replay > attacks from passive observers. > > Explicit server checks for challenge reuse ought to be REQUIRED, and > the above use of "stateless" needs to be qualified. Hmm. I think that HOBA ought not REQUIRE full replay protection in all cases, that is, it SHOULD be possible to deploy a server that is vulnerable to some replay. The reason is that we're trying to displace passwords here and I believe (without much hard evidence I'll grant you) that we'd lose some deployment chances if we were to insist on every single challenge being fresh. So I'd argue for no-change here, but would welcome further discussionm evidence or suggestions for text that's not going to be so onerous as to weaken our chances of getting this deployed. > > [3] Web origin checks > > I did not see text mandating that TLS (server certificate), HTTP (accessed > URL) and HOBA (signature input) use the same web origin, and stating that > the server has to check/enforce this. Did I miss something? > > I realize that this is an obvious requirement, but it does need to be > stated. Fair enough, I agree folks have been known to not implement even the most obvious things:-) I added the text below to section 3: The server MUST check that the same web origin is used in all of the server's TLS server certificate, the URL being accessed and the HOBA signature. If any of those checks fail, the server treats the signature as being cryptographically incorrect. > > [4] TLS requirement level > > TLS is only a "SHOULD" requirement for HOBA, not a "MUST" requirement - > first paragraph in Section 8.1 (Privacy Considerations). > > If TLS is not a "MUST" requirement, at least a discussion of man-in-the- > middle (MITM) attacks seems to be in order. There's no need for an extensive > discussion of all of the security properties of TLS, but MITM attacks are > definitely worth a mention, and that could be complemented by a pointer to > suitable HTTP/TLS security considerations text elsewhere. I think that's covered where we note the potential for replay, which is what a MitM would/could do in this case. That is noted in both section 3 and in 6.1 and in section 8. I think we have it covered to be honest. > > [5] Section 5.3 - unrecognized key > > Paragraphs 4 and 5 in this section don't seem to belong here, and appear to > be written in a somewhat loose fashion, particularly around user verification. > A server that does what is suggested here could have significant security > weaknesses. Which specific weaknesses do you mean? > > I strongly recommend replacing those two paragraphs with a short sentence that > says: > - if a kid is unrecognized or the server otherwise determines > that the CPK is not to be used for this HTTP authentication, > - then the Registration (see 6.1) and/or Associating Additional Keys to > an Exiting Account (see 6.2) processes MAY be used instead of > treating this situation as an authentication failure. > > and moving all discussion of user verification into Sections 6.1 and 6.2. Sorry, I don't think that is needed at all. The current text simply reflects the kind of thing that we think deployments will do and will need to do and I don't see what specific weaknesses you are claiming might ensue. I'd be happy to note any such of course. Also, from my reading your suggested text has the same impact and only differs in using a 2119 MAY instead of could, might etc. But if you meant it to differ more substantively you'll need to explain that to me some more. > > -- Minor issues: -- > > [A] ABNF encoding of alg > > In section 2, I see: > > alg = 1*2DIGIT > > o alg: specifies the signature algorithm being used encoded as an > ASCII character as defined in Section 9.3. > > Section 9.3 specifies a single digit. How does that become 1*2DIGIT ? Huh? The current algs only use one digit, but the abnf allows for more. Nothing odd there that I can see. > I suggest: "as an ASCII character" -> "as one or two ASCII digits based > on the IANA registry established by Section 9.3" I think it's ok as is. > This may seem like a nit, but any imprecision in signature algorithm > input can lead to interoperability problems. Yes it can. But we're not being imprecise that I can see. > > [B] Section 5.3 - CPK vs. kid > > In the authentication phase, the server extracts the CPK from the > signing phase and decides if it recognizes the CPK. If the server > recognizes the CPK, the server may finish the client authentication > process. > > That seems wrong. IIUC, the HOBA client sends: > > HOBA-RES = kid "." challenge "." nonce "." sig > > If so, I don't understand how the server extracts a CPK from that. Via the kid yes. > > I suspect that what was intended is that the server extracts a key identifier > (kid) and then determines a) whether it knows a CPK for that kid and b) whether > it allows use of that kid/CPK for this authentication. At least a) seems to > be indicated by this text in Section 3: > > The server MUST check the cryptographic correctness of the signature > based on a public key it knows for the kid in the signatures, I'm not seeing an actionable issue that needs a change. > > [C] RSA signature algorithm > > Section 7 says: > > RSA is defined in > Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. > > Section 8.2 of RFC 3447 specifies RSASSA-PKCS1-v1_5. At a minimum, that > algorithm name should be stated here (which is a nit). Disagree (also as a nit:-) > The minor issue is > whether that is the signature algorithm that's wanted, on which I'll defer > to the crypto experts on that (e.g., I seem to recall a negative saag > comment on PKCS 1.5 mechanisms in the past couple of months). Yes, it's fine for security and is correct for interop/deployment reasons. PKCSv1.5 encryption is what's less desirable if not done well and attempting to mandate PSS here would be a bad plan. > > [D] Javascript local storage. > > The first paragraph of Section 8.2 on this topic concludes with: > > It's not clear that we > introduce unique threats from which clear text passwords don't > already suffer. > > That's at odds with the use of "all" in this sentence in the abstract: > > HOBA is an > alternative to HTTP authentication schemes that require passwords and > therefore avoids all problems related to passwords, such as leakage > of server-side password databases. > > One of those two paragraphs needs some editing. I don't think so actually, the first quoted sentence above is in the context of a web site with XSS vulnerabilities. Omitting that context would make for bad text, but the immediately preceding sentence is fairly explicit on that. (In passing, I did edit the top of that para a bit, since using the WebCrypto API is now possible so a tweak was needed.) > > -- Nits/editorial comments: -- > > This is buried near the end of section 6.1 > > Note that replay of registration (and other HOBA) messages is quite > possible. That however can be counteracted if challenge freshness is > ensured. > > That's not a good place for these two sentences. HOBA registration > messages don't contain a challenge, and the general discussion of > replay attacks belongs under Security Considerations, not Registration. They do contain a challenge in the header, though not in the body. I think the sentence is ok where it is. > > In Section 9.4 and 9.5, I see the following proposed as part of IANA > registry contents: > > an unformatted string, at the user's/UA's whim > > I get the point, but it's still not appropriate for an IANA registry > - remove ", at the user's/UA's whim". I whimsically disagree:-) IANA shouldn't be against whimsy. > Appendix A appears to assume that human-memorable passwords are stored in > the clear in server databases. It should also briefly discuss the use > of one-way functions, especially computationally intensive ones, to > generate stored password verifiers. HOBA is still superior by comparison, > as the one-way functions only increase the difficulty of dictionary > attack, whereas dictionary attack on HOBA keys is pointless when > sufficiently large keys are used. I'd prefer to not get into more analysis of passwords, and even hashed passwords are essentially guessable. > > idnits 2.13.01 found the references to W3C's web site (www.w3.org) in > Section 4, e.g., > > 389 One element is required for HOBA-js: localStorage (see http:// > 390 www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key > 391 storage. > > I think idnits can be ignored, even though the "right way" to fix this is to > move each URL to a reference and cite the reference in Section 4. > > OTOH, idnits did not complain about the normative reference to RFC 20 ;-). Heh:-) > > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > Most of these questions are n/a because this draft describes an extension > to HTTP authentication, and RFC 5706's concerns would apply primarily to > HTTP and HTTP authentication. > > A.1.1 Has deployment been discussed? > > Yes, section 6 discusses how a user would deploy this for her access to web > servers. > > A.1.4. Have the Requirements on other protocols and functional > components been discussed? > > Yes, the discussion of how this functions within HTTP is sufficient. > > Major issues [3] and [4] fall into this category, but in both cases, > I think they're probably text oversights that are easy to fix. > > A.2.7 Is security management discussed? > > Not really, but this is an Experimental RFC. I would expect that the > experimental use of HOBA will yield insight into server key database > structure/management, key lifecycle management (e.g., revocation), > account management techniques/processes, etc. > > A.3. Documentation > > I do not expect significant operational impact. > > Section 10 notes the existence of two implementations of HOBA-JS and > one implementation of HOBA-http. That's a good start for an experiment. And now there's a 3rd! Thanks again for the fine review, S. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > From nobody Wed Dec 24 03:15:33 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7283D1ACD9B; Wed, 24 Dec 2014 03:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn85WFu2QGr3; Wed, 24 Dec 2014 03:15:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D471A8A15; Wed, 24 Dec 2014 03:15:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 15183BF20; Wed, 24 Dec 2014 11:15:20 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEX8Ge-QetMZ; Wed, 24 Dec 2014 11:15:17 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.42.31.173]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 412D9BF2F; Wed, 24 Dec 2014 11:15:14 +0000 (GMT) Message-ID: <549AA041.1070401@cs.tcd.ie> Date: Wed, 24 Dec 2014 11:15:13 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , ietf@ietf.org References: <20141210142247.26304.1220.idtracker@ietfa.amsl.com> <549033EE.2070302@greenbytes.de> In-Reply-To: <549033EE.2070302@greenbytes.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/szgdpmEzwsxXiSROfGsx3rJQAHs Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 11:15:25 -0000 Hi Julian, Thanks for the review and as noted in my response to David's... a proto-08 version (handling the various IETF LC comments) is at [1] with a diff vs. 07 at [2]. I'll plan to publish that as an official -08 in a few days if there are no comments. Cheers, S. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-07.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt On 16/12/14 13:30, Julian Reschke wrote: > Hi there, > > > see below my feedback on draft-ietf-httpauth-hoba-07. > > Best regards, Julian > > > -- feedback here -- > > > 1. Introduction > > HTTP Origin-Bound Authentication (HOBA) is an authentication design > that can be used as an HTTP authentication scheme [RFC7235] and for > Javascript-based authentication embedded in HTML. The main goal of > HOBA is to offer an easy-to-implement authentication scheme that is > not based on passwords, but that can easily replace HTTP or HTML > forms-based password authentication. Deployment of HOBA can reduce > or eliminate password entries in databases, with potentially > significant security benefits. > > "HTTP or HTML forms-based password authentication" reads weird. Maybe > "HTTP authentication [RFC7235] or authentication based on HTML forms and > cookies [ref]"? I prefer the current text to be honest. Seems purely stylistic to me. > > HOBA is an HTTP authentication mechanism that complies with the > framework for such schemes [RFC7235]. As a JavaScript design, HOBA > demonstrates a way for clients and servers to interact using the same > credentials that are used by the HTTP authentication scheme. > > Also confusing. Maybe state upfront that you define two different > protocols (sharing algorithms), one as HTTP auth scheme, one using JS. I disagree that this is confusing. > When done, use terminology conistently ("HOBA", HOBA HTTP auth scheme", > "HOBA JS whatever"). [I see you later defined HOBA-http and HOBA-js; > maybe do this earlier] That's done in section 1. Earlier would be quite tricky. > > Current username/password authentication methods such as HTTP Basic, > HTTP Digest, and web forms have been in use for many years but are > > Maybe add citations for these schemes? They're there later. > > ... > > HOBA session management is identical to username/password session > management, with a server-side session management tool or script > inserting a session cookie into the output to the browser. HOBA > still requires TLS to prevent session cookie hijacking. > > At this point you absolutely need to cite the Cookie spec. Yep - good catch. Added a ref to 6265 there. (There was one later anyway.) > > HOBA keys are "bare keys", so there is no need for the semantic > overhead of PKIX certificates, particularly with respect to naming > and trust anchors. The client public key ("CPK") structures in HOBA > do not have any publicly-visible identifier for the user who > possesses the corresponding private key, nor the web-origin with > which the client is using the CPK. > > Expand "PKIX". Yes, that's not great - changed to say "X.509 public key certificates" instead of "PKIX certificates." > > HOBA also defines some services that are required for modern HTTP > authentication: > > Avoid lowercase BCP14 terms. Also, don't understand "modern" here ;-) AVOIDED:-) "Modern" here means considering more of the life cycle as is clear from the list that follows (and hence does not need to be clarified before the list itself). > > ... > > 1.1. Interfacing to Applications (Cookies) > > HOBA can be used as a drop-in replacement for password-based user > authentication schemes used in common web applications. The simplest > way is to (re-)direct the UA to a HOBA "Login" URL and for the > response to a successful HTTP request containing a HOBA signature to > set a session cookie [RFC6265]. Further interactions with the web > application will then be secured via the session cookie, as is > commonly done today. > > Does this apply to the HTTP authentication scheme, too? Yes, which is why we don't say HOBA-js. My server code does exactly that in most cases. > > > 1.2. Terminology > > ... > > This specification uses the Augmented Backus-Naur Form (ABNF) > notation of [RFC5234] > > s/[RFC5234]/[RFC5234]./ ack > > Account: The term "account" is (loosely) used to refer to whatever > data structure(s) the server maintains that are associated with an > identity. That will contain of at least one CPK and a web-origin; it > will also optionally include an HTTP "realm" as defined in the HTTP > authentication specification. [RFC7235]. It might also involve many > > s/. [RFC7235]./[RFC7235]./ ack > > ... > > > 2. The HOBA Authentication Scheme > > HOBA-TBS = len ":" nonce > len ":" alg > len ":" origin > len ":" [ realm ] > len ":" kid > len ":" challenge > len = 1*DIGIT > nonce = 1*base64urlchars > alg = 1*2DIGIT > origin = scheme "://" authority ":" port > realm = unreserved > kid = 1*base64urlchars > challenge = 1*base64urlchars > ; Characters for Base64URL encoding from Table 2 of RFC 4648 > base64urlchars = %x30-39 ; Digits > / %x41-5A ; Uppercase letters > / %x61-7A ; Lowercase letters > / "-" / "_" / "=" ; Special characters > > Figure 1: To-be-signed data for HOBA > > ...specify a proper ABNF production for "unreserved". What? I don't know what you mean there. I added a pointer to 2.2 of RFC 7235 though, is that enough? > ...say where scheme, authority etc come from. done > ...maybe clarify that all of these characters are in US-ASCII (wrt to > encoding into octets) Really? Another ref to RFC20? Sure, why not. > > ... > > o nonce: is a random value chosen by the UA and MUST be base64url > encoded before being included in the HOBA-TBS value. (base64url > encoding is defined in [RFC4648].) UAs MUST be able to use at > least 32 bits of randomness in generating a nonce. UAs SHOULD be > able to use 64 or more bits of randomness for nonces. > > "MUST be able to use"... doesn't sound testable. It's still worth saying though. > > ... > > The HOBA "client result" is a dot-separated string that includes the > signature and is sent in the HTTP Authorized header field value using > > "Authorized"? Heh. Fixed. (Well, made it correct, fixing it would change the name:-) > > > 3. Introduction to the HOBA-http Mechanism > > ... > > o A "max-age" attribute MUST be included that specifies the number > of seconds from the time the HTTP response is emitted for which > responses to this challenge can be accepted for example "max-age: > 10" would indicatge ten seconds. If max-age is set to zero, then > that means that only one signature will be accepted for this > challenge. > > s/indicatge/indicate/ ack > > o A "realm" attribute MAY be included to indicate the scope of > protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. > The "realm" attribute MUST NOT appear more than once. > > ... > additional mechanisms to validate the signature. If the validation > fails, or if the server chooses reject the signature for any reason > whatsoever, the server aborts the transaction via a 401 Unauthorized > HTTP response. > > "..fails the request with a 401..." (I'd prefer not to speak of > transactions here) Ah good yes. > > Note that a HOBA signature is good for however long a non-zero max- > age attribute allows. This means that replay is possible within the > > s/attribute/parameter/ ack > > ... > > > 4. Introduction to the HOBA-js Mechanism > > ... > > One element is required for HOBA-js: localStorage (see http:// > www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key > > Add proper reference. I'll follow the RFC editor's preference. (I prefer refs that are only URLs like this myself, but they'll fix as they need to.) > > storage. For example, an implementation would store a dictionary > account identifier, public key and private key tuples in the origin's > localStorage for subsequent authentication requests. How this > information is actually stored in localStorage is an implementation > detail. This type of key storage relies on the security properties > of the same-origin policy that localStorage enforces. See the > security considerations for discussion about attacks on localStorage. > Note that IndexedDB (See http://www.w3.org/TR/IndexedDB/) is an > alternative to localStorage that can also be used here. > > And here. Ditto:-) > > Because of JavaScript's same-origin policy, scripts from subdomains > do not have access to the same localStorage that scripts in their > parent domains do. For larger or more complex sites, this could be > an issue that requires enrollment into subdomains, which could be a > hassle for users. One way to get around this is to use session > cookies because they can be used across subdomains. That is, with > HOBA-js, the user might log in using a single well-known domain, and > then the server uses session cookies to navigate around a site. > > Another element will be highly desirable for HOBA-js when it becomes > available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In > lieu of WebCrypto, JavaScript crypto libraries can be employed with > the known deficiencies of their pseudo-random number generators and > the general immaturity of those libraries. > > And here. Ditto ditto:-) > > > 5.3. Authentication Phase > > ... > If this stage of the process involves additional information for > authentication, such as asking the user which account she wants to > use (in the case where a UA is used for multiple accounts on a site), > the server can prompt the user for account identifying information or > the user could choose based on HTML offered by the server before the > 401 is triggered. None of this is standardized: it all follows the > > s/401/401 response/ good thanks > > server's security policy and session flow. At the end of this, the > server probably assigns or updates a session cookie for the client. > > > 6. Other Parts of the HOBA Process > > ... > > There are many use cases for these URLs to redirect to other URLs: a > site that does registration through a federated site, a site that > only does registration under HTTPS, and so on. Like any HTTP client, > HOBA-http clients have to be able to handle redirection of these > URLs. However, as that would potentially cause security issues when > > s/URLs/requests/ yep > > > 6.1. Registration > > Normally, a registration (also called "joining") is expected to > happen after a UA receives a WWW-Authenticate for a web-origin and > > s/WWW-Authenticate/401 response/ (right?) Yes that's better I think. > > ... > > The registration message for HOBA-http is sent as a POST message to > the URL ".well-known/hoba/register" with an HTML form (x-www-form- > encoded) described below; The registration message for HOBA-js can be > > Need citation for payload format. To RFC 1867? Added that (though it's been obsoleted). Happy to replace with a better ref so long as that better ref is not a work-in-progress:-) > Why does this need to be an HTML form, > btw? Doesn't need to be, but it just is as that works fine. > > ... > > o did: a UTF8 string that specifies the device identifier. This can > be used to help a user be confident that authentication has > worked, e.g., following authentication some web content might say > "You last logged in from device 'did' at time T." > > An example would be good to people note that many characters (plus all > non-ASCII characters) need to be percent-escaped in this payload format. Seems to me that it is not necessary to have an example of every single use of UTF8. Happy to add supplied text though. > > > 6.1.1. Hobareg Definition > > ... > > For this reason the server MUST add a header to the response message > > s/header/header field/ ack (I get that wrong now and then regardless of how often I'm told, maybe we should start to get over the distinction:-) > > when the registration has succeded to indicate the new state. The > header to be used is "Hobareg" and the value when registration has > succeeded is to be "regok". When registration is inwork (e.g. on an > HTTP response for an interstitial page) the server MAY add this > header with a value of "reginwork". See Section 9.6 for the relevant > IANA registration of this header field. > > Could this use the Authentication-Info header field currently defined in > DIGEST? Maybe but would prefer to not entwine with DIGEST in that way. Seems like all we'd get is delay and no benefit. > > ... > > o Only one single value is allowed in a Hobareg header field. > Should more than one (a list) be encountered, that should be > interpreted as being the same as "inwork." > > Misleading; just state that any ABNF-invalid value is to be interpreted > as "inwork". Sure, that's better. I left in the list example as well though. > > ... > > o Since Hobareg is only meant for responses it ought not appear in a > PUT request. > > Drop the part about PUT; not allowed in request means not allowed in > requests... ack > > ... > > o Intermediaries should never insert, delete or modify a Hobareg > header field. > > SHOULD? or even MUST? Got rid of the "should" based on another comment, so it's now the moral equivalent of MUST > > 6.2. Associating Additional Keys to an Exiting Account > > I'll assume you meant to say "Existing" :-) heh:-) > > > 6.3. Logging Out > > > The user can tell the server it wishes to log out. With HOBA-http, > this is done by sending any HOBA-authenticated HTTP message to the > URL ".well-known/hoba/logout" on the site in question. The UA SHOULD > also delete session cookies associated with the session so that the > user's state is no longer "logged in." > > Nope. Don't define this for GET (or any "safe" method). POST would work. Sorry I'm not seeing why that is GET specific? I agree POST should be fine too, but think that is allowed by the above. > > > 8.1. Privacy considerations > > HOBA does impact to some extent on privacy and could be considered to > > s/on// No, it's correct as-is. > > represent a super-cookie to the server, or to any entity on the path > from UA to HTTP server that can see the HOBA signature. This is > because we need to send a key identifier as part of the signature and > that will not vary for a given key. For this reason, and others, it > is strongly RECOMMENDED to only use HOBA over server-authenticated > TLS and to migrate web sites using HOBA to only use "https" URLs. > > UAs SHOULD provide users a way to manage their CPKs. Ideally, there > would be a way for a user to maintain their HOBA details for a site > while at the same time deleting other site information such as > cookies or non-HOBA HTML5 LocalStorage. However, as this is likely > to be complex and appropriate user interfaces counter intutitive, we > exepect that UAs that implement HOBA will likely treat HOBA > > s/exepect/expect/ ack > > information as just some more site data, that would disappear should > the user choose to "forget" that site. > > > > 9.6. Hobareg HTTP Header > > s/Header/Header Field/ ack > > > > 12.1. Normative References > > 12.2. Informative References > > [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data > Encodings", RFC 4648, October 2006. > > This is likely normative. sure > > [bonneau] Bonneau, , "The science of guessing: analyzing an > anonymized corpus of 70 million passwords.", Security and > Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012. , 2012. > > This reference looks broken (interpunction-wise). Tidied up. > > > Appendix A. Problems with Passwords > > ... > > Using memorizable passwords on unencrypted channels also poses risks > to the users. If a web site uses either the HTTP Plain > > s/Plain/Basic/ ? (also add ref) changed, ref is earlier > > Appendix B. Example > > > The following values show an example of HOBA-http authentication to > the origin https://example.com:443 Carriage-returns have been added > > s/443/443./ Sure, though not sure what RFC editor prefers there (for URLs at the end of sentences) but they can fix if needed. S. > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From nobody Wed Dec 24 03:15:38 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706C21AD029; Wed, 24 Dec 2014 03:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKOv5Hl9_Pv6; Wed, 24 Dec 2014 03:15:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5375C1A8A57; Wed, 24 Dec 2014 03:15:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1AB34BF2D; Wed, 24 Dec 2014 11:15:20 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yArzEc-RNLL; Wed, 24 Dec 2014 11:15:17 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.42.31.173]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2FDCABF2E; Wed, 24 Dec 2014 11:15:14 +0000 (GMT) Message-ID: <549AA041.3000205@cs.tcd.ie> Date: Wed, 24 Dec 2014 11:15:13 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , ietf@ietf.org References: <20141210142247.26304.1220.idtracker@ietfa.amsl.com> <549033EE.2070302@greenbytes.de> In-Reply-To: <549033EE.2070302@greenbytes.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/cUzvRVht1B1FTSPqkNGxgtKUdLY Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 11:15:26 -0000 Hi Julian, Thanks for the review and as noted in my response to David's... a proto-08 version (handling the various IETF LC comments) is at [1] with a diff vs. 07 at [2]. I'll plan to publish that as an official -08 in a few days if there are no comments. Cheers, S. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-07.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt On 16/12/14 13:30, Julian Reschke wrote: > Hi there, > > > see below my feedback on draft-ietf-httpauth-hoba-07. > > Best regards, Julian > > > -- feedback here -- > > > 1. Introduction > > HTTP Origin-Bound Authentication (HOBA) is an authentication design > that can be used as an HTTP authentication scheme [RFC7235] and for > Javascript-based authentication embedded in HTML. The main goal of > HOBA is to offer an easy-to-implement authentication scheme that is > not based on passwords, but that can easily replace HTTP or HTML > forms-based password authentication. Deployment of HOBA can reduce > or eliminate password entries in databases, with potentially > significant security benefits. > > "HTTP or HTML forms-based password authentication" reads weird. Maybe > "HTTP authentication [RFC7235] or authentication based on HTML forms and > cookies [ref]"? I prefer the current text to be honest. Seems purely stylistic to me. > > HOBA is an HTTP authentication mechanism that complies with the > framework for such schemes [RFC7235]. As a JavaScript design, HOBA > demonstrates a way for clients and servers to interact using the same > credentials that are used by the HTTP authentication scheme. > > Also confusing. Maybe state upfront that you define two different > protocols (sharing algorithms), one as HTTP auth scheme, one using JS. I disagree that this is confusing. > When done, use terminology conistently ("HOBA", HOBA HTTP auth scheme", > "HOBA JS whatever"). [I see you later defined HOBA-http and HOBA-js; > maybe do this earlier] That's done in section 1. Earlier would be quite tricky. > > Current username/password authentication methods such as HTTP Basic, > HTTP Digest, and web forms have been in use for many years but are > > Maybe add citations for these schemes? They're there later. > > ... > > HOBA session management is identical to username/password session > management, with a server-side session management tool or script > inserting a session cookie into the output to the browser. HOBA > still requires TLS to prevent session cookie hijacking. > > At this point you absolutely need to cite the Cookie spec. Yep - good catch. Added a ref to 6265 there. (There was one later anyway.) > > HOBA keys are "bare keys", so there is no need for the semantic > overhead of PKIX certificates, particularly with respect to naming > and trust anchors. The client public key ("CPK") structures in HOBA > do not have any publicly-visible identifier for the user who > possesses the corresponding private key, nor the web-origin with > which the client is using the CPK. > > Expand "PKIX". Yes, that's not great - changed to say "X.509 public key certificates" instead of "PKIX certificates." > > HOBA also defines some services that are required for modern HTTP > authentication: > > Avoid lowercase BCP14 terms. Also, don't understand "modern" here ;-) AVOIDED:-) "Modern" here means considering more of the life cycle as is clear from the list that follows (and hence does not need to be clarified before the list itself). > > ... > > 1.1. Interfacing to Applications (Cookies) > > HOBA can be used as a drop-in replacement for password-based user > authentication schemes used in common web applications. The simplest > way is to (re-)direct the UA to a HOBA "Login" URL and for the > response to a successful HTTP request containing a HOBA signature to > set a session cookie [RFC6265]. Further interactions with the web > application will then be secured via the session cookie, as is > commonly done today. > > Does this apply to the HTTP authentication scheme, too? Yes, which is why we don't say HOBA-js. My server code does exactly that in most cases. > > > 1.2. Terminology > > ... > > This specification uses the Augmented Backus-Naur Form (ABNF) > notation of [RFC5234] > > s/[RFC5234]/[RFC5234]./ ack > > Account: The term "account" is (loosely) used to refer to whatever > data structure(s) the server maintains that are associated with an > identity. That will contain of at least one CPK and a web-origin; it > will also optionally include an HTTP "realm" as defined in the HTTP > authentication specification. [RFC7235]. It might also involve many > > s/. [RFC7235]./[RFC7235]./ ack > > ... > > > 2. The HOBA Authentication Scheme > > HOBA-TBS = len ":" nonce > len ":" alg > len ":" origin > len ":" [ realm ] > len ":" kid > len ":" challenge > len = 1*DIGIT > nonce = 1*base64urlchars > alg = 1*2DIGIT > origin = scheme "://" authority ":" port > realm = unreserved > kid = 1*base64urlchars > challenge = 1*base64urlchars > ; Characters for Base64URL encoding from Table 2 of RFC 4648 > base64urlchars = %x30-39 ; Digits > / %x41-5A ; Uppercase letters > / %x61-7A ; Lowercase letters > / "-" / "_" / "=" ; Special characters > > Figure 1: To-be-signed data for HOBA > > ...specify a proper ABNF production for "unreserved". What? I don't know what you mean there. I added a pointer to 2.2 of RFC 7235 though, is that enough? > ...say where scheme, authority etc come from. done > ...maybe clarify that all of these characters are in US-ASCII (wrt to > encoding into octets) Really? Another ref to RFC20? Sure, why not. > > ... > > o nonce: is a random value chosen by the UA and MUST be base64url > encoded before being included in the HOBA-TBS value. (base64url > encoding is defined in [RFC4648].) UAs MUST be able to use at > least 32 bits of randomness in generating a nonce. UAs SHOULD be > able to use 64 or more bits of randomness for nonces. > > "MUST be able to use"... doesn't sound testable. It's still worth saying though. > > ... > > The HOBA "client result" is a dot-separated string that includes the > signature and is sent in the HTTP Authorized header field value using > > "Authorized"? Heh. Fixed. (Well, made it correct, fixing it would change the name:-) > > > 3. Introduction to the HOBA-http Mechanism > > ... > > o A "max-age" attribute MUST be included that specifies the number > of seconds from the time the HTTP response is emitted for which > responses to this challenge can be accepted for example "max-age: > 10" would indicatge ten seconds. If max-age is set to zero, then > that means that only one signature will be accepted for this > challenge. > > s/indicatge/indicate/ ack > > o A "realm" attribute MAY be included to indicate the scope of > protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. > The "realm" attribute MUST NOT appear more than once. > > ... > additional mechanisms to validate the signature. If the validation > fails, or if the server chooses reject the signature for any reason > whatsoever, the server aborts the transaction via a 401 Unauthorized > HTTP response. > > "..fails the request with a 401..." (I'd prefer not to speak of > transactions here) Ah good yes. > > Note that a HOBA signature is good for however long a non-zero max- > age attribute allows. This means that replay is possible within the > > s/attribute/parameter/ ack > > ... > > > 4. Introduction to the HOBA-js Mechanism > > ... > > One element is required for HOBA-js: localStorage (see http:// > www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key > > Add proper reference. I'll follow the RFC editor's preference. (I prefer refs that are only URLs like this myself, but they'll fix as they need to.) > > storage. For example, an implementation would store a dictionary > account identifier, public key and private key tuples in the origin's > localStorage for subsequent authentication requests. How this > information is actually stored in localStorage is an implementation > detail. This type of key storage relies on the security properties > of the same-origin policy that localStorage enforces. See the > security considerations for discussion about attacks on localStorage. > Note that IndexedDB (See http://www.w3.org/TR/IndexedDB/) is an > alternative to localStorage that can also be used here. > > And here. Ditto:-) > > Because of JavaScript's same-origin policy, scripts from subdomains > do not have access to the same localStorage that scripts in their > parent domains do. For larger or more complex sites, this could be > an issue that requires enrollment into subdomains, which could be a > hassle for users. One way to get around this is to use session > cookies because they can be used across subdomains. That is, with > HOBA-js, the user might log in using a single well-known domain, and > then the server uses session cookies to navigate around a site. > > Another element will be highly desirable for HOBA-js when it becomes > available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In > lieu of WebCrypto, JavaScript crypto libraries can be employed with > the known deficiencies of their pseudo-random number generators and > the general immaturity of those libraries. > > And here. Ditto ditto:-) > > > 5.3. Authentication Phase > > ... > If this stage of the process involves additional information for > authentication, such as asking the user which account she wants to > use (in the case where a UA is used for multiple accounts on a site), > the server can prompt the user for account identifying information or > the user could choose based on HTML offered by the server before the > 401 is triggered. None of this is standardized: it all follows the > > s/401/401 response/ good thanks > > server's security policy and session flow. At the end of this, the > server probably assigns or updates a session cookie for the client. > > > 6. Other Parts of the HOBA Process > > ... > > There are many use cases for these URLs to redirect to other URLs: a > site that does registration through a federated site, a site that > only does registration under HTTPS, and so on. Like any HTTP client, > HOBA-http clients have to be able to handle redirection of these > URLs. However, as that would potentially cause security issues when > > s/URLs/requests/ yep > > > 6.1. Registration > > Normally, a registration (also called "joining") is expected to > happen after a UA receives a WWW-Authenticate for a web-origin and > > s/WWW-Authenticate/401 response/ (right?) Yes that's better I think. > > ... > > The registration message for HOBA-http is sent as a POST message to > the URL ".well-known/hoba/register" with an HTML form (x-www-form- > encoded) described below; The registration message for HOBA-js can be > > Need citation for payload format. To RFC 1867? Added that (though it's been obsoleted). Happy to replace with a better ref so long as that better ref is not a work-in-progress:-) > Why does this need to be an HTML form, > btw? Doesn't need to be, but it just is as that works fine. > > ... > > o did: a UTF8 string that specifies the device identifier. This can > be used to help a user be confident that authentication has > worked, e.g., following authentication some web content might say > "You last logged in from device 'did' at time T." > > An example would be good to people note that many characters (plus all > non-ASCII characters) need to be percent-escaped in this payload format. Seems to me that it is not necessary to have an example of every single use of UTF8. Happy to add supplied text though. > > > 6.1.1. Hobareg Definition > > ... > > For this reason the server MUST add a header to the response message > > s/header/header field/ ack (I get that wrong now and then regardless of how often I'm told, maybe we should start to get over the distinction:-) > > when the registration has succeded to indicate the new state. The > header to be used is "Hobareg" and the value when registration has > succeeded is to be "regok". When registration is inwork (e.g. on an > HTTP response for an interstitial page) the server MAY add this > header with a value of "reginwork". See Section 9.6 for the relevant > IANA registration of this header field. > > Could this use the Authentication-Info header field currently defined in > DIGEST? Maybe but would prefer to not entwine with DIGEST in that way. Seems like all we'd get is delay and no benefit. > > ... > > o Only one single value is allowed in a Hobareg header field. > Should more than one (a list) be encountered, that should be > interpreted as being the same as "inwork." > > Misleading; just state that any ABNF-invalid value is to be interpreted > as "inwork". Sure, that's better. I left in the list example as well though. > > ... > > o Since Hobareg is only meant for responses it ought not appear in a > PUT request. > > Drop the part about PUT; not allowed in request means not allowed in > requests... ack > > ... > > o Intermediaries should never insert, delete or modify a Hobareg > header field. > > SHOULD? or even MUST? Got rid of the "should" based on another comment, so it's now the moral equivalent of MUST > > 6.2. Associating Additional Keys to an Exiting Account > > I'll assume you meant to say "Existing" :-) heh:-) > > > 6.3. Logging Out > > > The user can tell the server it wishes to log out. With HOBA-http, > this is done by sending any HOBA-authenticated HTTP message to the > URL ".well-known/hoba/logout" on the site in question. The UA SHOULD > also delete session cookies associated with the session so that the > user's state is no longer "logged in." > > Nope. Don't define this for GET (or any "safe" method). POST would work. Sorry I'm not seeing why that is GET specific? I agree POST should be fine too, but think that is allowed by the above. > > > 8.1. Privacy considerations > > HOBA does impact to some extent on privacy and could be considered to > > s/on// No, it's correct as-is. > > represent a super-cookie to the server, or to any entity on the path > from UA to HTTP server that can see the HOBA signature. This is > because we need to send a key identifier as part of the signature and > that will not vary for a given key. For this reason, and others, it > is strongly RECOMMENDED to only use HOBA over server-authenticated > TLS and to migrate web sites using HOBA to only use "https" URLs. > > UAs SHOULD provide users a way to manage their CPKs. Ideally, there > would be a way for a user to maintain their HOBA details for a site > while at the same time deleting other site information such as > cookies or non-HOBA HTML5 LocalStorage. However, as this is likely > to be complex and appropriate user interfaces counter intutitive, we > exepect that UAs that implement HOBA will likely treat HOBA > > s/exepect/expect/ ack > > information as just some more site data, that would disappear should > the user choose to "forget" that site. > > > > 9.6. Hobareg HTTP Header > > s/Header/Header Field/ ack > > > > 12.1. Normative References > > 12.2. Informative References > > [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data > Encodings", RFC 4648, October 2006. > > This is likely normative. sure > > [bonneau] Bonneau, , "The science of guessing: analyzing an > anonymized corpus of 70 million passwords.", Security and > Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012. , 2012. > > This reference looks broken (interpunction-wise). Tidied up. > > > Appendix A. Problems with Passwords > > ... > > Using memorizable passwords on unencrypted channels also poses risks > to the users. If a web site uses either the HTTP Plain > > s/Plain/Basic/ ? (also add ref) changed, ref is earlier > > Appendix B. Example > > > The following values show an example of HOBA-http authentication to > the origin https://example.com:443 Carriage-returns have been added > > s/443/443./ Sure, though not sure what RFC editor prefers there (for URLs at the end of sentences) but they can fix if needed. S. > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From nobody Wed Dec 24 03:31:07 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B031A86E6; Wed, 24 Dec 2014 03:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkF6Mo4dZLbC; Wed, 24 Dec 2014 03:31:04 -0800 (PST) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 16CF51A0364; Wed, 24 Dec 2014 03:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1419420658; d=isode.com; s=selector; i=@isode.com; bh=c50Kgk+7b66bRje2D7owjY0hkJEC9630hJgxxI1K/JE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=rBDQu4DPBcdYaDqrJQPLgwjBccU0EpBctcc1Lla57HrcBumHCJU2OyH1ZL+ZbXKXGO4AvL dtIswIcvnN8BZ0oO6LrnFQNDMk7PJIiPcsiMJhtGulwwYc8f0lTHfI2MIgO/AllUmUwNz8 FAx8BJ5PWa0O2JwMhlL9i3QKCkbJMjQ=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 24 Dec 2014 11:30:58 +0000 Message-ID: <549AA3BD.2010206@isode.com> Date: Wed, 24 Dec 2014 11:30:05 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 To: Stephen Farrell , drafts-lastcall@iana.org References: <20141210142247.26304.96086.idtracker@ietfa.amsl.com> <549AA031.4040302@cs.tcd.ie> In-Reply-To: <549AA031.4040302@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Xy-uVJt8iKqlVXcb8j0x6N6WZhI Cc: draft-ietf-httpauth-hoba@tools.ietf.org, "http-auth@ietf.org" , httpauth-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [http-auth] [IANA #798267] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 11:31:05 -0000 Hi Stephen, On 24/12/2014 11:14, Stephen Farrell wrote: > Hi Amanda, > > Thanks for the review - responses inline and a proto-08 > version (handling the various IETF LC comments) is at [1] > with a diff vs. 07 at [2]. I'll plan to publish that as an > official -08 in a few days if there are no comments. > > On 22/12/14 22:25, Amanda Baber via RT wrote: [...] >> Second, in the Well-Known URI registry located at: >> >> https://www.iana.org/assignments/well-known-uris/ >> >> a new well-known URI will be registered as follows: >> >> URI Suffix: hoba Change Controller: IETF Reference: Section 6 of [ >> RFC-to-be ] Related Information: [ none ] >> >> IANA Note -> As this document requests registrations in an Expert >> Review or Specification Required (see RFC 5226) registry, we will >> initiate the required Expert Review via a separate request. Expert >> review will need to be completed before your document can be approved >> for publication as an RFC. > Hmm, that's odd. I disagree with "will need to be completed" - this > is an IETF stream consensus document and the IETF LC trumps expert > review. I'll happily take comments of course when those are received > in time. Specification Required requires expert review. So the expert review is required anyway. IETF consensus can't override this, if this is how the registry is setup. (If the registry was setup as "IETF Consensus or Specification Required", that would have been a different story.) From nobody Wed Dec 24 03:37:01 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F721A9039; Wed, 24 Dec 2014 03:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7wxHgIIZ4EQ; Wed, 24 Dec 2014 03:36:54 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3ACA1A8A50; Wed, 24 Dec 2014 03:36:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AE9CEBF1D; Wed, 24 Dec 2014 11:36:52 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27mjWQlDXlbO; Wed, 24 Dec 2014 11:36:51 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.42.31.173]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6E008BF04; Wed, 24 Dec 2014 11:36:51 +0000 (GMT) Message-ID: <549AA553.2080606@cs.tcd.ie> Date: Wed, 24 Dec 2014 11:36:51 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Alexey Melnikov , drafts-lastcall@iana.org References: <20141210142247.26304.96086.idtracker@ietfa.amsl.com> <549AA031.4040302@cs.tcd.ie> <549AA3BD.2010206@isode.com> In-Reply-To: <549AA3BD.2010206@isode.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/1vmIKSDCqLMIFIFNIyHCkiPyLvA Cc: draft-ietf-httpauth-hoba@tools.ietf.org, "http-auth@ietf.org" , httpauth-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [http-auth] [IANA #798267] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 11:36:58 -0000 Hiya, On 24/12/14 11:30, Alexey Melnikov wrote: >> > Specification Required requires expert review. So the expert review is > required anyway. IETF consensus can't override this, if this is how the > registry is setup. > (If the registry was setup as "IETF Consensus or Specification > Required", that would have been a different story.) I recall the IESG discussing this before and thought we'd ended up with a different conclusion - since IETF LC can change any of the registry set ups, it basically wins was what I though we concluded. Seems odd to say that an IETF LC can change the registration rule without expert input but cannot add an entry. But whatever, I'm sure it's no big deal in this case and it's a minor process wrinkle anyway. Be good if we clarify though. (And it's quite possible this is just me mis-remembering.) S. From nobody Wed Dec 24 03:40:24 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE711A9073; Wed, 24 Dec 2014 03:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP-oXMSQfgVw; Wed, 24 Dec 2014 03:40:17 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id 15E741A9072; Wed, 24 Dec 2014 03:40:17 -0800 (PST) Received: from [192.168.2.160] (unknown [84.187.46.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id C9EA715A0424; Wed, 24 Dec 2014 12:40:15 +0100 (CET) Message-ID: <549AA61C.1010901@greenbytes.de> Date: Wed, 24 Dec 2014 12:40:12 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Stephen Farrell , ietf@ietf.org References: <20141210142247.26304.1220.idtracker@ietfa.amsl.com> <549033EE.2070302@greenbytes.de> <549AA041.1070401@cs.tcd.ie> In-Reply-To: <549AA041.1070401@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/NzK1s_8Xkq_8EFAeuBZRs7Unagk Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 11:40:20 -0000 On 2014-12-24 12:15, Stephen Farrell wrote: > ... >> 2. The HOBA Authentication Scheme >> >> HOBA-TBS = len ":" nonce >> len ":" alg >> len ":" origin >> len ":" [ realm ] >> len ":" kid >> len ":" challenge >> len = 1*DIGIT >> nonce = 1*base64urlchars >> alg = 1*2DIGIT >> origin = scheme "://" authority ":" port >> realm = unreserved >> kid = 1*base64urlchars >> challenge = 1*base64urlchars >> ; Characters for Base64URL encoding from Table 2 of RFC 4648 >> base64urlchars = %x30-39 ; Digits >> / %x41-5A ; Uppercase letters >> / %x61-7A ; Lowercase letters >> / "-" / "_" / "=" ; Special characters >> >> Figure 1: To-be-signed data for HOBA >> >> ...specify a proper ABNF production for "unreserved". > > What? I don't know what you mean there. I added a pointer to > 2.2 of RFC 7235 though, is that enough? What's the ABNF for "unreserved"? >> ... >> >> The registration message for HOBA-http is sent as a POST message to >> the URL ".well-known/hoba/register" with an HTML form (x-www-form- >> encoded) described below; The registration message for HOBA-js can be >> >> Need citation for payload format. > > To RFC 1867? Added that (though it's been obsoleted). Happy to > replace with a better ref so long as that better ref is not a > work-in-progress:-) I assume. > ... >> when the registration has succeded to indicate the new state. The >> header to be used is "Hobareg" and the value when registration has >> succeeded is to be "regok". When registration is inwork (e.g. on an >> HTTP response for an interstitial page) the server MAY add this >> header with a value of "reginwork". See Section 9.6 for the relevant >> IANA registration of this header field. >> >> Could this use the Authentication-Info header field currently defined in >> DIGEST? > > Maybe but would prefer to not entwine with DIGEST in that way. > Seems like all we'd get is delay and no benefit. ...that supports my p.o.v. that it should be in a separate spec :-) > ... >> 6.3. Logging Out >> >> >> The user can tell the server it wishes to log out. With HOBA-http, >> this is done by sending any HOBA-authenticated HTTP message to the >> URL ".well-known/hoba/logout" on the site in question. The UA SHOULD >> also delete session cookies associated with the session so that the >> user's state is no longer "logged in." >> >> Nope. Don't define this for GET (or any "safe" method). POST would work. > > Sorry I'm not seeing why that is GET specific? I agree POST should be > fine too, but think that is allowed by the above. GET is defined as safe, and safe is defined as: "Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server." -- So you can't have GET perform a logout. > ... >> Appendix B. Example >> >> >> The following values show an example of HOBA-http authentication to >> the origin https://example.com:443 Carriage-returns have been added >> >> s/443/443./ > > Sure, though not sure what RFC editor prefers there (for URLs at > the end of sentences) but they can fix if needed. In doubt, put it the URI in delimiters... Best regards, Julian From nobody Wed Dec 24 04:52:47 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D661A9232 for ; Wed, 24 Dec 2014 04:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tMXUeBkKk9W for ; Wed, 24 Dec 2014 04:52:44 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3931A9176 for ; Wed, 24 Dec 2014 04:52:44 -0800 (PST) Received: from [192.168.2.160] ([84.187.46.235]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lk81O-1XRgaO0SwE-00c9h6; Wed, 24 Dec 2014 13:52:42 +0100 Message-ID: <549AB711.30006@gmx.de> Date: Wed, 24 Dec 2014 13:52:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?windows-1252?Q?Michael_K=F6ller?= , http-auth@ietf.org References: <42CB92A9-7342-401B-9005-BE5D1FDACC09@greenbytes.de> In-Reply-To: <42CB92A9-7342-401B-9005-BE5D1FDACC09@greenbytes.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:QF7PPheafpx+8uHnvdL55e9evIkhcFfx9Q0NoVjEZes0XQSPBH7 Z/bR13Ttwn07RkFIh+Hc1KAV5aAOM/z0/QYnFbMOfSsJeSC56ZkLO/l2IlLgUYPw3KcPu0Q tPHhxGcuN67zGEpkVgW86IxX6AxzkPHId6JmX3XScWzEHh+eFYnE6BhyFpf1kX/mjvdbdNN psh3nGxOHDzxVKJPMOANw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/3_HgMHvjx91AKWflEQElEElF6kk Subject: Re: [http-auth] Last Call review: Basic Authentication Scheme X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 12:52:45 -0000 On 2014-12-22 14:47, Michael Köller wrote: > Hi, > > Today Julian asked me to review the Basic authentication Last Call draft. > Apologies if my remarks may already have been discussed on this list. I just subscribed today for the purpose of this mail, so I’m most probably not up to date with current discussion not yet reflected in the document. > > There’s one sentence that might qualify as a bug? Chapter 2.2 defines the term ‚authentication scope‘. It reads: >> Given the absolute URI ([RFC3986], Section 4.3) of an authenticated request, the authentication scope of that request is obtained by removing all characters after the last slash ("/") character. > I assume this definition fails to address slashes within the query part of the URI. So the authorization scope should be obtained by removing all characters after the last slash in the path of the absolute request URI. > ... Good catch, Michael. How about: > Given the absolute URI ([RFC3986], Section 4.3) of an authenticated > request, the authentication scope of that request is obtained by > removing all characters after the last slash ("/") character of the > path component ("hier_part", see [RFC3986], Section 3). A client > SHOULD assume that resources identified by URIs with a prefix-match > of the authentication scope are also within the protection space > specified by the realm value of the that authenticated request. Best regards, Julian From nobody Wed Dec 24 05:13:02 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA881AD02F; Wed, 24 Dec 2014 05:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC1-hIKMIb4Y; Wed, 24 Dec 2014 05:12:54 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0651ACDB6; Wed, 24 Dec 2014 05:12:54 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 4CCF3DA03C9; Wed, 24 Dec 2014 13:12:24 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2165A53E086; Wed, 24 Dec 2014 05:12:24 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 24 Dec 2014 05:12:18 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <549AA553.2080606@cs.tcd.ie> Date: Wed, 24 Dec 2014 08:12:03 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20141210142247.26304.96086.idtracker@ietfa.amsl.com> <549AA031.4040302@cs.tcd.ie> <549AA3BD.2010206@isode.com> <549AA553.2080606@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/gmTJQWgPChmwKzCavIsKpn-fCZY Cc: httpauth-chairs@tools.ietf.org, drafts-lastcall@iana.org, "http-auth@ietf.org" , iesg@ietf.org, draft-ietf-httpauth-hoba@tools.ietf.org Subject: Re: [http-auth] [IANA #798267] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 13:12:56 -0000 On Dec 24, 2014, at 6:36 AM, Stephen Farrell = wrote: > I recall the IESG discussing this before and thought we'd ended > up with a different conclusion - since IETF LC can change any of > the registry set ups, it basically wins was what I though we > concluded. Seems odd to say that an IETF LC can change the > registration rule without expert input but cannot add an entry. Most IETF consensus calls are silently ignored. A document that = changes a registry is likely to get more notice, at least if someone is = paying attention. So all IETF last calls are not equal, in practice if = not in principle. I wish it were not so. The expert review serves as a backstop: e.g., RFC 3315 requires expert = review because we occasionally get some working group that accidentally = changes the DHCP protocol in the process of adding a DHCP option = (probably happens with RADIUS and other similar protocols as well). At = least one document with a problem like this got to AUTH48 before anyone = who had DHCP fu noticed. Expert review is way late for catching = mistakes like this, but it's better than AUTH48 or post-publication (we = have one of those too). From nobody Wed Dec 24 05:41:47 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A4E1A88D3 for ; Mon, 22 Dec 2014 15:06:43 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wle_sA9Q00UP; Mon, 22 Dec 2014 15:06:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE261A1B80; Mon, 22 Dec 2014 15:06:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141222230642.5370.94237.idtracker@ietfa.amsl.com> Date: Mon, 22 Dec 2014 15:06:42 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/056FB5h4Tt5Lg6rTkgvZl1GWxnM X-Mailman-Approved-At: Wed, 24 Dec 2014 05:41:45 -0800 Subject: [http-auth] ID Tracker State Update Notice: X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 23:06:44 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ From nobody Wed Dec 24 05:41:49 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D98C1AD02C; Wed, 24 Dec 2014 05:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TzaM65N86Z0; Wed, 24 Dec 2014 05:33:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFE91A8A8A; Wed, 24 Dec 2014 05:33:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: http-auth@ietf.org, iesg-secretary@ietf.org, iesg@ietf.org, "Yoav Nir" , draft-ietf-httpauth-hoba.all@tools.ietf.org, httpauth-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141224133333.21985.81295.idtracker@ietfa.amsl.com> Date: Wed, 24 Dec 2014 05:33:33 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/lqBE1KTVpX6_dcfbMDQeunV_VLE X-Mailman-Approved-At: Wed, 24 Dec 2014 05:41:45 -0800 Subject: [http-auth] Telechat update notice: X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 13:33:34 -0000 Placed on agenda for telechat - 2015-01-08 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ From nobody Wed Dec 24 05:42:40 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C2D1A8A8A; Wed, 24 Dec 2014 05:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcM-Nixgpbo0; Wed, 24 Dec 2014 05:42:37 -0800 (PST) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id C36321A8AB9; Wed, 24 Dec 2014 05:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1419428556; d=isode.com; s=selector; i=@isode.com; bh=fheBX7S7eK89hU24AJvLXjc1M2mDcnbIIDs/UKy4VVo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=n6ratv2bL+BS9gBNTALbYeosGQZJT0O+jq8ayOACBbQCgUiZTtkjDGvdaSnCRnjh6XYUBZ WzTWg+Khd9eSbfjwqJwQr4KAwzwsH1BwhEk+pIod7nkPheJLnnK+IaBI94KiZLEfcjzbbM Ap7zWonpXzBUIOSm/lIUCwmewQIAPSc=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 24 Dec 2014 13:42:35 +0000 Message-ID: <549AC294.5030306@isode.com> Date: Wed, 24 Dec 2014 13:41:40 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 To: Stephen Farrell , drafts-lastcall@iana.org References: <20141210142247.26304.96086.idtracker@ietfa.amsl.com> <549AA031.4040302@cs.tcd.ie> <549AA3BD.2010206@isode.com> <549AA553.2080606@cs.tcd.ie> In-Reply-To: <549AA553.2080606@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/XhKY0zvGK54JIAcnallE1tLZuxA Cc: draft-ietf-httpauth-hoba@tools.ietf.org, "http-auth@ietf.org" , httpauth-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [http-auth] [IANA #798267] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 13:42:38 -0000 On 24/12/2014 11:36, Stephen Farrell wrote: > Hiya, > > On 24/12/14 11:30, Alexey Melnikov wrote: >> Specification Required requires expert review. So the expert review is >> required anyway. IETF consensus can't override this, if this is how the >> registry is setup. >> (If the registry was setup as "IETF Consensus or Specification >> Required", that would have been a different story.) > I recall the IESG discussing this before and thought we'd ended > up with a different conclusion - since IETF LC can change any of > the registry set ups, it basically wins was what I though we > concluded. Seems odd to say that an IETF LC can change the > registration rule without expert input but cannot add an entry. RFC 5226 is being updated and if this is true, then it is not clear on that, I think. I think IESG can override any registry policies, but I don't think that is the procedure that you are trying to invoke. Anyway, I've done with my IANA registry nitpicking job ;-). > But whatever, I'm sure it's no big deal in this case and it's > a minor process wrinkle anyway. Be good if we clarify though. Agreed. > (And it's quite possible this is just me mis-remembering.) From nobody Wed Dec 24 05:45:26 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B611A8AB7; Wed, 24 Dec 2014 05:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmNyWDi-I22U; Wed, 24 Dec 2014 05:45:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4D81A8A8A; Wed, 24 Dec 2014 05:45:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 716D0BF09; Wed, 24 Dec 2014 13:45:19 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Omq-i7qHSbHE; Wed, 24 Dec 2014 13:45:17 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.42.31.173]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9A1B7BF20; Wed, 24 Dec 2014 13:45:17 +0000 (GMT) Message-ID: <549AC36D.9050205@cs.tcd.ie> Date: Wed, 24 Dec 2014 13:45:17 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , ietf@ietf.org References: <20141210142247.26304.1220.idtracker@ietfa.amsl.com> <549033EE.2070302@greenbytes.de> <549AA041.1070401@cs.tcd.ie> <549AA61C.1010901@greenbytes.de> In-Reply-To: <549AA61C.1010901@greenbytes.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/I7QjFRP-o9yhD9Cye_N-tjtjkjA Cc: http-auth@ietf.org Subject: Re: [http-auth] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 13:45:24 -0000 Hiya, Thanks for the follow up... On 24/12/14 11:40, Julian Reschke wrote: > On 2014-12-24 12:15, Stephen Farrell wrote: >> ... >>> 2. The HOBA Authentication Scheme >>> >>> HOBA-TBS = len ":" nonce >>> len ":" alg >>> len ":" origin >>> len ":" [ realm ] >>> len ":" kid >>> len ":" challenge >>> len = 1*DIGIT >>> nonce = 1*base64urlchars >>> alg = 1*2DIGIT >>> origin = scheme "://" authority ":" port >>> realm = unreserved >>> kid = 1*base64urlchars >>> challenge = 1*base64urlchars >>> ; Characters for Base64URL encoding from Table 2 of RFC 4648 >>> base64urlchars = %x30-39 ; Digits >>> / %x41-5A ; Uppercase letters >>> / %x61-7A ; Lowercase letters >>> / "-" / "_" / "=" ; Special characters >>> >>> Figure 1: To-be-signed data for HOBA >>> >>> ...specify a proper ABNF production for "unreserved". >> >> What? I don't know what you mean there. I added a pointer to >> 2.2 of RFC 7235 though, is that enough? > > What's the ABNF for "unreserved"? See p18 of RFC 3986. I (sadly) added yet another comment around the already overloaded abnf there. (Sadly, because I think we're now documenting this assuming all developers are dim, which if sad if correct, and sad if incorrect;-) > >>> ... >>> >>> The registration message for HOBA-http is sent as a POST message to >>> the URL ".well-known/hoba/register" with an HTML form (x-www-form- >>> encoded) described below; The registration message for HOBA-js >>> can be >>> >>> Need citation for payload format. >> >> To RFC 1867? Added that (though it's been obsoleted). Happy to >> replace with a better ref so long as that better ref is not a >> work-in-progress:-) > > > I assume. Lovely. > >> ... >>> when the registration has succeded to indicate the new state. The >>> header to be used is "Hobareg" and the value when registration has >>> succeeded is to be "regok". When registration is inwork (e.g. on an >>> HTTP response for an interstitial page) the server MAY add this >>> header with a value of "reginwork". See Section 9.6 for the >>> relevant >>> IANA registration of this header field. >>> >>> Could this use the Authentication-Info header field currently defined in >>> DIGEST? >> >> Maybe but would prefer to not entwine with DIGEST in that way. >> Seems like all we'd get is delay and no benefit. > > ...that supports my p.o.v. that it should be in a separate spec :-) Sure. And when it is and if HOBA is put on the standards-track those can be better aligned if that's seen as useful. > >> ... >>> 6.3. Logging Out >>> >>> >>> The user can tell the server it wishes to log out. With HOBA-http, >>> this is done by sending any HOBA-authenticated HTTP message to the >>> URL ".well-known/hoba/logout" on the site in question. The UA >>> SHOULD >>> also delete session cookies associated with the session so that the >>> user's state is no longer "logged in." >>> >>> Nope. Don't define this for GET (or any "safe" method). POST would work. >> >> Sorry I'm not seeing why that is GET specific? I agree POST should be >> fine too, but think that is allowed by the above. > > GET is defined as safe, Ah sorry, I mis-read your comment. You're right. Luckily, that's what the code I've seen does anyway:-) But that's a good catch. > and safe is defined as: > > "Request methods are considered "safe" if their defined semantics are > essentially read-only; i.e., the client does not request, and does not > expect, any state change on the origin server as a result of applying a > safe method to a target resource. Likewise, reasonable use of a safe > method is not expected to cause any harm, loss of property, or unusual > burden on the origin server." -- > > > > So you can't have GET perform a logout. Changed that to say use POST. > >> ... >>> Appendix B. Example >>> >>> >>> The following values show an example of HOBA-http authentication to >>> the origin https://example.com:443 Carriage-returns have been added >>> >>> s/443/443./ >> >> Sure, though not sure what RFC editor prefers there (for URLs at >> the end of sentences) but they can fix if needed. > > In doubt, put it the URI in delimiters... Or... If in doubt, wait and see what RFC editor prefers:-) The above changes applied as before at [1,2]. If there's no more follow up, I'll publish that in a couple of days. Cheers, S. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-07.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt > > Best regards, Julian From nobody Wed Dec 24 08:16:24 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CE41A8A8B; Wed, 24 Dec 2014 08:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myvDxta2UWW8; Wed, 24 Dec 2014 08:16:20 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F471A8A89; Wed, 24 Dec 2014 08:16:18 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id u10so6846320lbd.6; Wed, 24 Dec 2014 08:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5zsnJcg/Dnze9fGDhyLqQaf+sVFavxS+DIlaExYbhJ0=; b=XEe40fKlKIXtvLoq5FCzpLeJypNpAFpGSHd9azGy8QjZa1GzdBViiCWaCEIzWlJtSd SL/eDI89JwN9w2tQbxTnFU5Ofhfz9cz04S+p8POMABmgApxSKxXKHKMXxciVTUlpD+Sz 6KqyM/DT1oPXE6MESfGqE91GC2TgxjWsALmEaLWbgT6zskmQ8qS19TidVuKFekBGkFHg B1uhu9suKpojPGIhftD/F2UMBS1+FN7rtwn6lS16Vi+OVe6SqBvcIe/VOKUDlQI/DLqi lGrunFNjmF1RvTOuZPFFEaD12wnYql8GSxhjsEDBX0k/dUXLmkaNVYf/G6n43/VaGFGh EwXA== MIME-Version: 1.0 X-Received: by 10.112.101.100 with SMTP id ff4mr34459355lbb.94.1419437777503; Wed, 24 Dec 2014 08:16:17 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Wed, 24 Dec 2014 08:16:17 -0800 (PST) In-Reply-To: <549AA553.2080606@cs.tcd.ie> References: <20141210142247.26304.96086.idtracker@ietfa.amsl.com> <549AA031.4040302@cs.tcd.ie> <549AA3BD.2010206@isode.com> <549AA553.2080606@cs.tcd.ie> Date: Wed, 24 Dec 2014 11:16:17 -0500 X-Google-Sender-Auth: tmebkMnQYxW7LsmYupdACfFObEI Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/pHHMakxLULUQszoOyhYifDDW_kc Cc: httpauth-chairs@tools.ietf.org, Pearl Liang via RT , "http-auth@ietf.org" , IESG , draft-ietf-httpauth-hoba@tools.ietf.org Subject: Re: [http-auth] [IANA #798267] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 16:16:21 -0000 > I recall the IESG discussing this before and thought we'd ended > up with a different conclusion We did not. Some registries (ports, media types) are set up so that IETF consensus documents do not need expert review. But if the registry is not set up that way, the expert does get involved. The IESG can always explicitly override that, but IETF consensus does not. If someone should want to submit a document to change the registration policy to exempt registrations made from IETF consensus documents from expert review, someone certainly could do that. Barry From nobody Wed Dec 24 09:04:48 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6E61A07BE; Wed, 24 Dec 2014 09:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5PGGC50GjuH; Wed, 24 Dec 2014 09:04:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82E31A079A; Wed, 24 Dec 2014 09:04:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D5B01BF0E; Wed, 24 Dec 2014 17:04:42 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpdU1Z0wIy_u; Wed, 24 Dec 2014 17:04:41 +0000 (GMT) Received: from [127.0.0.1] (unknown [86.42.31.173]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BB0BBBF09; Wed, 24 Dec 2014 17:04:41 +0000 (GMT) X-Priority: 3 To: barryleiba@computer.org From: stephen.farrell@cs.tcd.ie In-Reply-To: References: <20141210142247.26304.96086.idtracker@ietfa.amsl.com> <549AA031.4040302@cs.tcd.ie> <549AA3BD.2010206@isode.com> <549AA553.2080606@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Wed, 24 Dec 2014 17:04:39 +0000 Message-ID: MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/MThICbGk9ZNtqMtXysqXjao5ylI Cc: httpauth-chairs@tools.ietf.org, drafts-lastcall@iana.org, http-auth@ietf.org, iesg@ietf.org, draft-ietf-httpauth-hoba@tools.ietf.org Subject: Re: [http-auth] [IANA #798267] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 17:04:46 -0000 DQoNCk9uIFdlZCBEZWMgMjQgMTY6MTY6MTcgMjAxNCBHTVQsIEJhcnJ5IExlaWJhIHdyb3RlOg0K PiA+IEkgcmVjYWxsIHRoZSBJRVNHIGRpc2N1c3NpbmcgdGhpcyBiZWZvcmUgYW5kIHRob3VnaHQg d2UnZCBlbmRlZA0KPiA+IHVwIHdpdGggYSBkaWZmZXJlbnQgY29uY2x1c2lvbg0KPiANCj4gV2Ug ZGlkIG5vdC4gIFNvbWUgcmVnaXN0cmllcyAocG9ydHMsIG1lZGlhIHR5cGVzKSBhcmUgc2V0IHVw IHNvIHRoYXQNCj4gSUVURiBjb25zZW5zdXMgZG9jdW1lbnRzIGRvIG5vdCBuZWVkIGV4cGVydCBy ZXZpZXcuICBCdXQgaWYgdGhlDQo+IHJlZ2lzdHJ5IGlzIG5vdCBzZXQgdXAgdGhhdCB3YXksIHRo ZSBleHBlcnQgZG9lcyBnZXQgaW52b2x2ZWQuICBUaGUNCj4gSUVTRyBjYW4gYWx3YXlzIGV4cGxp Y2l0bHkgb3ZlcnJpZGUgdGhhdCwgYnV0IElFVEYgY29uc2Vuc3VzIGRvZXMgbm90Lg0KPiANCj4g SWYgc29tZW9uZSBzaG91bGQgd2FudCB0byBzdWJtaXQgYSBkb2N1bWVudCB0byBjaGFuZ2UgdGhl IHJlZ2lzdHJhdGlvbg0KPiBwb2xpY3kgdG8gZXhlbXB0IHJlZ2lzdHJhdGlvbnMgbWFkZSBmcm9t IElFVEYgY29uc2Vuc3VzIGRvY3VtZW50cyBmcm9tDQo+IGV4cGVydCByZXZpZXcsIHNvbWVvbmUg Y2VydGFpbmx5IGNvdWxkIGRvIHRoYXQuDQoNCldvdWxkbid0IHRoYXQgYmUgcGFydCBvZiA1MjI2 YmlzIGlmIGl0IHdlcmUgd2hhdCB3ZSB3YW50ZWQ/DQoNCkFzIHRvIHRoZSAobWlub3IpIHN1YnN0 YW5jZSBoZXJlIEknZCBzdWdnZXN0IHRoYXQgZXhwZXJ0cyBiZSBjb25zdWx0ZWQgYnV0IG5vbiBi bG9ja2luZyBmb3IgaWV0ZiBjb25zZW5zdXMgZG9jcyBJIHRoaW5rLiBBZGRpbmcgdW5leHBlY3Rl ZCB0d2lzdHMgbGlrZSB0aGlzIGF0IHRoZSBlbmQgb2YgdGhlIHByb2Nlc3MgaXMgYmFkIGluIGdl bmVyYWwgKHRob3VnaCBub3QgYSBwcm9ibGVtIGluIHRoaXMgY2FzZSkgDQoNClMNCg0KPiANCj4g QmFycnkNCj4= From nobody Wed Dec 24 09:49:50 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7781A19F2; Wed, 24 Dec 2014 09:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzR0k7YoMw4e; Wed, 24 Dec 2014 09:49:45 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F4D1A0A85; Wed, 24 Dec 2014 09:49:45 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gm9so7421376lab.12; Wed, 24 Dec 2014 09:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mb0/JAuIUOg/7ShXKdgIlnHMgqbSPApXfVEWdy55/fc=; b=qy0kV2koQg27Oj7smDDNM6dnrIaKw9C+ghUQNUYM5//dRHUW2xzZAdZwYkK+6AQ+lv kcoAGVcrRL7T3OpweMm4NLhblZ5lpVw257yCEW4SueYas5xdVm6K58/bMbWademmoeZf j1+E+fGGP1+ppRePPdozI7DMbKl4I+x4+PBNRXmtpNkOXTDvOXdlQWlt+QBzbLqfHKq9 i3zMDsO+e913l2W0Z9Vofi0Rh1M7YvJ84j4LsHqaq70r5cexDTnIF0RaiSFXEWyttP/g 0jlGXM+fcIVwX+j44nocc0sVbApGtIvY4uO8662dhSJ+zH4+DTlJnq8uPmIK1wSmpQ1Y CYVw== MIME-Version: 1.0 X-Received: by 10.152.27.130 with SMTP id t2mr34395073lag.28.1419443383473; Wed, 24 Dec 2014 09:49:43 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Wed, 24 Dec 2014 09:49:43 -0800 (PST) In-Reply-To: References: <20141210142247.26304.96086.idtracker@ietfa.amsl.com> <549AA031.4040302@cs.tcd.ie> <549AA3BD.2010206@isode.com> <549AA553.2080606@cs.tcd.ie> Date: Wed, 24 Dec 2014 12:49:43 -0500 X-Google-Sender-Auth: CsUekQzRUnP18X3eDofBtGx2Vdg Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/ugD6Ro80UrMAn96bcFZ-xudlLhs Cc: httpauth-chairs@tools.ietf.org, Pearl Liang via RT , "http-auth@ietf.org" , IESG , draft-ietf-httpauth-hoba@tools.ietf.org Subject: Re: [http-auth] [IANA #798267] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 17:49:46 -0000 >> If someone should want to submit a document to change the registration >> policy to exempt registrations made from IETF consensus documents from >> expert review, someone certainly could do that. > > Wouldn't that be part of 5226bis if it were what we wanted? Perhaps, but it's clearly not what we want, in general (see below). And 5226bis does suggest using combinations of policies to handle this, combinations such as "IETF Review or Expert Review" (see Section 2.3.2). > As to the (minor) substance here I'd suggest that experts be consulted > but non blocking for ietf consensus docs I think. Adding unexpected > twists like this at the end of the process is bad in general This is not an unexpected twist: anyone looking at the registration policy can clearly see that it requires expert review, and nothing indicates an exception for IETF consensus documents. Further, as to your first sentence (and my "see below" above), I have pushed back, in IESG Evaluation, on expert review policies, asking if they wanted to make an exception for IETF consensus documents. In every case where I pushed back, they did *not*. They always wanted to get the designated experts involved to make sure things looked right. This actually makes sense, because in many cases it's possible -- even likely -- that registrations will be requested by authors, working groups, or other sub-communities who are not experts in the ins and outs of the particular registry involved, and the creators of the registry want to make sure that someone who *is* gives the registration request at least a once-over. Barry From nobody Wed Dec 24 10:40:46 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DDD1A1A3B; Wed, 24 Dec 2014 10:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnY_Jxaa-bLL; Wed, 24 Dec 2014 10:40:36 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E30F1A1A22; Wed, 24 Dec 2014 10:40:35 -0800 (PST) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBOIeSLr021166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Dec 2014 13:40:28 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com sBOIeSLr021166 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1419446430; bh=8OKt29X+zCEoS3ejRulyeC/+GU0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Q64PMC3AQ4k/ws7Jiq4N4xOSpzRgyuvHuvLq3OvLVGLFFDU/MgcN7JeyRSOKGIbBo j3sBRhehs4U920LXIWHte0hPP/8FNDhTNKHnwSyryapHnKQZzvAXsxgMEKDDqu3dEb FPzW0fVi9xUUXcXhJSeAGSNYOKa2APQm3KsGZqTc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com sBOIeSLr021166 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd03.lss.emc.com (RSA Interceptor); Wed, 24 Dec 2014 13:40:02 -0500 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBOIeCKk022420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Dec 2014 13:40:12 -0500 Received: from MXHUB210.corp.emc.com (10.253.68.36) by mxhub24.corp.emc.com (128.222.70.136) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 24 Dec 2014 13:40:11 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB210.corp.emc.com ([10.253.68.36]) with mapi id 14.03.0195.001; Wed, 24 Dec 2014 13:40:11 -0500 From: "Black, David" To: Stephen Farrell , "paul.hoffman@vpnc.org" , "mike@phresheez.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 Thread-Index: AdAYvlv0aser5OsbSxuh2NmwD9vCCwG1mzwAAAMHcGA= Date: Wed, 24 Dec 2014 18:40:11 +0000 Message-ID: References: <549AA03C.5070107@cs.tcd.ie> In-Reply-To: <549AA03C.5070107@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.41.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/yJxxkaD-iuEI3j9kgCp-CoRznas Cc: "Black, David" , "http-auth@ietf.org" , "ietf@ietf.org" Subject: Re: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 18:40:42 -0000 SGkgU3RlcGhlbiwNCg0KVGhhbmtzIGZvciB0aGUgcmVzcG9uc2UgYW5kIGluaXRpYWwgdXBkYXRl cyAtIGFueXRoaW5nIHRoYXQgSSBkb24ndCBjb21tZW50DQpvbiBmdXJ0aGVyIGlzIGZpbmUsIGFu ZCBldmVyeXRoaW5nIGluIHRoaXMgcmVzcG9uc2Ugc2hvdWxkIG5vdyBiZSByZWR1Y2VkIHRvDQpy ZXF1ZXN0cyBmb3IgbWlub3IgYWRkaXRpb25hbCB0ZXh0IGNoYW5nZXM6DQoNCj4gPiBbMl0gQ2hh bGxlbmdlIHZlcmlmaWNhdGlvbiBhbmQgcmV1c2UNCj4gPg0KPiA+IFRoaXMgc2VudGVuY2Ugb24g cC42IHN0cmlrZXMgbWUgYXMgc3VidGx5IGRhbmdlcm91czoNCj4gPg0KPiA+ICAgIFRoZSBjaGFs bGVuZ2UgaG93ZXZlciBpcyBzZW50IG92ZXINCj4gPiAgICB0aGUgbmV0d29yayBzbyBhcyB0byBt YWtlIGl0IHNpbXBsZXIgZm9yIGEgc2VydmVyIHRvIGJlIHN0YXRlbGVzcy4NCj4gPiAgICAoT25l IGZvcm0gb2Ygc3RhdGVsZXNzIGNoYWxsZW5nZSBtaWdodCBiZSBhIGNpcGhlcnRleHQgdGhhdCB0 aGUNCj4gPiAgICBzZXJ2ZXIgZGVjcnlwdHMgYW5kIGNoZWNrcywgYnV0IHRoYXQgaXMgYW4gaW1w bGVtZW50YXRpb24gZGV0YWlsLikNCj4gPg0KPiA+IFRoZSBkcmFmdCBlbHNld2hlcmUgYXNzZXJ0 cyBvciBhc3N1bWVzIHRoYXQgY2hhbGxlbmdlIHJldXNlIGNhbiBiZQ0KPiA+IHByZXZlbnRlZCBi eSB0aGUgc2VydmVyIG9yIGJlIHRpbWUtYm91bmRlZCBieSBtYXgtYWdlLCBhbmQgcmVsaWVzIG9u DQo+ID4gdGhvc2UgcmV1c2UgbGltaXRzIGZvciBzZWN1cml0eSBwcm9wZXJ0aWVzLA0KDQpbLi4u IHNuaXAgLi4uXQ0KDQo+IEhtbS4gSSB0aGluayB0aGF0IEhPQkEgb3VnaHQgbm90IFJFUVVJUkUg ZnVsbCByZXBsYXkgcHJvdGVjdGlvbg0KPiBpbiBhbGwgY2FzZXMsIHRoYXQgaXMsIGl0IFNIT1VM RCBiZSBwb3NzaWJsZSB0byBkZXBsb3kgYSBzZXJ2ZXINCj4gdGhhdCBpcyB2dWxuZXJhYmxlIHRv IHNvbWUgcmVwbGF5LiBUaGUgcmVhc29uIGlzIHRoYXQgd2UncmUgdHJ5aW5nDQo+IHRvIGRpc3Bs YWNlIHBhc3N3b3JkcyBoZXJlIGFuZCBJIGJlbGlldmUgKHdpdGhvdXQgbXVjaCBoYXJkIGV2aWRl bmNlDQo+IEknbGwgZ3JhbnQgeW91KSB0aGF0IHdlJ2QgbG9zZSBzb21lIGRlcGxveW1lbnQgY2hh bmNlcyBpZiB3ZSB3ZXJlDQo+IHRvIGluc2lzdCBvbiBldmVyeSBzaW5nbGUgY2hhbGxlbmdlIGJl aW5nIGZyZXNoLg0KPiANCj4gU28gSSdkIGFyZ3VlIGZvciBuby1jaGFuZ2UgaGVyZSwgYnV0IHdv dWxkIHdlbGNvbWUgZnVydGhlciBkaXNjdXNzaW9uDQo+IGV2aWRlbmNlIG9yIHN1Z2dlc3Rpb25z IGZvciB0ZXh0IHRoYXQncyBub3QgZ29pbmcgdG8gYmUgc28gb25lcm91cw0KPiBhcyB0byB3ZWFr ZW4gb3VyIGNoYW5jZXMgb2YgZ2V0dGluZyB0aGlzIGRlcGxveWVkLg0KDQpUaGUgd29yZCAic3Rh dGVsZXNzIiBpcyBib3RoZXJpbmcgbWUsIGFzIGRvaW5nIGEgZ29vZCBqb2Igb2YgcmVwbGF5DQpw cmV2ZW50aW9uIHVzdWFsbHkgcmVxdWlyZXMgc2F2aW5nIHN0YXRlIHRvIHJlbWVtYmVyIHdoYXQg aGFzIGFscmVhZHkNCmJlZW4gc2Vlbi4gIFRoZSBmb2xsb3dpbmcgY2hhbmdlIHdvdWxkIGFkZHJl c3MgdGhpcyBjb25jZXJuOg0KDQpPTEQNCiAgIFRoZSBjaGFsbGVuZ2UgaG93ZXZlciBpcyBzZW50 IG92ZXINCiAgIHRoZSBuZXR3b3JrIHNvIGFzIHRvIG1ha2UgaXQgc2ltcGxlciBmb3IgYSBzZXJ2 ZXIgdG8gYmUgc3RhdGVsZXNzLg0KTkVXDQogICBUaGUgY2hhbGxlbmdlIGhvd2V2ZXIgaXMgc2Vu dCBvdmVyDQogICB0aGUgbmV0d29yayBzbyBhcyB0byByZWR1Y2UgdGhlIGFtb3VudCBvZiBzdGF0 ZSB0aGF0IG5lZWRzIHRvIGJlDQogICBtYWludGFpbmVkIGJ5IHNlcnZlcnMuDQoNClRoZSByZXN0 IG9mIHRoZSB0ZXh0IG9uIHJlcGxheSwgaW5jbHVkaW5nIGFsbG93aW5nIHNvbWUgcmVwbGF5IChl LmcuLA0Kd2l0aGluIG1heC1hZ2UpIGlzIGZpbmUgdy9tZS4NCg0KPiA+IFs0XSBUTFMgcmVxdWly ZW1lbnQgbGV2ZWwNCj4gPg0KPiA+IFRMUyBpcyBvbmx5IGEgIlNIT1VMRCIgcmVxdWlyZW1lbnQg Zm9yIEhPQkEsIG5vdCBhICJNVVNUIiByZXF1aXJlbWVudCAtDQo+ID4gZmlyc3QgcGFyYWdyYXBo IGluIFNlY3Rpb24gOC4xIChQcml2YWN5IENvbnNpZGVyYXRpb25zKS4NCj4NCj4gPiBJZiBUTFMg aXMgbm90IGEgIk1VU1QiIHJlcXVpcmVtZW50LCBhdCBsZWFzdCBhIGRpc2N1c3Npb24gb2YgbWFu LWluLXRoZS0NCj4gPiBtaWRkbGUgKE1JVE0pIGF0dGFja3Mgc2VlbXMgdG8gYmUgaW4gb3JkZXIu ICBUaGVyZSdzIG5vIG5lZWQgZm9yIGFuPiBleHRlbnNpdmUNCj4gPiBkaXNjdXNzaW9uIG9mIGFs bCBvZiB0aGUgc2VjdXJpdHkgcHJvcGVydGllcyBvZiBUTFMsIGJ1dCBNSVRNIGF0dGFja3MgYXJl DQo+ID4gZGVmaW5pdGVseSB3b3J0aCBhIG1lbnRpb24sIGFuZCB0aGF0IGNvdWxkIGJlIGNvbXBs ZW1lbnRlZCBieSBhIHBvaW50ZXIgdG8NCj4gPiBzdWl0YWJsZSBIVFRQL1RMUyBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyB0ZXh0IGVsc2V3aGVyZS4NCj4gDQo+IEkgdGhpbmsgdGhhdCdzIGNvdmVy ZWQgd2hlcmUgd2Ugbm90ZSB0aGUgcG90ZW50aWFsIGZvciByZXBsYXksIHdoaWNoDQo+IGlzIHdo YXQgYSBNaXRNIHdvdWxkL2NvdWxkIGRvIGluIHRoaXMgY2FzZS4gVGhhdCBpcyBub3RlZCBpbiBi b3RoDQo+IHNlY3Rpb24gMyBhbmQgaW4gNi4xIGFuZCBpbiBzZWN0aW9uIDguIEkgdGhpbmsgd2Ug aGF2ZSBpdCBjb3ZlcmVkIHRvDQo+IGJlIGhvbmVzdC4NCg0KT2ssIGluIGxvb2tpbmcgZnVydGhl ciBhdCB0aGUgdGV4dCBvbiBUTFMsIEkgc3VnZ2VzdCBjbGFyaWZ5aW5nIHRoZSBsYXN0DQpzZW50 ZW5jZSBpbiB0aGlzIHRleHQgaW4gc2VjdGlvbiAxOg0KDQogICBIT0JBIHNlc3Npb24gbWFuYWdl bWVudCBpcyBpZGVudGljYWwgdG8gdXNlcm5hbWUvcGFzc3dvcmQgc2Vzc2lvbg0KICAgbWFuYWdl bWVudCwgd2l0aCBhIHNlcnZlci1zaWRlIHNlc3Npb24gbWFuYWdlbWVudCB0b29sIG9yIHNjcmlw dA0KICAgaW5zZXJ0aW5nIGEgc2Vzc2lvbiBjb29raWUgW1JGQzYyNjVdIGludG8gdGhlIG91dHB1 dCB0byB0aGUgYnJvd3Nlci4NCiAgIEhPQkEgc3RpbGwgcmVxdWlyZXMgVExTIHRvIHByZXZlbnQg c2Vzc2lvbiBjb29raWUgaGlqYWNraW5nLg0KDQpUaGlzIGlzIG5vdCBhIHJlcXVpcmVtZW50IG9u IEhPQkEgaW50ZXJhY3Rpb25zIC0gaXQncyBvbiB0aGUgb3ZlcmFsbA0KSFRUUCBzZXNzaW9uLiAg U3VnZ2VzdGlvbjoNCg0KT0xEDQogICBIT0JBIHN0aWxsIHJlcXVpcmVzIFRMUyB0byBwcmV2ZW50 IHNlc3Npb24gY29va2llIGhpamFja2luZy4NCk5FVw0KICAgVXNlIG9mIFRMUyBmb3IgdGhlIEhU VFAgc2Vzc2lvbiBpcyBzdGlsbCBuZWNlc3NhcnkgdG8gcHJldmVudA0KICAgc2Vzc2lvbiBjb29r aWUgaGlqYWNraW5nLg0KDQo+ID4gWzVdIFNlY3Rpb24gNS4zIC0gdW5yZWNvZ25pemVkIGtleQ0K PiA+DQo+ID4gUGFyYWdyYXBocyA0IGFuZCA1IGluIHRoaXMgc2VjdGlvbiBkb24ndCBzZWVtIHRv IGJlbG9uZyBoZXJlLCBhbmQgYXBwZWFyIHRvDQo+ID4gYmUgd3JpdHRlbiBpbiBhIHNvbWV3aGF0 IGxvb3NlIGZhc2hpb24sIHBhcnRpY3VsYXJseSBhcm91bmQgdXNlciAgdmVyaWZpY2F0aW9uLg0K PiA+IEEgc2VydmVyIHRoYXQgZG9lcyB3aGF0IGlzIHN1Z2dlc3RlZCBoZXJlIGNvdWxkIGhhdmUg c2lnbmlmaWNhbnQgc2VjdXJpdHkNCj4gPiB3ZWFrbmVzc2VzLg0KPiANCj4gV2hpY2ggc3BlY2lm aWMgd2Vha25lc3NlcyBkbyB5b3UgbWVhbj8NCg0KSW4gdGhpcyB0ZXh0Og0KDQogICBUaGUgc2Vy dmVyID4+Y2FuPDwgdGhlbiB1c2Ugc29tZSBvdXQtb2YtYmFuZCBtZXRob2QgKHN1Y2ggYXMgYQ0K ICAgY29uZmlybWF0aW9uIGVtYWlsIHJvdW5kIHRyaXAsIFNNUywgb3IgYW4gVUEgdGhhdCBpcyBh bHJlYWR5DQogICBlbnJvbGxlZCkgdG8gdmVyaWZ5IHRoYXQgdGhlICJuZXciIHVzZXIgaXMgdGhl IHNhbWUgYXMgdGhlIGFscmVhZHktDQogICBlbnJvbGxlZCBvbmUuDQoNCmFuZCB0aGlzIHRleHQN Cg0KICAgQ29tcGxldGlvbiBvZiB0aGUgam9pbmluZyBwcm9jZXNzID4+bWlnaHQ8PCByZXF1aXJl IGNvbmZpcm1hdGlvbiBieQ0KICAgZW1haWwsIFNNUywgQ2FwdGNoYSwgYW5kIHNvIG9uLg0KDQp0 aGUgdXNlIG9mICJjYW4iIGFuZCAibWlnaHQiIGFwcGVhcnMgdG8gbWFrZSB1c2VyIHZlcmlmaWNh dGlvbiBvcHRpb25hbCwNCndoaWNoIGlzIGEgcG9vciByZWNvbW1lbmRhdGlvbiBmb3Igb2J2aW91 cyByZWFzb25zLg0KDQpUaGUgc2ltcGxlc3QgZml4IHdvdWxkIGJlIHRvIGNoYW5nZSBib3RoIG9m IHRob3NlIHdvcmRzIHRvICJvdWdodCB0byINCm9yICJzaG91bGQiIChsb3dlciBjYXNlKS4NCg0K PiA+IFtBXSBBQk5GIGVuY29kaW5nIG9mIGFsZw0KPiA+DQo+ID4gSW4gc2VjdGlvbiAyLCBJIHNl ZToNCj4gPg0KPiA+ICAgIGFsZyA9IDEqMkRJR0lUDQo+ID4NCj4gPiAgICBvICBhbGc6IHNwZWNp ZmllcyB0aGUgc2lnbmF0dXJlIGFsZ29yaXRobSBiZWluZyB1c2VkIGVuY29kZWQgYXMgYW4NCj4g PiAgICAgICBBU0NJSSBjaGFyYWN0ZXIgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDkuMy4NCj4gPg0K PiA+IFNlY3Rpb24gOS4zIHNwZWNpZmllcyBhIHNpbmdsZSBkaWdpdC4gIEhvdyBkb2VzIHRoYXQg YmVjb21lIDEqMkRJR0lUID8NCj4gDQo+IEh1aD8gVGhlIGN1cnJlbnQgYWxncyBvbmx5IHVzZSBv bmUgZGlnaXQsIGJ1dCB0aGUgYWJuZiBhbGxvd3MgZm9yDQo+IG1vcmUuIE5vdGhpbmcgb2RkIHRo ZXJlIHRoYXQgSSBjYW4gc2VlLg0KDQpXaGF0IGlmIHNvbWVvbmUgdXNlcyAiMDEiIGluc3RlYWQg b2YgIjEiID8gIEFkZGluZyB0aGUgZm9sbG93aW5nIHZhcmlhbnQNCm9mIHlvdXIgcmVzcG9uc2Ug KHdoaWNoIGlzIGJldHRlciB0aGFuIG15IGluaXRpYWwgcHJvcG9zYWwpIHdvdWxkIGNsb3NlIG9m Zg0KdGhpcyBjb3JuZXIgY2FzZToNCg0KCUFsZ29yaXRobXMgZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50IHVzZSBvbmx5IG9uZSBkaWdpdDsgdGhlIEFCTkYNCglhbGxvd3MgZm9yIHR3byBkaWdpdHMg Zm9yIGZ1dHVyZSBleHBhbnNpb24uDQoNCj4gPiBbQl0gU2VjdGlvbiA1LjMgLSBDUEsgdnMuIGtp ZA0KDQo+ID4gSUlVQywgdGhlIEhPQkEgY2xpZW50IHNlbmRzOg0KPiA+DQo+ID4gICAgSE9CQS1S RVMgPSBraWQgIi4iIGNoYWxsZW5nZSAiLiIgbm9uY2UgIi4iIHNpZw0KPiA+DQo+ID4gSWYgc28s IEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgdGhlIHNlcnZlciBleHRyYWN0cyBhIENQSyBmcm9tIHRo YXQuDQo+IA0KPiBWaWEgdGhlIGtpZCB5ZXMuDQoNClsuLi4gc25pcCAuLi5dDQoNCj4gSSdtIG5v dCBzZWVpbmcgYW4gYWN0aW9uYWJsZSBpc3N1ZSB0aGF0IG5lZWRzIGEgY2hhbmdlLg0KDQpUaGUg Y2xpZW50IHNlbmRzIGEga2lkLCBidXQgdGhlIHNlcnZlciBpcyBzdXBwb3NlZCB0byByZWNvZ25p emUgdGhlIENQSy4NClRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgc2VydmVyJ3MgYWN0aW9ucyBuZWVk cyB0byBzdGFydCBmcm9tIHRoZSBraWQsIGFzDQpraWQtPkNQSyBsb29rdXAgbWF5IGZhaWwuICBI ZXJlJ3MgYSBwb3NzaWJsZSB0ZXh0IGNoYW5nZToNCg0KT0xEDQogICBJbiB0aGUgYXV0aGVudGlj YXRpb24gcGhhc2UsIHRoZSBzZXJ2ZXIgZXh0cmFjdHMgdGhlIENQSyBmcm9tIHRoZQ0KICAgc2ln bmluZyBwaGFzZSBhbmQgZGVjaWRlcyBpZiBpdCByZWNvZ25pemVzIHRoZSBDUEsuICBJZiB0aGUg c2VydmVyDQogICByZWNvZ25pemVzIHRoZSBDUEssIHRoZSBzZXJ2ZXIgbWF5IGZpbmlzaCB0aGUg Y2xpZW50IGF1dGhlbnRpY2F0aW9uDQogICBwcm9jZXNzLg0KTkVXDQogICBJbiB0aGUgYXV0aGVu dGljYXRpb24gcGhhc2UsIHRoZSBzZXJ2ZXIgdXNlcyB0aGUga2lkIHRvIGxvY2F0ZSBpdHMNCiAg IGNvcHkgb2YgdGhlIGNsaWVudCdzIENQSy4gIElmIHRoZSBzZXJ2ZXIgZmluZHMgdGhlIENQSyBh bmQgcmVjb2duaXplcw0KICAgdGhhdCBDUEsgYXMgYXBwcm9wcmlhdGUgZm9yIHVzZSwgdGhlIHNl cnZlciBtYXkgZmluaXNoIHRoZSBjbGllbnQNCiAgIGF1dGhlbnRpY2F0aW9uIHByb2Nlc3MuDQoN ClRoYXQgcmVzdWx0cyBpbiBhIGNvdXBsZSBvZiBrbm9jay1vbiBjaGFuZ2VzIHRvIGdlbmVyYWxp emUgInJlY29nbml6ZSINCnRvICJsb2NhdGUgb3IgcmVjb2duaXplIiAtIGhlcmUncyB0aGUgZmly c3Qgb25lOg0KDQpPTEQNCiAgIER1cmluZyB0aGUgYXV0aGVudGljYXRpb24gcGhhc2UsIGlmIHRo ZSBzZXJ2ZXIgZG9lcyBub3QgcmVjb2duaXplIHRoZQ0KICAgQ1BLLA0KTkVXDQogICBEdXJpbmcg dGhlIGF1dGhlbnRpY2F0aW9uIHBoYXNlLCBpZiB0aGUgc2VydmVyIGNhbm5vdCBsb2NhdGUgb3Ig ZG9lcw0KICAgbm90IHJlY29nbml6ZSB0aGUgQ1BLLA0KDQpUaGUgb3RoZXIgb25lIGlzIHNpbWls YXIuDQoNCj4gPiBbQ10gUlNBIHNpZ25hdHVyZSBhbGdvcml0aG0NCg0KWy4uLiBuaXQgc25pcHBl ZCAuLi5dDQoNCj4gPiBUaGUgbWlub3IgaXNzdWUgaXMNCj4gPiB3aGV0aGVyIHRoYXQgaXMgdGhl IHNpZ25hdHVyZSBhbGdvcml0aG0gdGhhdCdzIHdhbnRlZCwgb24gd2hpY2ggSSdsbCBkZWZlcg0K PiA+IHRvIHRoZSBjcnlwdG8gZXhwZXJ0cyBvbiB0aGF0IChlLmcuLCBJIHNlZW0gdG8gcmVjYWxs IGEgbmVnYXRpdmUgc2FhZw0KPiA+IGNvbW1lbnQgb24gUEtDUyAxLjUgbWVjaGFuaXNtcyBpbiB0 aGUgcGFzdCBjb3VwbGUgb2YgbW9udGhzKS4NCj4gDQo+IFllcywgaXQncyBmaW5lIGZvciBzZWN1 cml0eSBhbmQgaXMgY29ycmVjdCBmb3IgaW50ZXJvcC9kZXBsb3ltZW50DQo+IHJlYXNvbnMuIFBL Q1N2MS41IGVuY3J5cHRpb24gaXMgd2hhdCdzIGxlc3MgZGVzaXJhYmxlIGlmIG5vdCBkb25lDQo+ IHdlbGwgYW5kIGF0dGVtcHRpbmcgdG8gbWFuZGF0ZSBQU1MgaGVyZSB3b3VsZCBiZSBhIGJhZCBw bGFuLg0KDQpPaywgdGhhdCdzIHdoYXQgSSB3YW50ZWQgdG8gc2VlIGNoZWNrZWQuICBObyBwcm9i bGVtLg0KDQo+ID4gW0RdIEphdmFzY3JpcHQgbG9jYWwgc3RvcmFnZS4NCg0KQWdhaW4sIG9uZSB3 b3JkIGlzIGJvdGhlcmluZyBtZSAtIGhlcmUncyBhIHN1Z2dlc3RlZCBjaGFuZ2UgdG8gdGhlIGFi c3RyYWN0Og0KDQogICBIT0JBIGlzIGFuDQogICBhbHRlcm5hdGl2ZSB0byBIVFRQIGF1dGhlbnRp Y2F0aW9uIHNjaGVtZXMgdGhhdCByZXF1aXJlIHBhc3N3b3JkcyBhbmQNCiAgIHRoZXJlZm9yZSBh dm9pZHMgYWxsIHByb2JsZW1zIHJlbGF0ZWQgdG8gcGFzc3dvcmRzLCBzdWNoIGFzIGxlYWthZ2UN CiAgIG9mIHNlcnZlci1zaWRlIHBhc3N3b3JkIGRhdGFiYXNlcy4NCg0KUmVtb3ZlICJhbGwiIC0g b3IgY2hhbmdlIGl0IHRvICJtYW55IiBvciAiY29tbW9uIi4NCg0KVGhhbmtzLA0KLS1EYXZpZA0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFN0ZXBoZW4gRmFycmVsbCBb bWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdDQo+IFNlbnQ6IFdlZG5lc2RheSwgRGVj ZW1iZXIgMjQsIDIwMTQgNjoxNSBBTQ0KPiBUbzogQmxhY2ssIERhdmlkOyBwYXVsLmhvZmZtYW5A dnBuYy5vcmc7IG1pa2VAcGhyZXNoZWV6LmNvbTsgR2VuZXJhbCBBcmVhDQo+IFJldmlldyBUZWFt IChnZW4tYXJ0QGlldGYub3JnKTsgb3BzLWRpckBpZXRmLm9yZw0KPiBDYzogaWV0ZkBpZXRmLm9y ZzsgaHR0cC1hdXRoQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBHZW4tQVJUIGFuZCBPUFMtRGly IHJldmlldyBvZiBkcmFmdC1pZXRmLWh0dHBhdXRoLWhvYmEtMDcNCj4gDQo+IA0KPiBIaSBEYXZp ZCwNCj4gDQo+IFNvcnJ5IGZvciB0aGUgc2xvdyByZXNwb25zZSwgZW5kIG9mIHllYXIgcnVzaCBh bmQgYWxsIHRoYXQuLi4NCj4gDQo+IEFuZCB0aGFua3MgZm9yIHRoZSByZXZpZXcsIHJlc3BvbnNl cyBpbmxpbmUgYW5kIGEgcHJvdG8tMDgNCj4gdmVyc2lvbiAoaGFuZGxpbmcgdGhlIHZhcmlvdXMg SUVURiBMQyBjb21tZW50cykgaXMgYXQgWzFdDQo+IHdpdGggYSBkaWZmIHZzLiAwNyBhdCBbMl0u IEknbGwgcGxhbiB0byBwdWJsaXNoIHRoYXQgYXMgYW4NCj4gb2ZmaWNpYWwgLTA4IGluIGEgZmV3 IGRheXMgaWYgdGhlcmUgYXJlIG5vIGNvbW1lbnRzLg0KPiANCj4gQ2hlZXJzLA0KPiBTLg0KPiAN Cj4gWzFdIGh0dHBzOi8vZG93bi5kc2cuY3MudGNkLmllL21pc2MvZHJhZnQtaWV0Zi1odHRwYXV0 aC1ob2JhLTA4LnR4dA0KPiBbMl0NCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDE9ZHJhZnQtaWV0Zi1odHRwYXV0aC1ob2JhLQ0KPiAwNy50eHQmdXJsMj1odHRwczovL2Rvd24u ZHNnLmNzLnRjZC5pZS9taXNjL2RyYWZ0LWlldGYtaHR0cGF1dGgtaG9iYS0wOC50eHQNCj4gDQo+ IE9uIDE1LzEyLzE0IDIzOjI1LCBCbGFjaywgRGF2aWQgd3JvdGU6DQo+ID4gVGhpcyBpcyBhIGNv bWJpbmVkIEdlbi1BUlQgYW5kIE9QUy1EaXIgcmV2aWV3LiAgQm9pbGVycGxhdGUgZm9yIGJvdGgg Zm9sbG93cw0KPiAuLi4NCj4gPg0KPiA+IEkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3 ZXIgZm9yIHRoaXMgZHJhZnQuIEZvciBiYWNrZ3JvdW5kIG9uDQo+ID4gR2VuLUFSVCwgcGxlYXNl IHNlZSB0aGUgRkFRIGF0Og0KPiA+DQo+ID4gPGh0dHA6Ly93aWtpLnRvb2xzLmlldGYub3JnL2Fy ZWEvZ2VuL3RyYWMvd2lraS9HZW5BcnRmYXE+Lg0KPiA+DQo+ID4gUGxlYXNlIHJlc29sdmUgdGhl c2UgY29tbWVudHMgYWxvbmcgd2l0aCBhbnkgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRzDQo+ID4g eW91IG1heSByZWNlaXZlLg0KPiA+DQo+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQg YXMgcGFydCBvZiB0aGUgT3BlcmF0aW9uYWwgZGlyZWN0b3JhdGUncyBvbmdvaW5nDQo+ID4gZWZm b3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJ RVNHLiAgVGhlc2UgY29tbWVudHMNCj4gPiB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUg YmVuZWZpdCBvZiB0aGUgb3BlcmF0aW9uYWwgYXJlYSBkaXJlY3RvcnMuDQo+ID4gRG9jdW1lbnQg ZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxp a2UgYW55IG90aGVyDQo+ID4gbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiA+DQo+ID4gRG9jdW1lbnQ6 IGRyYWZ0LWlldGYtaHR0cGF1dGgtaG9iYS0wNw0KPiA+IFJldmlld2VyOiBEYXZpZCBCbGFjaw0K PiA+IFJldmlldyBEYXRlOiBEZWMgWFgsIDIwMTQNCj4gPiBJRVRGIExDIEVuZCBEYXRlOiBEZWMg MjQsIDIwMTQNCj4gPg0KPiA+IFN1bW1hcnk6IFRoaXMgZHJhZnQgaXMgb24gdGhlIHJpZ2h0IHRy YWNrLCBidXQgaGFzIG9wZW4gaXNzdWVzDQo+ID4gIAkJZGVzY3JpYmVkIGluIHRoZSByZXZpZXcu DQo+ID4NCj4gPiBUaGlzIGRyYWZ0IHNwZWNpZmllcyBhIHNpZ25hdHVyZS1iYXNlZCBhdXRoZW50 aWNhdGlvbiBtZWNoYW5pc20gZm9yIEhUVFANCj4gPiB0aGF0IGlzIGJhc2VkIG9uIGFzeW1tZXRy aWMgKHB1YmxpYy1wcml2YXRlKSBrZXkgcGFpcnMgd2l0aG91dCB1c2luZw0KPiA+IGNlcnRpZmlj YXRlcy4gIEEgZGlmZmVyZW50IGtleSBwYWlyIGlzIHVzZWQgYnkgZWFjaCB1c2VyIGZvciBlYWNo IGZvcg0KPiA+IGVhY2ggaG9zdCAoIndlYi1vcmlnaW4iLCBzZWUgW1JGQzY0NTRdKSwgYW5kIGVh Y2ggc2lnbmF0dXJlIGlzIGJhc2VkDQo+ID4gb24gYSBzZXJ2ZXItZ2VuZXJhdGVkIGNoYWxsZW5n ZS4NCj4gPg0KPiA+IFRoZSBkcmFmdCBpcyBnZW5lcmFsbHkgd2VsbC13cml0dGVuIGFuZCBjbGVh ciBvbiB0aGUgYXV0aGVudGljYXRpb24NCj4gPiBtZWNoYW5pY3MsIGJ1dCBoYXMgd2Vha25lc3Nl cyBpbiBzcGVjaWZ5aW5nIHRoZSBlbnZpcm9ubWVudCB0aGF0DQo+ID4gc3Vycm91bmRzIHVzZSBv ZiB0aGlzIG1lY2hhbmlzbS4gIFNvbWUgb2YgdGhlc2UgaXNzdWVzIGFyZSBiYXNpYyB0aGluZ3MN Cj4gPiB0aGF0IGFueW9uZSB3b3JraW5nIG9uIHdlYiB0ZWNobm9sb2d5IG9yIGFwcGxpZWQgY3J5 cHRvICJqdXN0IGtub3dzIiwNCj4gPiBidXQgZXZlbiB0aGUgb2J2aW91cyBuZWVkcyB0byBiZSBz dGF0ZWQgd2hlbiBpdCdzIGludGVncmFsIHRvIHNlY3VyaXR5Lg0KPiA+DQo+ID4gLS0gTWFqb3Ig aXNzdWVzOiAtLQ0KPiA+DQo+ID4gWzFdIENoYWxsZW5nZSBzaXplIGFuZCBwcmVkaWN0YWJpbGl0 eQ0KPiA+DQo+ID4gSW4gdGhlIEFCTkY6DQo+ID4NCj4gPiAgICBjaGFsbGVuZ2UgPSAxKmJhc2U2 NHVybGNoYXJzDQo+ID4NCj4gPiBJIGRpZCBub3Qgc2VlIGFueSBvdGhlciBkaXNjdXNzaW9uIG9m IG1pbmltdW0gbGVuZ3RoIG9mIGNoYWxsZW5nZQ0KPiA+IG9yIGFtb3VudCBvZiBlbnRyb3B5IGlu IHRoZSBjaGFsbGVuZ2UuICBGb3IgdGhlIGxhdHRlciwgZG8gdGhlIGNoYWxsZW5nZXMNCj4gPiBu ZWVkIHRvIGJlIHVucHJlZGljdGFibGU/ICBJIHdvdWxkIHRoaW5rIHNvLg0KPiA+DQo+ID4gSSB0 aGluayBhIHJlcXVpcmVtZW50IG9uIG1pbmltdW0gY2hhbGxlbmdlIHNpemUgYW5kIGEgcmVjb21t ZW5kYXRpb24gb24NCj4gPiBtaW5pbXVtIGFtb3VudCBvZiBlbnRyb3B5IHdvdWxkIGJlIGdvb2Qg aWRlYXMuDQo+IA0KPiBGYWlyIHBvaW50LiBBbmQgeW91J3JlIHJpZ2h0IHRoYXQgdGhpcyBpcyBh c3N1bWVkIGFuZCBvdWdodCBiZQ0KPiBleHBsaWNpdCwgc28gZ29vZCBjYXRjaC4NCj4gDQo+IE9M RDoNCj4gDQo+ICAgIG8gIGNoYWxsZW5nZTogTVVTVCBiZSBhIGJhc2U2NHVybCBlbmNvZGVkIGNo YWxsZW5nZSB2YWx1ZSB0aGF0IHRoZQ0KPiAgICAgICBzZXJ2ZXIgY2hvc2UgdG8gc2VuZCB0byB0 aGUgY2xpZW50DQo+IA0KPiBORVc6DQo+IA0KPiAgICBvICBjaGFsbGVuZ2U6IE1VU1QgYmUgYSBi YXNlNjR1cmwgZW5jb2RlZCBjaGFsbGVuZ2UgdmFsdWUgdGhhdCB0aGUNCj4gICAgICAgc2VydmVy IGNob3NlIHRvIHNlbmQgdG8gdGhlIGNsaWVudC4gVGhlIGNoYWxsZW5nZSBNVVNUIGJlIGNob3Nl bg0KPiAgICAgICBzbyB0aGF0IGl0IGlzIGluZmVhc2libGUgdG8gZ3Vlc3MsIGFuZCBTSE9VTEQg YmUgaW5kaXN0aW5ndWlzaGFibGUNCj4gICAgICAgZnJvbSAodGhlIGJhc2U2NHVybCBlbmNvZGlu ZyBvZikgYW4gYXQgbGVhc3QgMTI4LWJpdCBsb25nIHJhbmRvbQ0KPiAgICAgICBzdHJpbmcuDQo+ IA0KPiA+DQo+ID4gWzJdIENoYWxsZW5nZSB2ZXJpZmljYXRpb24gYW5kIHJldXNlDQo+ID4NCj4g PiBUaGlzIHNlbnRlbmNlIG9uIHAuNiBzdHJpa2VzIG1lIGFzIHN1YnRseSBkYW5nZXJvdXM6DQo+ ID4NCj4gPiAgICBUaGUgY2hhbGxlbmdlIGhvd2V2ZXIgaXMgc2VudCBvdmVyDQo+ID4gICAgdGhl IG5ldHdvcmsgc28gYXMgdG8gbWFrZSBpdCBzaW1wbGVyIGZvciBhIHNlcnZlciB0byBiZSBzdGF0 ZWxlc3MuDQo+ID4gICAgKE9uZSBmb3JtIG9mIHN0YXRlbGVzcyBjaGFsbGVuZ2UgbWlnaHQgYmUg YSBjaXBoZXJ0ZXh0IHRoYXQgdGhlDQo+ID4gICAgc2VydmVyIGRlY3J5cHRzIGFuZCBjaGVja3Ms IGJ1dCB0aGF0IGlzIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC4pDQo+ID4NCj4gPiBUaGUgZHJh ZnQgZWxzZXdoZXJlIGFzc2VydHMgb3IgYXNzdW1lcyB0aGF0IGNoYWxsZW5nZSByZXVzZSBjYW4g YmUNCj4gPiBwcmV2ZW50ZWQgYnkgdGhlIHNlcnZlciBvciBiZSB0aW1lLWJvdW5kZWQgYnkgbWF4 LWFnZSwgYW5kIHJlbGllcyBvbg0KPiA+IHRob3NlIHJldXNlIGxpbWl0cyBmb3Igc2VjdXJpdHkg cHJvcGVydGllcywgZS5nLiwgYXMgaW4gdGhpcyBzZW50ZW5jZQ0KPiA+IG5lYXIgdGhlIGVuZCBv ZiBTZWN0aW9uIDYuMToNCj4gPg0KPiA+ICAgIE5vdGUgdGhhdCByZXBsYXkgb2YgcmVnaXN0cmF0 aW9uIChhbmQgb3RoZXIgSE9CQSkgbWVzc2FnZXMgaXMgcXVpdGUNCj4gPiAgICBwb3NzaWJsZS4g IFRoYXQgaG93ZXZlciBjYW4gYmUgY291bnRlcmFjdGVkIGlmIGNoYWxsZW5nZSBmcmVzaG5lc3Mg aXMNCj4gPiAgICBlbnN1cmVkLg0KPiA+DQo+ID4gVGhlIHNlbnRlbmNlIHF1b3RlZCBmcm9tIHAu NiBhcHBlYXJzIHRvIGFsbG93IChvciBldmVuIGVuY291cmFnZSkNCj4gPiBzdGF0ZWxlc3Mgc2Vy dmVycyB0byBpbXBsZW1lbnQgcmF0aGVyIHdlYWsgY2hlY2tzIG9uIG5vdCBvbmx5IGNoYWxsZW5n ZQ0KPiA+IHJldXNlLCBidXQgYWxzbyBjaGFsbGVuZ2UgdmFsaWRpdHkgKGUuZy4sIHdoYXQgaWYg dGhlIGNoYWxsZW5nZSB2YWxpZGl0eQ0KPiA+IHRlc3Qgd2VyZSAiY2hhbGxlbmdlIG1vZCAxMDI0 ID09IDciID8pLg0KPiA+DQo+ID4gQWxsb3dpbmcgc3VjaCB3ZWFrIGNoZWNrcyBjb3VsZCBlbmFi bGUgYW4gYXR0YWNrZXIgdG8gY2hvb3NlIG9yIGluZmx1ZW5jZQ0KPiA+IHRoZSBjaG9pY2Ugb2Yg Y2hhbGxlbmdlIHZhbHVlcywgd2hpY2ggY291bGQgYmUgdXNlZnVsIChlLmcuLCBmb3INCj4gPiBk aWZmZXJlbnRpYWwgY3J5cHRhbmFseXNpcyBhdHRhY2sgb24gdGhlIGhhc2ggZnVuY3Rpb24pLCBh cyB0aGUNCj4gPiBhdHRhY2tlciAoY2xpZW50KSBhbHJlYWR5IGNvbnRyb2xzIHRoZSBub25jZS4N Cj4gPg0KPiA+IEFzIHBhcnQgb2YgdGhpcywgdGhlIHNlcnZlciBuZWVkcyB0byBjaGVjayB3aGV0 aGVyIGEgY2hhbGxlbmdlIHByZXNlbnRlZA0KPiA+IG9uIG9uZSBjb25uZWN0aW9uIG9yIHNlc3Np b24gaGFzIGJlZW4gcmV1c2VkIG9uIGFub3RoZXIuICBJIHRoaW5rIHRoZQ0KPiA+IGZvbGxvd2lu ZyBzZW50ZW5jZSBpbiBzZWN0aW9uIDMgaXMgaW50ZW5kZWQgdG8gcHJldmVudCB0aGlzLCBidXQg aXQncw0KPiA+IHdlYWtlbmVkIGJ5IHRoZSAic3RhdGVsZXNzIiBsYW5ndWFnZSBhYm92ZToNCj4g Pg0KPiA+ICAgICAgIFRoZSBjaGFsbGVuZ2UgTVVTVCBiZQ0KPiA+ICAgICAgIHVuaXF1ZSBmb3Ig ZXZlcnkgSFRUUCA0MDEgcmVzcG9uc2UgaW4gb3JkZXIgdG8gcHJldmVudCByZXBsYXkNCj4gPiAg ICAgICBhdHRhY2tzIGZyb20gcGFzc2l2ZSBvYnNlcnZlcnMuDQo+ID4NCj4gPiBFeHBsaWNpdCBz ZXJ2ZXIgY2hlY2tzIGZvciBjaGFsbGVuZ2UgcmV1c2Ugb3VnaHQgdG8gYmUgUkVRVUlSRUQsIGFu ZA0KPiA+IHRoZSBhYm92ZSB1c2Ugb2YgInN0YXRlbGVzcyIgbmVlZHMgdG8gYmUgcXVhbGlmaWVk Lg0KPiANCj4gSG1tLiBJIHRoaW5rIHRoYXQgSE9CQSBvdWdodCBub3QgUkVRVUlSRSBmdWxsIHJl cGxheSBwcm90ZWN0aW9uDQo+IGluIGFsbCBjYXNlcywgdGhhdCBpcywgaXQgU0hPVUxEIGJlIHBv c3NpYmxlIHRvIGRlcGxveSBhIHNlcnZlcg0KPiB0aGF0IGlzIHZ1bG5lcmFibGUgdG8gc29tZSBy ZXBsYXkuIFRoZSByZWFzb24gaXMgdGhhdCB3ZSdyZSB0cnlpbmcNCj4gdG8gZGlzcGxhY2UgcGFz c3dvcmRzIGhlcmUgYW5kIEkgYmVsaWV2ZSAod2l0aG91dCBtdWNoIGhhcmQgZXZpZGVuY2UNCj4g SSdsbCBncmFudCB5b3UpIHRoYXQgd2UnZCBsb3NlIHNvbWUgZGVwbG95bWVudCBjaGFuY2VzIGlm IHdlIHdlcmUNCj4gdG8gaW5zaXN0IG9uIGV2ZXJ5IHNpbmdsZSBjaGFsbGVuZ2UgYmVpbmcgZnJl c2guDQo+IA0KPiBTbyBJJ2QgYXJndWUgZm9yIG5vLWNoYW5nZSBoZXJlLCBidXQgd291bGQgd2Vs Y29tZSBmdXJ0aGVyIGRpc2N1c3Npb25tDQo+IGV2aWRlbmNlIG9yIHN1Z2dlc3Rpb25zIGZvciB0 ZXh0IHRoYXQncyBub3QgZ29pbmcgdG8gYmUgc28gb25lcm91cw0KPiBhcyB0byB3ZWFrZW4gb3Vy IGNoYW5jZXMgb2YgZ2V0dGluZyB0aGlzIGRlcGxveWVkLg0KPiANCj4gDQo+ID4NCj4gPiBbM10g V2ViIG9yaWdpbiBjaGVja3MNCj4gPg0KPiA+IEkgZGlkIG5vdCBzZWUgdGV4dCBtYW5kYXRpbmcg dGhhdCBUTFMgKHNlcnZlciBjZXJ0aWZpY2F0ZSksIEhUVFAgKGFjY2Vzc2VkDQo+ID4gVVJMKSBh bmQgSE9CQSAoc2lnbmF0dXJlIGlucHV0KSB1c2UgdGhlIHNhbWUgd2ViIG9yaWdpbiwgYW5kIHN0 YXRpbmcgdGhhdA0KPiA+IHRoZSBzZXJ2ZXIgaGFzIHRvIGNoZWNrL2VuZm9yY2UgdGhpcy4gIERp ZCBJIG1pc3Mgc29tZXRoaW5nPw0KPiA+DQo+ID4gSSByZWFsaXplIHRoYXQgdGhpcyBpcyBhbiBv YnZpb3VzIHJlcXVpcmVtZW50LCBidXQgaXQgZG9lcyBuZWVkIHRvIGJlDQo+ID4gc3RhdGVkLg0K PiANCj4gRmFpciBlbm91Z2gsIEkgYWdyZWUgZm9sa3MgaGF2ZSBiZWVuIGtub3duIHRvIG5vdCBp bXBsZW1lbnQgZXZlbiB0aGUNCj4gbW9zdCBvYnZpb3VzIHRoaW5nczotKSBJIGFkZGVkIHRoZSB0 ZXh0IGJlbG93IHRvIHNlY3Rpb24gMzoNCj4gDQo+ICAgIFRoZSBzZXJ2ZXIgTVVTVCBjaGVjayB0 aGF0IHRoZSBzYW1lIHdlYiBvcmlnaW4gaXMgdXNlZCBpbiBhbGwgb2YgdGhlDQo+ICAgIHNlcnZl cidzIFRMUyBzZXJ2ZXIgY2VydGlmaWNhdGUsIHRoZSBVUkwgYmVpbmcgYWNjZXNzZWQgYW5kIHRo ZSBIT0JBDQo+ICAgIHNpZ25hdHVyZS4gIElmIGFueSBvZiB0aG9zZSBjaGVja3MgZmFpbCwgdGhl IHNlcnZlciB0cmVhdHMgdGhlDQo+ICAgIHNpZ25hdHVyZSBhcyBiZWluZyBjcnlwdG9ncmFwaGlj YWxseSBpbmNvcnJlY3QuDQo+IA0KPiA+DQo+ID4gWzRdIFRMUyByZXF1aXJlbWVudCBsZXZlbA0K PiA+DQo+ID4gVExTIGlzIG9ubHkgYSAiU0hPVUxEIiByZXF1aXJlbWVudCBmb3IgSE9CQSwgbm90 IGEgIk1VU1QiIHJlcXVpcmVtZW50IC0NCj4gPiBmaXJzdCBwYXJhZ3JhcGggaW4gU2VjdGlvbiA4 LjEgKFByaXZhY3kgQ29uc2lkZXJhdGlvbnMpLg0KPiA+DQo+ID4gSWYgVExTIGlzIG5vdCBhICJN VVNUIiByZXF1aXJlbWVudCwgYXQgbGVhc3QgYSBkaXNjdXNzaW9uIG9mIG1hbi1pbi10aGUtDQo+ ID4gbWlkZGxlIChNSVRNKSBhdHRhY2tzIHNlZW1zIHRvIGJlIGluIG9yZGVyLiAgVGhlcmUncyBu byBuZWVkIGZvciBhbg0KPiBleHRlbnNpdmUNCj4gPiBkaXNjdXNzaW9uIG9mIGFsbCBvZiB0aGUg c2VjdXJpdHkgcHJvcGVydGllcyBvZiBUTFMsIGJ1dCBNSVRNIGF0dGFja3MgYXJlDQo+ID4gZGVm aW5pdGVseSB3b3J0aCBhIG1lbnRpb24sIGFuZCB0aGF0IGNvdWxkIGJlIGNvbXBsZW1lbnRlZCBi eSBhIHBvaW50ZXIgdG8NCj4gPiBzdWl0YWJsZSBIVFRQL1RMUyBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyB0ZXh0IGVsc2V3aGVyZS4NCj4gDQo+IEkgdGhpbmsgdGhhdCdzIGNvdmVyZWQgd2hlcmUg d2Ugbm90ZSB0aGUgcG90ZW50aWFsIGZvciByZXBsYXksIHdoaWNoDQo+IGlzIHdoYXQgYSBNaXRN IHdvdWxkL2NvdWxkIGRvIGluIHRoaXMgY2FzZS4gVGhhdCBpcyBub3RlZCBpbiBib3RoDQo+IHNl Y3Rpb24gMyBhbmQgaW4gNi4xIGFuZCBpbiBzZWN0aW9uIDguIEkgdGhpbmsgd2UgaGF2ZSBpdCBj b3ZlcmVkIHRvDQo+IGJlIGhvbmVzdC4NCj4gDQo+ID4NCj4gPiBbNV0gU2VjdGlvbiA1LjMgLSB1 bnJlY29nbml6ZWQga2V5DQo+ID4NCj4gPiBQYXJhZ3JhcGhzIDQgYW5kIDUgaW4gdGhpcyBzZWN0 aW9uIGRvbid0IHNlZW0gdG8gYmVsb25nIGhlcmUsIGFuZCBhcHBlYXIgdG8NCj4gPiBiZSB3cml0 dGVuIGluIGEgc29tZXdoYXQgbG9vc2UgZmFzaGlvbiwgcGFydGljdWxhcmx5IGFyb3VuZCB1c2Vy DQo+IHZlcmlmaWNhdGlvbi4NCj4gPiBBIHNlcnZlciB0aGF0IGRvZXMgd2hhdCBpcyBzdWdnZXN0 ZWQgaGVyZSBjb3VsZCBoYXZlIHNpZ25pZmljYW50IHNlY3VyaXR5DQo+ID4gd2Vha25lc3Nlcy4N Cj4gDQo+IFdoaWNoIHNwZWNpZmljIHdlYWtuZXNzZXMgZG8geW91IG1lYW4/DQo+IA0KPiA+DQo+ ID4gSSBzdHJvbmdseSByZWNvbW1lbmQgcmVwbGFjaW5nIHRob3NlIHR3byBwYXJhZ3JhcGhzIHdp dGggYSBzaG9ydCBzZW50ZW5jZQ0KPiB0aGF0DQo+ID4gc2F5czoNCj4gPiAJLSBpZiBhIGtpZCBp cyB1bnJlY29nbml6ZWQgb3IgdGhlIHNlcnZlciBvdGhlcndpc2UgZGV0ZXJtaW5lcw0KPiA+IAkJ dGhhdCB0aGUgQ1BLIGlzIG5vdCB0byBiZSB1c2VkIGZvciB0aGlzIEhUVFAgYXV0aGVudGljYXRp b24sDQo+ID4gCS0gdGhlbiB0aGUgUmVnaXN0cmF0aW9uIChzZWUgNi4xKSBhbmQvb3IgQXNzb2Np YXRpbmcgQWRkaXRpb25hbCBLZXlzIHRvDQo+ID4gCQlhbiBFeGl0aW5nIEFjY291bnQgKHNlZSA2 LjIpIHByb2Nlc3NlcyBNQVkgYmUgdXNlZCBpbnN0ZWFkIG9mDQo+ID4gCQl0cmVhdGluZyB0aGlz IHNpdHVhdGlvbiBhcyBhbiBhdXRoZW50aWNhdGlvbiBmYWlsdXJlLg0KPiA+DQo+ID4gYW5kIG1v dmluZyBhbGwgZGlzY3Vzc2lvbiBvZiB1c2VyIHZlcmlmaWNhdGlvbiBpbnRvIFNlY3Rpb25zIDYu MSBhbmQgNi4yLg0KPiANCj4gU29ycnksIEkgZG9uJ3QgdGhpbmsgdGhhdCBpcyBuZWVkZWQgYXQg YWxsLiBUaGUgY3VycmVudCB0ZXh0IHNpbXBseQ0KPiByZWZsZWN0cyB0aGUga2luZCBvZiB0aGlu ZyB0aGF0IHdlIHRoaW5rIGRlcGxveW1lbnRzIHdpbGwgZG8gYW5kIHdpbGwNCj4gbmVlZCB0byBk byBhbmQgSSBkb24ndCBzZWUgd2hhdCBzcGVjaWZpYyB3ZWFrbmVzc2VzIHlvdSBhcmUgY2xhaW1p bmcNCj4gbWlnaHQgZW5zdWUuIEknZCBiZSBoYXBweSB0byBub3RlIGFueSBzdWNoIG9mIGNvdXJz ZS4NCj4gDQo+IEFsc28sIGZyb20gbXkgcmVhZGluZyB5b3VyIHN1Z2dlc3RlZCB0ZXh0IGhhcyB0 aGUgc2FtZSBpbXBhY3QgYW5kDQo+IG9ubHkgZGlmZmVycyBpbiB1c2luZyBhIDIxMTkgTUFZIGlu c3RlYWQgb2YgY291bGQsIG1pZ2h0IGV0Yy4gQnV0IGlmDQo+IHlvdSBtZWFudCBpdCB0byBkaWZm ZXIgbW9yZSBzdWJzdGFudGl2ZWx5IHlvdSdsbCBuZWVkIHRvIGV4cGxhaW4gdGhhdA0KPiB0byBt ZSBzb21lIG1vcmUuDQo+IA0KPiA+DQo+ID4gLS0gTWlub3IgaXNzdWVzOiAtLQ0KPiA+DQo+ID4g W0FdIEFCTkYgZW5jb2Rpbmcgb2YgYWxnDQo+ID4NCj4gPiBJbiBzZWN0aW9uIDIsIEkgc2VlOg0K PiA+DQo+ID4gICAgYWxnID0gMSoyRElHSVQNCj4gPg0KPiA+ICAgIG8gIGFsZzogc3BlY2lmaWVz IHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtIGJlaW5nIHVzZWQgZW5jb2RlZCBhcyBhbg0KPiA+ICAg ICAgIEFTQ0lJIGNoYXJhY3RlciBhcyBkZWZpbmVkIGluIFNlY3Rpb24gOS4zLg0KPiA+DQo+ID4g U2VjdGlvbiA5LjMgc3BlY2lmaWVzIGEgc2luZ2xlIGRpZ2l0LiAgSG93IGRvZXMgdGhhdCBiZWNv bWUgMSoyRElHSVQgPw0KPiANCj4gSHVoPyBUaGUgY3VycmVudCBhbGdzIG9ubHkgdXNlIG9uZSBk aWdpdCwgYnV0IHRoZSBhYm5mIGFsbG93cyBmb3INCj4gbW9yZS4gTm90aGluZyBvZGQgdGhlcmUg dGhhdCBJIGNhbiBzZWUuDQo+IA0KPiA+IEkgc3VnZ2VzdDogImFzIGFuIEFTQ0lJIGNoYXJhY3Rl ciIgLT4gImFzIG9uZSBvciB0d28gQVNDSUkgZGlnaXRzIGJhc2VkDQo+ID4gb24gdGhlIElBTkEg cmVnaXN0cnkgZXN0YWJsaXNoZWQgYnkgU2VjdGlvbiA5LjMiDQo+IA0KPiBJIHRoaW5rIGl0J3Mg b2sgYXMgaXMuDQo+IA0KPiA+IFRoaXMgbWF5IHNlZW0gbGlrZSBhIG5pdCwgYnV0IGFueSBpbXBy ZWNpc2lvbiBpbiBzaWduYXR1cmUgYWxnb3JpdGhtDQo+ID4gaW5wdXQgY2FuIGxlYWQgdG8gaW50 ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcy4NCj4gDQo+IFllcyBpdCBjYW4uIEJ1dCB3ZSdyZSBub3Qg YmVpbmcgaW1wcmVjaXNlIHRoYXQgSSBjYW4gc2VlLg0KPiANCj4gPg0KPiA+IFtCXSBTZWN0aW9u IDUuMyAtIENQSyB2cy4ga2lkDQo+ID4NCj4gPiAgICBJbiB0aGUgYXV0aGVudGljYXRpb24gcGhh c2UsIHRoZSBzZXJ2ZXIgZXh0cmFjdHMgdGhlIENQSyBmcm9tIHRoZQ0KPiA+ICAgIHNpZ25pbmcg cGhhc2UgYW5kIGRlY2lkZXMgaWYgaXQgcmVjb2duaXplcyB0aGUgQ1BLLiAgSWYgdGhlIHNlcnZl cg0KPiA+ICAgIHJlY29nbml6ZXMgdGhlIENQSywgdGhlIHNlcnZlciBtYXkgZmluaXNoIHRoZSBj bGllbnQgYXV0aGVudGljYXRpb24NCj4gPiAgICBwcm9jZXNzLg0KPiA+DQo+ID4gVGhhdCBzZWVt cyB3cm9uZy4gIElJVUMsIHRoZSBIT0JBIGNsaWVudCBzZW5kczoNCj4gPg0KPiA+ICAgIEhPQkEt UkVTID0ga2lkICIuIiBjaGFsbGVuZ2UgIi4iIG5vbmNlICIuIiBzaWcNCj4gPg0KPiA+IElmIHNv LCBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoZSBzZXJ2ZXIgZXh0cmFjdHMgYSBDUEsgZnJvbSB0 aGF0Lg0KPiANCj4gVmlhIHRoZSBraWQgeWVzLg0KPiANCj4gPg0KPiA+IEkgc3VzcGVjdCB0aGF0 IHdoYXQgd2FzIGludGVuZGVkIGlzIHRoYXQgdGhlIHNlcnZlciBleHRyYWN0cyBhIGtleQ0KPiBp ZGVudGlmaWVyDQo+ID4gKGtpZCkgYW5kIHRoZW4gZGV0ZXJtaW5lcyBhKSB3aGV0aGVyIGl0IGtu b3dzIGEgQ1BLIGZvciB0aGF0IGtpZCBhbmQgYikNCj4gd2hldGhlcg0KPiA+IGl0IGFsbG93cyB1 c2Ugb2YgdGhhdCBraWQvQ1BLIGZvciB0aGlzIGF1dGhlbnRpY2F0aW9uLiAgQXQgbGVhc3QgYSkg c2VlbXMgdG8NCj4gPiBiZSBpbmRpY2F0ZWQgYnkgdGhpcyB0ZXh0IGluIFNlY3Rpb24gMzoNCj4g Pg0KPiA+ICAgIFRoZSBzZXJ2ZXIgTVVTVCBjaGVjayB0aGUgY3J5cHRvZ3JhcGhpYyBjb3JyZWN0 bmVzcyBvZiB0aGUgc2lnbmF0dXJlDQo+ID4gICAgYmFzZWQgb24gYSBwdWJsaWMga2V5IGl0IGtu b3dzIGZvciB0aGUga2lkIGluIHRoZSBzaWduYXR1cmVzLA0KPiANCj4gSSdtIG5vdCBzZWVpbmcg YW4gYWN0aW9uYWJsZSBpc3N1ZSB0aGF0IG5lZWRzIGEgY2hhbmdlLg0KPiANCj4gPg0KPiA+IFtD XSBSU0Egc2lnbmF0dXJlIGFsZ29yaXRobQ0KPiA+DQo+ID4gU2VjdGlvbiA3IHNheXM6DQo+ID4N Cj4gPiAgICBSU0EgaXMgZGVmaW5lZCBpbg0KPiA+ICAgIFNlY3Rpb24gOC4yIG9mIFtSRkMzNDQ3 XSwgYW5kIFNIQS0xIGFuZCBTSEEtMjU2IGFyZSBkZWZpbmVkIGluIFtTSFNdLg0KPiA+DQo+ID4g U2VjdGlvbiA4LjIgb2YgUkZDIDM0NDcgc3BlY2lmaWVzIFJTQVNTQS1QS0NTMS12MV81LiAgQXQg YSBtaW5pbXVtLCB0aGF0DQo+ID4gYWxnb3JpdGhtIG5hbWUgc2hvdWxkIGJlIHN0YXRlZCBoZXJl ICh3aGljaCBpcyBhIG5pdCkuDQo+IA0KPiBEaXNhZ3JlZSAoYWxzbyBhcyBhIG5pdDotKQ0KPiAN Cj4gPiBUaGUgbWlub3IgaXNzdWUgaXMNCj4gPiB3aGV0aGVyIHRoYXQgaXMgdGhlIHNpZ25hdHVy ZSBhbGdvcml0aG0gdGhhdCdzIHdhbnRlZCwgb24gd2hpY2ggSSdsbCBkZWZlcg0KPiA+IHRvIHRo ZSBjcnlwdG8gZXhwZXJ0cyBvbiB0aGF0IChlLmcuLCBJIHNlZW0gdG8gcmVjYWxsIGEgbmVnYXRp dmUgc2FhZw0KPiA+IGNvbW1lbnQgb24gUEtDUyAxLjUgbWVjaGFuaXNtcyBpbiB0aGUgcGFzdCBj b3VwbGUgb2YgbW9udGhzKS4NCj4gDQo+IFllcywgaXQncyBmaW5lIGZvciBzZWN1cml0eSBhbmQg aXMgY29ycmVjdCBmb3IgaW50ZXJvcC9kZXBsb3ltZW50DQo+IHJlYXNvbnMuIFBLQ1N2MS41IGVu Y3J5cHRpb24gaXMgd2hhdCdzIGxlc3MgZGVzaXJhYmxlIGlmIG5vdCBkb25lDQo+IHdlbGwgYW5k IGF0dGVtcHRpbmcgdG8gbWFuZGF0ZSBQU1MgaGVyZSB3b3VsZCBiZSBhIGJhZCBwbGFuLg0KPiAN Cj4gPg0KPiA+IFtEXSBKYXZhc2NyaXB0IGxvY2FsIHN0b3JhZ2UuDQo+ID4NCj4gPiBUaGUgZmly c3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gOC4yIG9uIHRoaXMgdG9waWMgY29uY2x1ZGVzIHdpdGg6 DQo+ID4NCj4gPiAgICBJdCdzIG5vdCBjbGVhciB0aGF0IHdlDQo+ID4gICAgaW50cm9kdWNlIHVu aXF1ZSB0aHJlYXRzIGZyb20gd2hpY2ggY2xlYXIgdGV4dCBwYXNzd29yZHMgZG9uJ3QNCj4gPiAg ICBhbHJlYWR5IHN1ZmZlci4NCj4gPg0KPiA+IFRoYXQncyBhdCBvZGRzIHdpdGggdGhlIHVzZSBv ZiAiYWxsIiBpbiB0aGlzIHNlbnRlbmNlIGluIHRoZSBhYnN0cmFjdDoNCj4gPg0KPiA+ICAgIEhP QkEgaXMgYW4NCj4gPiAgICBhbHRlcm5hdGl2ZSB0byBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVt ZXMgdGhhdCByZXF1aXJlIHBhc3N3b3JkcyBhbmQNCj4gPiAgICB0aGVyZWZvcmUgYXZvaWRzIGFs bCBwcm9ibGVtcyByZWxhdGVkIHRvIHBhc3N3b3Jkcywgc3VjaCBhcyBsZWFrYWdlDQo+ID4gICAg b2Ygc2VydmVyLXNpZGUgcGFzc3dvcmQgZGF0YWJhc2VzLg0KPiA+DQo+ID4gT25lIG9mIHRob3Nl IHR3byBwYXJhZ3JhcGhzIG5lZWRzIHNvbWUgZWRpdGluZy4NCj4gDQo+IEkgZG9uJ3QgdGhpbmsg c28gYWN0dWFsbHksIHRoZSBmaXJzdCBxdW90ZWQgc2VudGVuY2UgYWJvdmUgaXMgaW4gdGhlDQo+ IGNvbnRleHQgb2YgYSB3ZWIgc2l0ZSB3aXRoIFhTUyB2dWxuZXJhYmlsaXRpZXMuIE9taXR0aW5n IHRoYXQgY29udGV4dA0KPiB3b3VsZCBtYWtlIGZvciBiYWQgdGV4dCwgYnV0IHRoZSBpbW1lZGlh dGVseSBwcmVjZWRpbmcgc2VudGVuY2UgaXMNCj4gZmFpcmx5IGV4cGxpY2l0IG9uIHRoYXQuDQo+ IA0KPiAoSW4gcGFzc2luZywgSSBkaWQgZWRpdCB0aGUgdG9wIG9mIHRoYXQgcGFyYSBhIGJpdCwg c2luY2UgdXNpbmcgdGhlDQo+IFdlYkNyeXB0byBBUEkgaXMgbm93IHBvc3NpYmxlIHNvIGEgdHdl YWsgd2FzIG5lZWRlZC4pDQo+IA0KPiA+DQo+ID4gLS0gTml0cy9lZGl0b3JpYWwgY29tbWVudHM6 IC0tDQo+ID4NCj4gPiBUaGlzIGlzIGJ1cmllZCBuZWFyIHRoZSBlbmQgb2Ygc2VjdGlvbiA2LjEN Cj4gPg0KPiA+ICAgIE5vdGUgdGhhdCByZXBsYXkgb2YgcmVnaXN0cmF0aW9uIChhbmQgb3RoZXIg SE9CQSkgbWVzc2FnZXMgaXMgcXVpdGUNCj4gPiAgICBwb3NzaWJsZS4gIFRoYXQgaG93ZXZlciBj YW4gYmUgY291bnRlcmFjdGVkIGlmIGNoYWxsZW5nZSBmcmVzaG5lc3MgaXMNCj4gPiAgICBlbnN1 cmVkLg0KPiA+DQo+ID4gVGhhdCdzIG5vdCBhIGdvb2QgcGxhY2UgZm9yIHRoZXNlIHR3byBzZW50 ZW5jZXMuICBIT0JBIHJlZ2lzdHJhdGlvbg0KPiA+IG1lc3NhZ2VzIGRvbid0IGNvbnRhaW4gYSBj aGFsbGVuZ2UsIGFuZCB0aGUgZ2VuZXJhbCBkaXNjdXNzaW9uIG9mDQo+ID4gcmVwbGF5IGF0dGFj a3MgYmVsb25ncyB1bmRlciBTZWN1cml0eSBDb25zaWRlcmF0aW9ucywgbm90IFJlZ2lzdHJhdGlv bi4NCj4gDQo+IFRoZXkgZG8gY29udGFpbiBhIGNoYWxsZW5nZSBpbiB0aGUgaGVhZGVyLCB0aG91 Z2ggbm90IGluIHRoZSBib2R5Lg0KPiBJIHRoaW5rIHRoZSBzZW50ZW5jZSBpcyBvayB3aGVyZSBp dCBpcy4NCj4gDQo+ID4NCj4gPiBJbiBTZWN0aW9uIDkuNCBhbmQgOS41LCBJIHNlZSB0aGUgZm9s bG93aW5nIHByb3Bvc2VkIGFzIHBhcnQgb2YgSUFOQQ0KPiA+IHJlZ2lzdHJ5IGNvbnRlbnRzOg0K PiA+DQo+ID4gCWFuIHVuZm9ybWF0dGVkIHN0cmluZywgYXQgdGhlIHVzZXIncy9VQSdzIHdoaW0N Cj4gPg0KPiA+IEkgZ2V0IHRoZSBwb2ludCwgYnV0IGl0J3Mgc3RpbGwgbm90IGFwcHJvcHJpYXRl IGZvciBhbiBJQU5BIHJlZ2lzdHJ5DQo+ID4gLSByZW1vdmUgIiwgYXQgdGhlIHVzZXIncy9VQSdz IHdoaW0iLg0KPiANCj4gSSB3aGltc2ljYWxseSBkaXNhZ3JlZTotKSBJQU5BIHNob3VsZG4ndCBi ZSBhZ2FpbnN0IHdoaW1zeS4NCj4gDQo+ID4gQXBwZW5kaXggQSBhcHBlYXJzICB0byBhc3N1bWUg dGhhdCBodW1hbi1tZW1vcmFibGUgcGFzc3dvcmRzIGFyZSBzdG9yZWQgaW4NCj4gPiB0aGUgY2xl YXIgaW4gc2VydmVyIGRhdGFiYXNlcy4gIEl0IHNob3VsZCBhbHNvIGJyaWVmbHkgZGlzY3VzcyB0 aGUgdXNlDQo+ID4gb2Ygb25lLXdheSBmdW5jdGlvbnMsIGVzcGVjaWFsbHkgY29tcHV0YXRpb25h bGx5IGludGVuc2l2ZSBvbmVzLCB0bw0KPiA+IGdlbmVyYXRlIHN0b3JlZCBwYXNzd29yZCB2ZXJp ZmllcnMuICBIT0JBIGlzIHN0aWxsIHN1cGVyaW9yIGJ5IGNvbXBhcmlzb24sDQo+ID4gYXMgdGhl IG9uZS13YXkgZnVuY3Rpb25zIG9ubHkgaW5jcmVhc2UgdGhlIGRpZmZpY3VsdHkgb2YgZGljdGlv bmFyeQ0KPiA+IGF0dGFjaywgd2hlcmVhcyBkaWN0aW9uYXJ5IGF0dGFjayBvbiBIT0JBIGtleXMg aXMgcG9pbnRsZXNzIHdoZW4NCj4gPiBzdWZmaWNpZW50bHkgbGFyZ2Uga2V5cyBhcmUgdXNlZC4N Cj4gDQo+IEknZCBwcmVmZXIgdG8gbm90IGdldCBpbnRvIG1vcmUgYW5hbHlzaXMgb2YgcGFzc3dv cmRzLCBhbmQgZXZlbiBoYXNoZWQNCj4gcGFzc3dvcmRzIGFyZSBlc3NlbnRpYWxseSBndWVzc2Fi bGUuDQo+IA0KPiA+DQo+ID4gaWRuaXRzIDIuMTMuMDEgZm91bmQgdGhlIHJlZmVyZW5jZXMgdG8g VzNDJ3Mgd2ViIHNpdGUgKHd3dy53My5vcmcpIGluDQo+ID4gU2VjdGlvbiA0LCBlLmcuLA0KPiA+ DQo+ID4gMzg5CSAgIE9uZSBlbGVtZW50IGlzIHJlcXVpcmVkIGZvciBIT0JBLWpzOiBsb2NhbFN0 b3JhZ2UgKHNlZSBodHRwOi8vDQo+ID4gMzkwCSAgIHd3dy53My5vcmcvVFIvd2Vic3RvcmFnZS8p IGZyb20gSFRNTDUgY2FuIGJlIHVzZWQgZm9yIHBlcnNpc3RlbnQga2V5DQo+ID4gMzkxCSAgIHN0 b3JhZ2UuDQo+ID4NCj4gPiBJIHRoaW5rIGlkbml0cyBjYW4gYmUgaWdub3JlZCwgZXZlbiB0aG91 Z2ggdGhlICJyaWdodCB3YXkiIHRvIGZpeCB0aGlzIGlzIHRvDQo+ID4gbW92ZSBlYWNoIFVSTCB0 byBhIHJlZmVyZW5jZSBhbmQgY2l0ZSB0aGUgcmVmZXJlbmNlIGluIFNlY3Rpb24gNC4NCj4gPg0K PiA+IE9UT0gsIGlkbml0cyBkaWQgbm90IGNvbXBsYWluIGFib3V0IHRoZSBub3JtYXRpdmUgcmVm ZXJlbmNlIHRvIFJGQyAyMCA7LSkuDQo+IA0KPiBIZWg6LSkNCj4gDQo+ID4NCj4gPiAtLS0gU2Vs ZWN0ZWQgUkZDIDU3MDYgQXBwZW5kaXggQSBRJkEgZm9yIE9QUy1EaXIgcmV2aWV3IC0tLQ0KPiA+ DQo+ID4gTW9zdCBvZiB0aGVzZSBxdWVzdGlvbnMgYXJlIG4vYSBiZWNhdXNlIHRoaXMgZHJhZnQg ZGVzY3JpYmVzIGFuIGV4dGVuc2lvbg0KPiA+IHRvIEhUVFAgYXV0aGVudGljYXRpb24sIGFuZCBS RkMgNTcwNidzIGNvbmNlcm5zIHdvdWxkIGFwcGx5IHByaW1hcmlseSB0bw0KPiA+IEhUVFAgYW5k IEhUVFAgYXV0aGVudGljYXRpb24uDQo+ID4NCj4gPiBBLjEuMSAgICBIYXMgZGVwbG95bWVudCBi ZWVuIGRpc2N1c3NlZD8NCj4gPg0KPiA+IFllcywgc2VjdGlvbiA2IGRpc2N1c3NlcyBob3cgYSB1 c2VyIHdvdWxkIGRlcGxveSB0aGlzIGZvciBoZXIgYWNjZXNzIHRvIHdlYg0KPiA+IHNlcnZlcnMu DQo+ID4NCj4gPiBBLjEuNC4gIEhhdmUgdGhlIFJlcXVpcmVtZW50cyBvbiBvdGhlciBwcm90b2Nv bHMgYW5kIGZ1bmN0aW9uYWwNCj4gPiAgICAgICAgY29tcG9uZW50cyBiZWVuIGRpc2N1c3NlZD8N Cj4gPg0KPiA+IFllcywgdGhlIGRpc2N1c3Npb24gb2YgaG93IHRoaXMgZnVuY3Rpb25zIHdpdGhp biBIVFRQIGlzIHN1ZmZpY2llbnQuDQo+ID4NCj4gPiBNYWpvciBpc3N1ZXMgWzNdIGFuZCBbNF0g ZmFsbCBpbnRvIHRoaXMgY2F0ZWdvcnksIGJ1dCBpbiBib3RoIGNhc2VzLA0KPiA+IEkgdGhpbmsg dGhleSdyZSBwcm9iYWJseSB0ZXh0IG92ZXJzaWdodHMgdGhhdCBhcmUgZWFzeSB0byBmaXguDQo+ ID4NCj4gPiBBLjIuNyBJcyBzZWN1cml0eSBtYW5hZ2VtZW50IGRpc2N1c3NlZD8NCj4gPg0KPiA+ IE5vdCByZWFsbHksIGJ1dCB0aGlzIGlzIGFuIEV4cGVyaW1lbnRhbCBSRkMuICBJIHdvdWxkIGV4 cGVjdCB0aGF0IHRoZQ0KPiA+IGV4cGVyaW1lbnRhbCB1c2Ugb2YgSE9CQSB3aWxsIHlpZWxkIGlu c2lnaHQgaW50byBzZXJ2ZXIga2V5IGRhdGFiYXNlDQo+ID4gc3RydWN0dXJlL21hbmFnZW1lbnQs IGtleSBsaWZlY3ljbGUgbWFuYWdlbWVudCAoZS5nLiwgcmV2b2NhdGlvbiksDQo+ID4gYWNjb3Vu dCBtYW5hZ2VtZW50IHRlY2huaXF1ZXMvcHJvY2Vzc2VzLCBldGMuDQo+ID4NCj4gPiBBLjMuICBE b2N1bWVudGF0aW9uDQo+ID4NCj4gPiBJIGRvIG5vdCBleHBlY3Qgc2lnbmlmaWNhbnQgb3BlcmF0 aW9uYWwgaW1wYWN0Lg0KPiA+DQo+ID4gU2VjdGlvbiAxMCBub3RlcyB0aGUgZXhpc3RlbmNlIG9m IHR3byBpbXBsZW1lbnRhdGlvbnMgb2YgSE9CQS1KUyBhbmQNCj4gPiBvbmUgaW1wbGVtZW50YXRp b24gb2YgSE9CQS1odHRwLiAgVGhhdCdzIGEgZ29vZCBzdGFydCBmb3IgYW4gZXhwZXJpbWVudC4N Cj4gDQo+IEFuZCBub3cgdGhlcmUncyBhIDNyZCENCj4gDQo+IFRoYW5rcyBhZ2FpbiBmb3IgdGhl IGZpbmUgcmV2aWV3LA0KPiBTLg0KPiANCj4gDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gLS1EYXZp ZA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gPiBEYXZpZCBMLiBCbGFjaywgRGlzdGluZ3Vpc2hlZCBFbmdpbmVlcg0KPiA+IEVNQyBD b3Jwb3JhdGlvbiwgMTc2IFNvdXRoIFN0LiwgSG9wa2ludG9uLCBNQSAgMDE3NDgNCj4gPiArMSAo NTA4KSAyOTMtNzk1MyAgICAgICAgICAgICBGQVg6ICsxICg1MDgpIDI5My03Nzg2DQo+ID4gZGF2 aWQuYmxhY2tAZW1jLmNvbSAgICAgICAgTW9iaWxlOiArMSAoOTc4KSAzOTQtNzc1NA0KPiA+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0K PiA+DQo+ID4NCg== From nobody Wed Dec 24 11:29:14 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962381A1A5B; Wed, 24 Dec 2014 11:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmJx8l1oHyvX; Wed, 24 Dec 2014 11:29:10 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2BD1A1A3D; Wed, 24 Dec 2014 11:29:09 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id i50so5908931qgf.38; Wed, 24 Dec 2014 11:29:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l5v1bkp0d5dsmdNl1lhlaeJD7xCA8FNFBht1JtUnblo=; b=rV1+qowDeBReZEvc6Hgy71QHoH30DPhGIh9UrAldmK4KzgMXHbqyFf9hIYrc3x2OmV hfd84QQKvsJcxnD99+MZslh4WMCqvNTr43gKp4RAmix+RgkcAbu5Wh1DCjtVWcPpWGiX NyrhErPQGTsj+tVA6LwnKk477PwoOvXABQ8eqSJjc/6FbJqRLZ+ZRCh9lFYZHhRpOkcz Hm/QquOhBmqRdQjRhY7nAzlPUcEow4PWu/eGG1iBY/KNZuG9CmRXCx/bJCMoCfSTZwU1 Jt+WklYWSs/zTu4BUvRY/8aZum1jl6QGCJynha3wu8N6IYX5r2X+VXTRMCUcTyoQk8E8 WXTg== X-Received: by 10.229.35.74 with SMTP id o10mr37466846qcd.26.1419449349160; Wed, 24 Dec 2014 11:29:09 -0800 (PST) Received: from [10.0.1.6] (ool-18bd99b2.dyn.optonline.net. [24.189.153.178]) by mx.google.com with ESMTPSA id i76sm21985974qgd.4.2014.12.24.11.29.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Dec 2014 11:29:07 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Wed, 24 Dec 2014 14:29:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141210142247.26304.96086.idtracker@ietfa.amsl.com> <549AA031.4040302@cs.tcd.ie> <549AA3BD.2010206@isode.com> <549AA553.2080606@cs.tcd.ie> To: Barry Leiba Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/dALozLf6-kKN_EB1GcYzDQ9mngI Cc: "httpauth-chairs@tools.ietf.org" , Pearl Liang via RT , "http-auth@ietf.org" , IESG , "draft-ietf-httpauth-hoba@tools.ietf.org" Subject: Re: [http-auth] [IANA #798267] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 19:29:11 -0000 Thanks for the discussion on this. We'll make sure the expert review happen= s before I add a ballot and I'll move this out further if needed. The draft= is on the agenda for 1/8 right now. Best regards, Kathleen=20 Sent from my iPhone On Dec 24, 2014, at 12:49 PM, Barry Leiba wrote: >>> If someone should want to submit a document to change the registration >>> policy to exempt registrations made from IETF consensus documents from >>> expert review, someone certainly could do that. >>=20 >> Wouldn't that be part of 5226bis if it were what we wanted? >=20 > Perhaps, but it's clearly not what we want, in general (see below). > And 5226bis does suggest using combinations of policies to handle > this, combinations such as "IETF Review or Expert Review" (see Section > 2.3.2). >=20 >> As to the (minor) substance here I'd suggest that experts be consulted >> but non blocking for ietf consensus docs I think. Adding unexpected >> twists like this at the end of the process is bad in general >=20 > This is not an unexpected twist: anyone looking at the registration > policy can clearly see that it requires expert review, and nothing > indicates an exception for IETF consensus documents. Further, as to > your first sentence (and my "see below" above), I have pushed back, in > IESG Evaluation, on expert review policies, asking if they wanted to > make an exception for IETF consensus documents. In every case where I > pushed back, they did *not*. They always wanted to get the designated > experts involved to make sure things looked right. >=20 > This actually makes sense, because in many cases it's possible -- even > likely -- that registrations will be requested by authors, working > groups, or other sub-communities who are not experts in the ins and > outs of the particular registry involved, and the creators of the > registry want to make sure that someone who *is* gives the > registration request at least a once-over. >=20 > Barry >=20 From nobody Wed Dec 24 12:03:21 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B9A1A1A74; Wed, 24 Dec 2014 12:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5PSZR4Tu7n3; Wed, 24 Dec 2014 12:03:17 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1856C1A1A72; Wed, 24 Dec 2014 12:03:17 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so7466934lab.34; Wed, 24 Dec 2014 12:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+Euf422auaTx+oZ0if7o+KOvKWpRUgKN61rI10BWgtM=; b=D0Kl9gpLBxrfxfOL4IrlMGMRJ+Wwar7DJNSTOji9yrpuFmRS9K9rQ7crK87bQQK9V+ riZKEZXWB0DwwN1OQ73Nwsjbgccc5d3Ppn49nMxAXlCmBFVBSpmlsvyvtworhODd2NWh mcPYHINxPjP0nYGjW01HRAmEUUPtV9iae8TUaEF8oUlzoOqD/i/QxtV8SkMGguaS+yEg 08AUqS8jFTiL9i89WJZek2WHbObmjZKqWYT7ItEhIvyktoTB1CoQ+SuJ+HCUIBY0nogm u/hKCAIVzFhOx+/ifz5FULRk2n3fcnNQmUjVEzMv7JFymQK5oKynq4OpREX32do2Agpz 1l1Q== MIME-Version: 1.0 X-Received: by 10.112.72.197 with SMTP id f5mr12753802lbv.21.1419451395515; Wed, 24 Dec 2014 12:03:15 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Wed, 24 Dec 2014 12:03:15 -0800 (PST) In-Reply-To: References: <20141210142247.26304.96086.idtracker@ietfa.amsl.com> <549AA031.4040302@cs.tcd.ie> <549AA3BD.2010206@isode.com> <549AA553.2080606@cs.tcd.ie> Date: Wed, 24 Dec 2014 15:03:15 -0500 X-Google-Sender-Auth: sN8lTmWiWZKn5ZEh8Umu0biC3tc Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a11c23d8a34ac79050afbc8da Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/aSIgvFUgDjOrw7-ur5EI2BvEqbI Cc: "httpauth-chairs@tools.ietf.org" , Pearl Liang via RT , "http-auth@ietf.org" , IESG , "draft-ietf-httpauth-hoba@tools.ietf.org" Subject: Re: [http-auth] [IANA #798267] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 20:03:19 -0000 --001a11c23d8a34ac79050afbc8da Content-Type: text/plain; charset=ISO-8859-1 I wouldn't wait on the ballot. The substance of the document probably won't change significantly. Barry On Wednesday, December 24, 2014, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Thanks for the discussion on this. We'll make sure the expert review > happens before I add a ballot and I'll move this out further if needed. > The draft is on the agenda for 1/8 right now. > > Best regards, > Kathleen > > Sent from my iPhone > > On Dec 24, 2014, at 12:49 PM, Barry Leiba > wrote: > > >>> If someone should want to submit a document to change the registration > >>> policy to exempt registrations made from IETF consensus documents from > >>> expert review, someone certainly could do that. > >> > >> Wouldn't that be part of 5226bis if it were what we wanted? > > > > Perhaps, but it's clearly not what we want, in general (see below). > > And 5226bis does suggest using combinations of policies to handle > > this, combinations such as "IETF Review or Expert Review" (see Section > > 2.3.2). > > > >> As to the (minor) substance here I'd suggest that experts be consulted > >> but non blocking for ietf consensus docs I think. Adding unexpected > >> twists like this at the end of the process is bad in general > > > > This is not an unexpected twist: anyone looking at the registration > > policy can clearly see that it requires expert review, and nothing > > indicates an exception for IETF consensus documents. Further, as to > > your first sentence (and my "see below" above), I have pushed back, in > > IESG Evaluation, on expert review policies, asking if they wanted to > > make an exception for IETF consensus documents. In every case where I > > pushed back, they did *not*. They always wanted to get the designated > > experts involved to make sure things looked right. > > > > This actually makes sense, because in many cases it's possible -- even > > likely -- that registrations will be requested by authors, working > > groups, or other sub-communities who are not experts in the ins and > > outs of the particular registry involved, and the creators of the > > registry want to make sure that someone who *is* gives the > > registration request at least a once-over. > > > > Barry > > > > --001a11c23d8a34ac79050afbc8da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I wouldn't wait on the ballot.=A0 The substance of the document probabl= y won't change significantly.

Barry

On Wednes= day, December 24, 2014, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Thanks for the discussion on this.=A0 We'= ll make sure the expert review happens before I add a ballot and I'll m= ove this out further if needed.=A0 The draft is on the agenda for 1/8 right= now.

Best regards,
Kathleen

Sent from my iPhone

On Dec 24, 2014, at 12:49 PM, Barry Leiba <barryl= eiba@computer.org> wrote:

>>> If someone should want to submit a document to change the regi= stration
>>> policy to exempt registrations made from IETF consensus docume= nts from
>>> expert review, someone certainly could do that.
>>
>> Wouldn't that be part of 5226bis if it were what we wanted? >
> Perhaps, but it's clearly not what we want, in general (see below)= .
> And 5226bis does suggest using combinations of policies to handle
> this, combinations such as "IETF Review or Expert Review" (s= ee Section
> 2.3.2).
>
>> As to the (minor) substance here I'd suggest that experts be c= onsulted
>> but non blocking for ietf consensus docs I think. Adding unexpecte= d
>> twists like this at the end of the process is bad in general
>
> This is not an unexpected twist: anyone looking at the registration > policy can clearly see that it requires expert review, and nothing
> indicates an exception for IETF consensus documents.=A0 Further, as to=
> your first sentence (and my "see below" above), I have pushe= d back, in
> IESG Evaluation, on expert review policies, asking if they wanted to > make an exception for IETF consensus documents.=A0 In every case where= I
> pushed back, they did *not*.=A0 They always wanted to get the designat= ed
> experts involved to make sure things looked right.
>
> This actually makes sense, because in many cases it's possible -- = even
> likely -- that registrations will be requested by authors, working
> groups, or other sub-communities who are not experts in the ins and > outs of the particular registry involved, and the creators of the
> registry want to make sure that someone who *is* gives the
> registration request at least a once-over.
>
> Barry
>

--001a11c23d8a34ac79050afbc8da-- From nobody Wed Dec 24 12:06:40 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B35F1A1A88; Wed, 24 Dec 2014 12:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaLfhc42xUcz; Wed, 24 Dec 2014 12:06:35 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305771A1A74; Wed, 24 Dec 2014 12:06:35 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id c9so6042167qcz.24; Wed, 24 Dec 2014 12:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U1AyVpaemxufRGC2CJFzxXQ6lSJ8EBh69PDGY+meEjE=; b=qthSnHWjmGF4rHV2DxX4VtJPctT0hy/I1lqTqkfJB411TcuCeH9FLzjD7HwtBGSS6j V1gmb2ab+xoIYpi0k+3RvhgRo9zaELshQnnQ9dtx3f9SQUZ8y4Ck/0EPrwfwhKVb2NQn bxT3FSFtr7IeVm6an1KR4MVSf2CKmlzuDC4IKw6BtwzmoWY3wUBE6gTonU+AYw0749IZ vAvYrP70DaWu0oKAxLv+mgVLW9e+G3/SuWdf1BNWjwVbYRtQROJ3FlPxW9YJkQgzcBy6 VdKj5QGoX4Wwzfm3ws+C9weijquoYConkZ5wDn0OwcBQGJpnMS5gphyAiEtkOLcPfqtx 2J1g== X-Received: by 10.229.124.4 with SMTP id s4mr57299131qcr.11.1419451593967; Wed, 24 Dec 2014 12:06:33 -0800 (PST) Received: from [10.0.1.6] (ool-18bd99b2.dyn.optonline.net. [24.189.153.178]) by mx.google.com with ESMTPSA id w94sm8626730qgw.6.2014.12.24.12.06.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Dec 2014 12:06:32 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-22F8262E-AFB9-4E89-B171-42442D5257D6 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Wed, 24 Dec 2014 15:06:31 -0500 Content-Transfer-Encoding: 7bit Message-Id: <136CFA8F-0CEF-4ACC-A9C5-008A798A5692@gmail.com> References: <20141210142247.26304.96086.idtracker@ietfa.amsl.com> <549AA031.4040302@cs.tcd.ie> <549AA3BD.2010206@isode.com> <549AA553.2080606@cs.tcd.ie> To: Barry Leiba Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/F0Wxn_4vmfarjBHscmx-JSP4814 Cc: "httpauth-chairs@tools.ietf.org" , Pearl Liang via RT , "http-auth@ietf.org" , IESG , "draft-ietf-httpauth-hoba@tools.ietf.org" Subject: Re: [http-auth] [IANA #798267] Last Call: (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 20:06:37 -0000 --Apple-Mail-22F8262E-AFB9-4E89-B171-42442D5257D6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Dec 24, 2014, at 3:03 PM, Barry Leiba wrote: >=20 > I wouldn't wait on the ballot. The substance of the document probably won= 't change significantly. Ok, thanks. I'll just wait for the next revision as Stephen has changes he w= as confirming with reviewers. The ballot is ready to go, so it'll get poste= d once the draft is there, Thanks & merry Christmas, happy Chanukah, and happy Festivus for everyone el= se :-) Kathleen=20 >=20 > Barry >=20 >> On Wednesday, December 24, 2014, Kathleen Moriarty wrote: >> Thanks for the discussion on this. We'll make sure the expert review hap= pens before I add a ballot and I'll move this out further if needed. The dr= aft is on the agenda for 1/8 right now. >>=20 >> Best regards, >> Kathleen >>=20 >> Sent from my iPhone >>=20 >> On Dec 24, 2014, at 12:49 PM, Barry Leiba wrote= : >>=20 >> >>> If someone should want to submit a document to change the registratio= n >> >>> policy to exempt registrations made from IETF consensus documents fro= m >> >>> expert review, someone certainly could do that. >> >> >> >> Wouldn't that be part of 5226bis if it were what we wanted? >> > >> > Perhaps, but it's clearly not what we want, in general (see below). >> > And 5226bis does suggest using combinations of policies to handle >> > this, combinations such as "IETF Review or Expert Review" (see Section >> > 2.3.2). >> > >> >> As to the (minor) substance here I'd suggest that experts be consulted= >> >> but non blocking for ietf consensus docs I think. Adding unexpected >> >> twists like this at the end of the process is bad in general >> > >> > This is not an unexpected twist: anyone looking at the registration >> > policy can clearly see that it requires expert review, and nothing >> > indicates an exception for IETF consensus documents. Further, as to >> > your first sentence (and my "see below" above), I have pushed back, in >> > IESG Evaluation, on expert review policies, asking if they wanted to >> > make an exception for IETF consensus documents. In every case where I >> > pushed back, they did *not*. They always wanted to get the designated >> > experts involved to make sure things looked right. >> > >> > This actually makes sense, because in many cases it's possible -- even >> > likely -- that registrations will be requested by authors, working >> > groups, or other sub-communities who are not experts in the ins and >> > outs of the particular registry involved, and the creators of the >> > registry want to make sure that someone who *is* gives the >> > registration request at least a once-over. >> > >> > Barry >> > --Apple-Mail-22F8262E-AFB9-4E89-B171-42442D5257D6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Dec 24, 2014, at 3:03 PM, Barry Leiba <barryleiba@computer.org> wrote:

I wouldn't wait on the ballot.  The substance of= the document probably won't change significantly.
Ok, thanks.  I'll just wait for the next revision as Stephen ha= s changes he was confirming with reviewers.  The ballot is ready to go,= so it'll get posted once the draft is there,

Thanks &= ; merry Christmas, happy Chanukah, and happy Festivus for everyone else :-)<= /div>

Kathleen 


Barry

On Wednesday, December 24, 2014, K= athleen Moriarty <kat= hleen.moriarty.ietf@gmail.com> wrote:
barryleiba@computer.org<= /a>> wrote:

>>> If someone should want to submit a document to change the regis= tration
>>> policy to exempt registrations made from IETF consensus documen= ts from
>>> expert review, someone certainly could do that.
>>
>> Wouldn't that be part of 5226bis if it were what we wanted?
>
> Perhaps, but it's clearly not what we want, in general (see below).
= > And 5226bis does suggest using combinations of policies to handle
> this, combinations such as "IETF Review or Expert Review" (see Section<= br> > 2.3.2).
>
>> As to the (minor) substance here I'd suggest that experts be consul= ted
>> but non blocking for ietf consensus docs I think. Adding unexpected=
>> twists like this at the end of the process is bad in general
>
> This is not an unexpected twist: anyone looking at the registration
= > policy can clearly see that it requires expert review, and nothing
> indicates an exception for IETF consensus documents.  Further, as t= o
> your first sentence (and my "see below" above), I have pushed back, in<= br> > IESG Evaluation, on expert review policies, asking if they wanted to > make an exception for IETF consensus documents.  In every case whe= re I
> pushed back, they did *not*.  They always wanted to get the design= ated
> experts involved to make sure things looked right.
>
> This actually makes sense, because in many cases it's possible -- even<= br> > likely -- that registrations will be requested by authors, working
> groups, or other sub-communities who are not experts in the ins and
= > outs of the particular registry involved, and the creators of the
> registry want to make sure that someone who *is* gives the
> registration request at least a once-over.
>
> Barry
>

= --Apple-Mail-22F8262E-AFB9-4E89-B171-42442D5257D6-- From nobody Fri Dec 26 15:40:37 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16EB1ACFD1; Fri, 26 Dec 2014 15:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPzfLrngvUiQ; Fri, 26 Dec 2014 15:40:24 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB171ACFD0; Fri, 26 Dec 2014 15:40:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0AB61BF13; Fri, 26 Dec 2014 23:40:22 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RwJaUC6NnYN; Fri, 26 Dec 2014 23:40:18 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.41.53.28]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 925B5BF11; Fri, 26 Dec 2014 23:40:17 +0000 (GMT) Message-ID: <549DF1E1.3080308@cs.tcd.ie> Date: Fri, 26 Dec 2014 23:40:17 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Black, David" , "paul.hoffman@vpnc.org" , "mike@phresheez.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" References: <549AA03C.5070107@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/hXB2_6g_pu97igpG60hIdZsua_c Cc: "http-auth@ietf.org" , "ietf@ietf.org" Subject: Re: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2014 23:40:31 -0000 Hi David, Again thanks for the follow up... On 24/12/14 18:40, Black, David wrote: > Hi Stephen, > > Thanks for the response and initial updates - anything that I don't comment > on further is fine, and everything in this response should now be reduced to > requests for minor additional text changes: > >>> [2] Challenge verification and reuse >>> >>> This sentence on p.6 strikes me as subtly dangerous: >>> >>> The challenge however is sent over >>> the network so as to make it simpler for a server to be stateless. >>> (One form of stateless challenge might be a ciphertext that the >>> server decrypts and checks, but that is an implementation detail.) >>> >>> The draft elsewhere asserts or assumes that challenge reuse can be >>> prevented by the server or be time-bounded by max-age, and relies on >>> those reuse limits for security properties, > > [... snip ...] > >> Hmm. I think that HOBA ought not REQUIRE full replay protection >> in all cases, that is, it SHOULD be possible to deploy a server >> that is vulnerable to some replay. The reason is that we're trying >> to displace passwords here and I believe (without much hard evidence >> I'll grant you) that we'd lose some deployment chances if we were >> to insist on every single challenge being fresh. >> >> So I'd argue for no-change here, but would welcome further discussion >> evidence or suggestions for text that's not going to be so onerous >> as to weaken our chances of getting this deployed. > > The word "stateless" is bothering me, That's HTTP for ya:-) > as doing a good job of replay > prevention usually requires saving state to remember what has already > been seen. The following change would address this concern: > > OLD > The challenge however is sent over > the network so as to make it simpler for a server to be stateless. > NEW > The challenge however is sent over > the network so as to reduce the amount of state that needs to be > maintained by servers. I don't see a useful difference, but I can buy that your wording is maybe better so I've made that change. > > The rest of the text on replay, including allowing some replay (e.g., > within max-age) is fine w/me. > >>> [4] TLS requirement level >>> >>> TLS is only a "SHOULD" requirement for HOBA, not a "MUST" requirement - >>> first paragraph in Section 8.1 (Privacy Considerations). >> >>> If TLS is not a "MUST" requirement, at least a discussion of man-in-the- >>> middle (MITM) attacks seems to be in order. There's no need for an> extensive >>> discussion of all of the security properties of TLS, but MITM attacks are >>> definitely worth a mention, and that could be complemented by a pointer to >>> suitable HTTP/TLS security considerations text elsewhere. >> >> I think that's covered where we note the potential for replay, which >> is what a MitM would/could do in this case. That is noted in both >> section 3 and in 6.1 and in section 8. I think we have it covered to >> be honest. > > Ok, in looking further at the text on TLS, I suggest clarifying the last > sentence in this text in section 1: > > HOBA session management is identical to username/password session > management, with a server-side session management tool or script > inserting a session cookie [RFC6265] into the output to the browser. > HOBA still requires TLS to prevent session cookie hijacking. > > This is not a requirement on HOBA interactions - it's on the overall > HTTP session. Suggestion: > > OLD > HOBA still requires TLS to prevent session cookie hijacking. > NEW > Use of TLS for the HTTP session is still necessary to prevent > session cookie hijacking. As above:-) > >>> [5] Section 5.3 - unrecognized key >>> >>> Paragraphs 4 and 5 in this section don't seem to belong here, and appear to >>> be written in a somewhat loose fashion, particularly around user verification. >>> A server that does what is suggested here could have significant security >>> weaknesses. >> >> Which specific weaknesses do you mean? > > In this text: > > The server >>can<< then use some out-of-band method (such as a > confirmation email round trip, SMS, or an UA that is already > enrolled) to verify that the "new" user is the same as the already- > enrolled one. > > and this text > > Completion of the joining process >>might<< require confirmation by > email, SMS, Captcha, and so on. > > the use of "can" and "might" appears to make user verification optional, > which is a poor recommendation for obvious reasons. > > The simplest fix would be to change both of those words to "ought to" > or "should" (lower case). Ok, at this point I think we're more into tweaking for the sake of it so I've not made that change. > >>> [A] ABNF encoding of alg >>> >>> In section 2, I see: >>> >>> alg = 1*2DIGIT >>> >>> o alg: specifies the signature algorithm being used encoded as an >>> ASCII character as defined in Section 9.3. >>> >>> Section 9.3 specifies a single digit. How does that become 1*2DIGIT ? >> >> Huh? The current algs only use one digit, but the abnf allows for >> more. Nothing odd there that I can see. > > What if someone uses "01" instead of "1" ? Adding the following variant > of your response (which is better than my initial proposal) would close off > this corner case: > > Algorithms defined in this document use only one digit; the ABNF > allows for two digits for future expansion. But that's already clear. No change made for now. > >>> [B] Section 5.3 - CPK vs. kid > >>> IIUC, the HOBA client sends: >>> >>> HOBA-RES = kid "." challenge "." nonce "." sig >>> >>> If so, I don't understand how the server extracts a CPK from that. >> >> Via the kid yes. > > [... snip ...] > >> I'm not seeing an actionable issue that needs a change. > > The client sends a kid, but the server is supposed to recognize the CPK. > The description of the server's actions needs to start from the kid, as > kid->CPK lookup may fail. Here's a possible text change: > > OLD > In the authentication phase, the server extracts the CPK from the > signing phase and decides if it recognizes the CPK. If the server > recognizes the CPK, the server may finish the client authentication > process. > NEW > In the authentication phase, the server uses the kid to locate its > copy of the client's CPK. If the server finds the CPK and recognizes > that CPK as appropriate for use, the server may finish the client > authentication process. > > That results in a couple of knock-on changes to generalize "recognize" > to "locate or recognize" - here's the first one: > > OLD > During the authentication phase, if the server does not recognize the > CPK, > NEW > During the authentication phase, if the server cannot locate or does > not recognize the CPK, > > The other one is similar. > >>> [C] RSA signature algorithm > > [... nit snipped ...] > >>> The minor issue is >>> whether that is the signature algorithm that's wanted, on which I'll defer >>> to the crypto experts on that (e.g., I seem to recall a negative saag >>> comment on PKCS 1.5 mechanisms in the past couple of months). >> >> Yes, it's fine for security and is correct for interop/deployment >> reasons. PKCSv1.5 encryption is what's less desirable if not done >> well and attempting to mandate PSS here would be a bad plan. > > Ok, that's what I wanted to see checked. No problem. > >>> [D] Javascript local storage. > > Again, one word is bothering me - here's a suggested change to the abstract: > > HOBA is an > alternative to HTTP authentication schemes that require passwords and > therefore avoids all problems related to passwords, such as leakage > of server-side password databases. > > Remove "all" - or change it to "many" or "common". I'm gonna stick with all - an implementation of HOBA can be vulnerable to many things, and one likely but temporary style of implementation (non-WebCrypto in browsers) will be vulnerable (as we note) but the protocol itself does avoid all password problems. I'll post -08 in a few minutes with those changes. Cheers, S. > > Thanks, > --David > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Wednesday, December 24, 2014 6:15 AM >> To: Black, David; paul.hoffman@vpnc.org; mike@phresheez.com; General Area >> Review Team (gen-art@ietf.org); ops-dir@ietf.org >> Cc: ietf@ietf.org; http-auth@ietf.org >> Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 >> >> >> Hi David, >> >> Sorry for the slow response, end of year rush and all that... >> >> And thanks for the review, responses inline and a proto-08 >> version (handling the various IETF LC comments) is at [1] >> with a diff vs. 07 at [2]. I'll plan to publish that as an >> official -08 in a few days if there are no comments. >> >> Cheers, >> S. >> >> [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt >> [2] >> https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba- >> 07.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt >> >> On 15/12/14 23:25, Black, David wrote: >>> This is a combined Gen-ART and OPS-Dir review. Boilerplate for both follows >> ... >>> >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at: >>> >>> . >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> I have reviewed this document as part of the Operational directorate's ongoing >>> effort to review all IETF documents being processed by the IESG. These comments >>> were written primarily for the benefit of the operational area directors. >>> Document editors and WG chairs should treat these comments just like any other >>> last call comments. >>> >>> Document: draft-ietf-httpauth-hoba-07 >>> Reviewer: David Black >>> Review Date: Dec XX, 2014 >>> IETF LC End Date: Dec 24, 2014 >>> >>> Summary: This draft is on the right track, but has open issues >>> described in the review. >>> >>> This draft specifies a signature-based authentication mechanism for HTTP >>> that is based on asymmetric (public-private) key pairs without using >>> certificates. A different key pair is used by each user for each for >>> each host ("web-origin", see [RFC6454]), and each signature is based >>> on a server-generated challenge. >>> >>> The draft is generally well-written and clear on the authentication >>> mechanics, but has weaknesses in specifying the environment that >>> surrounds use of this mechanism. Some of these issues are basic things >>> that anyone working on web technology or applied crypto "just knows", >>> but even the obvious needs to be stated when it's integral to security. >>> >>> -- Major issues: -- >>> >>> [1] Challenge size and predictability >>> >>> In the ABNF: >>> >>> challenge = 1*base64urlchars >>> >>> I did not see any other discussion of minimum length of challenge >>> or amount of entropy in the challenge. For the latter, do the challenges >>> need to be unpredictable? I would think so. >>> >>> I think a requirement on minimum challenge size and a recommendation on >>> minimum amount of entropy would be good ideas. >> >> Fair point. And you're right that this is assumed and ought be >> explicit, so good catch. >> >> OLD: >> >> o challenge: MUST be a base64url encoded challenge value that the >> server chose to send to the client >> >> NEW: >> >> o challenge: MUST be a base64url encoded challenge value that the >> server chose to send to the client. The challenge MUST be chosen >> so that it is infeasible to guess, and SHOULD be indistinguishable >> from (the base64url encoding of) an at least 128-bit long random >> string. >> >>> >>> [2] Challenge verification and reuse >>> >>> This sentence on p.6 strikes me as subtly dangerous: >>> >>> The challenge however is sent over >>> the network so as to make it simpler for a server to be stateless. >>> (One form of stateless challenge might be a ciphertext that the >>> server decrypts and checks, but that is an implementation detail.) >>> >>> The draft elsewhere asserts or assumes that challenge reuse can be >>> prevented by the server or be time-bounded by max-age, and relies on >>> those reuse limits for security properties, e.g., as in this sentence >>> near the end of Section 6.1: >>> >>> Note that replay of registration (and other HOBA) messages is quite >>> possible. That however can be counteracted if challenge freshness is >>> ensured. >>> >>> The sentence quoted from p.6 appears to allow (or even encourage) >>> stateless servers to implement rather weak checks on not only challenge >>> reuse, but also challenge validity (e.g., what if the challenge validity >>> test were "challenge mod 1024 == 7" ?). >>> >>> Allowing such weak checks could enable an attacker to choose or influence >>> the choice of challenge values, which could be useful (e.g., for >>> differential cryptanalysis attack on the hash function), as the >>> attacker (client) already controls the nonce. >>> >>> As part of this, the server needs to check whether a challenge presented >>> on one connection or session has been reused on another. I think the >>> following sentence in section 3 is intended to prevent this, but it's >>> weakened by the "stateless" language above: >>> >>> The challenge MUST be >>> unique for every HTTP 401 response in order to prevent replay >>> attacks from passive observers. >>> >>> Explicit server checks for challenge reuse ought to be REQUIRED, and >>> the above use of "stateless" needs to be qualified. >> >> Hmm. I think that HOBA ought not REQUIRE full replay protection >> in all cases, that is, it SHOULD be possible to deploy a server >> that is vulnerable to some replay. The reason is that we're trying >> to displace passwords here and I believe (without much hard evidence >> I'll grant you) that we'd lose some deployment chances if we were >> to insist on every single challenge being fresh. >> >> So I'd argue for no-change here, but would welcome further discussionm >> evidence or suggestions for text that's not going to be so onerous >> as to weaken our chances of getting this deployed. >> >> >>> >>> [3] Web origin checks >>> >>> I did not see text mandating that TLS (server certificate), HTTP (accessed >>> URL) and HOBA (signature input) use the same web origin, and stating that >>> the server has to check/enforce this. Did I miss something? >>> >>> I realize that this is an obvious requirement, but it does need to be >>> stated. >> >> Fair enough, I agree folks have been known to not implement even the >> most obvious things:-) I added the text below to section 3: >> >> The server MUST check that the same web origin is used in all of the >> server's TLS server certificate, the URL being accessed and the HOBA >> signature. If any of those checks fail, the server treats the >> signature as being cryptographically incorrect. >> >>> >>> [4] TLS requirement level >>> >>> TLS is only a "SHOULD" requirement for HOBA, not a "MUST" requirement - >>> first paragraph in Section 8.1 (Privacy Considerations). >>> >>> If TLS is not a "MUST" requirement, at least a discussion of man-in-the- >>> middle (MITM) attacks seems to be in order. There's no need for an >> extensive >>> discussion of all of the security properties of TLS, but MITM attacks are >>> definitely worth a mention, and that could be complemented by a pointer to >>> suitable HTTP/TLS security considerations text elsewhere. >> >> I think that's covered where we note the potential for replay, which >> is what a MitM would/could do in this case. That is noted in both >> section 3 and in 6.1 and in section 8. I think we have it covered to >> be honest. >> >>> >>> [5] Section 5.3 - unrecognized key >>> >>> Paragraphs 4 and 5 in this section don't seem to belong here, and appear to >>> be written in a somewhat loose fashion, particularly around user >> verification. >>> A server that does what is suggested here could have significant security >>> weaknesses. >> >> Which specific weaknesses do you mean? >> >>> >>> I strongly recommend replacing those two paragraphs with a short sentence >> that >>> says: >>> - if a kid is unrecognized or the server otherwise determines >>> that the CPK is not to be used for this HTTP authentication, >>> - then the Registration (see 6.1) and/or Associating Additional Keys to >>> an Exiting Account (see 6.2) processes MAY be used instead of >>> treating this situation as an authentication failure. >>> >>> and moving all discussion of user verification into Sections 6.1 and 6.2. >> >> Sorry, I don't think that is needed at all. The current text simply >> reflects the kind of thing that we think deployments will do and will >> need to do and I don't see what specific weaknesses you are claiming >> might ensue. I'd be happy to note any such of course. >> >> Also, from my reading your suggested text has the same impact and >> only differs in using a 2119 MAY instead of could, might etc. But if >> you meant it to differ more substantively you'll need to explain that >> to me some more. >> >>> >>> -- Minor issues: -- >>> >>> [A] ABNF encoding of alg >>> >>> In section 2, I see: >>> >>> alg = 1*2DIGIT >>> >>> o alg: specifies the signature algorithm being used encoded as an >>> ASCII character as defined in Section 9.3. >>> >>> Section 9.3 specifies a single digit. How does that become 1*2DIGIT ? >> >> Huh? The current algs only use one digit, but the abnf allows for >> more. Nothing odd there that I can see. >> >>> I suggest: "as an ASCII character" -> "as one or two ASCII digits based >>> on the IANA registry established by Section 9.3" >> >> I think it's ok as is. >> >>> This may seem like a nit, but any imprecision in signature algorithm >>> input can lead to interoperability problems. >> >> Yes it can. But we're not being imprecise that I can see. >> >>> >>> [B] Section 5.3 - CPK vs. kid >>> >>> In the authentication phase, the server extracts the CPK from the >>> signing phase and decides if it recognizes the CPK. If the server >>> recognizes the CPK, the server may finish the client authentication >>> process. >>> >>> That seems wrong. IIUC, the HOBA client sends: >>> >>> HOBA-RES = kid "." challenge "." nonce "." sig >>> >>> If so, I don't understand how the server extracts a CPK from that. >> >> Via the kid yes. >> >>> >>> I suspect that what was intended is that the server extracts a key >> identifier >>> (kid) and then determines a) whether it knows a CPK for that kid and b) >> whether >>> it allows use of that kid/CPK for this authentication. At least a) seems to >>> be indicated by this text in Section 3: >>> >>> The server MUST check the cryptographic correctness of the signature >>> based on a public key it knows for the kid in the signatures, >> >> I'm not seeing an actionable issue that needs a change. >> >>> >>> [C] RSA signature algorithm >>> >>> Section 7 says: >>> >>> RSA is defined in >>> Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. >>> >>> Section 8.2 of RFC 3447 specifies RSASSA-PKCS1-v1_5. At a minimum, that >>> algorithm name should be stated here (which is a nit). >> >> Disagree (also as a nit:-) >> >>> The minor issue is >>> whether that is the signature algorithm that's wanted, on which I'll defer >>> to the crypto experts on that (e.g., I seem to recall a negative saag >>> comment on PKCS 1.5 mechanisms in the past couple of months). >> >> Yes, it's fine for security and is correct for interop/deployment >> reasons. PKCSv1.5 encryption is what's less desirable if not done >> well and attempting to mandate PSS here would be a bad plan. >> >>> >>> [D] Javascript local storage. >>> >>> The first paragraph of Section 8.2 on this topic concludes with: >>> >>> It's not clear that we >>> introduce unique threats from which clear text passwords don't >>> already suffer. >>> >>> That's at odds with the use of "all" in this sentence in the abstract: >>> >>> HOBA is an >>> alternative to HTTP authentication schemes that require passwords and >>> therefore avoids all problems related to passwords, such as leakage >>> of server-side password databases. >>> >>> One of those two paragraphs needs some editing. >> >> I don't think so actually, the first quoted sentence above is in the >> context of a web site with XSS vulnerabilities. Omitting that context >> would make for bad text, but the immediately preceding sentence is >> fairly explicit on that. >> >> (In passing, I did edit the top of that para a bit, since using the >> WebCrypto API is now possible so a tweak was needed.) >> >>> >>> -- Nits/editorial comments: -- >>> >>> This is buried near the end of section 6.1 >>> >>> Note that replay of registration (and other HOBA) messages is quite >>> possible. That however can be counteracted if challenge freshness is >>> ensured. >>> >>> That's not a good place for these two sentences. HOBA registration >>> messages don't contain a challenge, and the general discussion of >>> replay attacks belongs under Security Considerations, not Registration. >> >> They do contain a challenge in the header, though not in the body. >> I think the sentence is ok where it is. >> >>> >>> In Section 9.4 and 9.5, I see the following proposed as part of IANA >>> registry contents: >>> >>> an unformatted string, at the user's/UA's whim >>> >>> I get the point, but it's still not appropriate for an IANA registry >>> - remove ", at the user's/UA's whim". >> >> I whimsically disagree:-) IANA shouldn't be against whimsy. >> >>> Appendix A appears to assume that human-memorable passwords are stored in >>> the clear in server databases. It should also briefly discuss the use >>> of one-way functions, especially computationally intensive ones, to >>> generate stored password verifiers. HOBA is still superior by comparison, >>> as the one-way functions only increase the difficulty of dictionary >>> attack, whereas dictionary attack on HOBA keys is pointless when >>> sufficiently large keys are used. >> >> I'd prefer to not get into more analysis of passwords, and even hashed >> passwords are essentially guessable. >> >>> >>> idnits 2.13.01 found the references to W3C's web site (www.w3.org) in >>> Section 4, e.g., >>> >>> 389 One element is required for HOBA-js: localStorage (see http:// >>> 390 www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key >>> 391 storage. >>> >>> I think idnits can be ignored, even though the "right way" to fix this is to >>> move each URL to a reference and cite the reference in Section 4. >>> >>> OTOH, idnits did not complain about the normative reference to RFC 20 ;-). >> >> Heh:-) >> >>> >>> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- >>> >>> Most of these questions are n/a because this draft describes an extension >>> to HTTP authentication, and RFC 5706's concerns would apply primarily to >>> HTTP and HTTP authentication. >>> >>> A.1.1 Has deployment been discussed? >>> >>> Yes, section 6 discusses how a user would deploy this for her access to web >>> servers. >>> >>> A.1.4. Have the Requirements on other protocols and functional >>> components been discussed? >>> >>> Yes, the discussion of how this functions within HTTP is sufficient. >>> >>> Major issues [3] and [4] fall into this category, but in both cases, >>> I think they're probably text oversights that are easy to fix. >>> >>> A.2.7 Is security management discussed? >>> >>> Not really, but this is an Experimental RFC. I would expect that the >>> experimental use of HOBA will yield insight into server key database >>> structure/management, key lifecycle management (e.g., revocation), >>> account management techniques/processes, etc. >>> >>> A.3. Documentation >>> >>> I do not expect significant operational impact. >>> >>> Section 10 notes the existence of two implementations of HOBA-JS and >>> one implementation of HOBA-http. That's a good start for an experiment. >> >> And now there's a 3rd! >> >> Thanks again for the fine review, >> S. >> >> >>> >>> Thanks, >>> --David >>> ---------------------------------------------------- >>> David L. Black, Distinguished Engineer >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>> david.black@emc.com Mobile: +1 (978) 394-7754 >>> ---------------------------------------------------- >>> >>> >>> From nobody Fri Dec 26 15:42:31 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92351ACFD8; Fri, 26 Dec 2014 15:42:20 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eu5OJ4e-uxnb; Fri, 26 Dec 2014 15:42:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA04F1ACFD0; Fri, 26 Dec 2014 15:42:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141226234215.30393.91976.idtracker@ietfa.amsl.com> Date: Fri, 26 Dec 2014 15:42:15 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/R8tGFg4ywLegcoPVLH-JCc3B1VI Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-hoba-08.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2014 23:42:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : HTTP Origin-Bound Authentication (HOBA) Authors : Stephen Farrell Paul Hoffman Michael Thomas Filename : draft-ietf-httpauth-hoba-08.txt Pages : 26 Date : 2014-12-26 Abstract: HTTP Origin-Bound Authentication (HOBA) is a digital signature based design for an HTTP authentication method. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-hoba-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 26 15:42:41 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC561ACFD1 for ; Fri, 26 Dec 2014 15:42:27 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDEi8EUH-5IK; Fri, 26 Dec 2014 15:42:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D481ACFD3; Fri, 26 Dec 2014 15:42:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" , Kathleen.Moriarty.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141226234215.30393.9476.idtracker@ietfa.amsl.com> Date: Fri, 26 Dec 2014 15:42:15 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/J24NJT1p26oc7xUyglxN_PpuoIE Subject: [http-auth] New Version Notification - draft-ietf-httpauth-hoba-08.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2014 23:42:28 -0000 A new version (-08) has been submitted for draft-ietf-httpauth-hoba: http://www.ietf.org/internet-drafts/draft-ietf-httpauth-hoba-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Dec 26 18:45:27 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A3E1A1B61; Fri, 26 Dec 2014 18:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efiwxIiGmxyP; Fri, 26 Dec 2014 18:45:12 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B431A1B34; Fri, 26 Dec 2014 18:45:11 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBR2j2AM010733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Dec 2014 21:45:02 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sBR2j2AM010733 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1419648303; bh=NZ4zpYS+CXvtZPyPQ8kbEDrmmqY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=uVWPdX6KYcQeXv42pRy5eSi3a3nGdie/hQdvBSoH13ASDEdERcVaWBDrcAPSHLtxI qnhTWNe2JTLsXNEeFICcBxL0lH7RitqVHD1R96WsKJ/njlCgoyTaz5phw/cqLgzTq7 Vv5Ouwh250GHaHYAWOTBgArKbCpH583ZIPmPVzM8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sBR2j2AM010733 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd56.lss.emc.com (RSA Interceptor); Fri, 26 Dec 2014 21:43:43 -0500 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBR2irEp006579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Dec 2014 21:44:53 -0500 Received: from MXHUB202.corp.emc.com (10.253.68.28) by mxhub13.corp.emc.com (128.222.70.234) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 26 Dec 2014 21:44:53 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB202.corp.emc.com ([10.253.68.28]) with mapi id 14.03.0195.001; Fri, 26 Dec 2014 21:44:52 -0500 From: "Black, David" To: Stephen Farrell , "paul.hoffman@vpnc.org" , "mike@phresheez.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 Thread-Index: AdAYvlv0aser5OsbSxuh2NmwD9vCCwG1mzwAAAMHcGAAe5PugAAEOpRQ Date: Sat, 27 Dec 2014 02:44:52 +0000 Message-ID: References: <549AA03C.5070107@cs.tcd.ie> <549DF1E1.3080308@cs.tcd.ie> In-Reply-To: <549DF1E1.3080308@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.251.42.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/yNj5nplT3Y2fzKbPhessZA71Xfo Cc: "Black, David" , "http-auth@ietf.org" , "ietf@ietf.org" Subject: Re: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 02:45:17 -0000 QW5kIHRoYW5rcyBmb3IgdGhlIGNoYW5nZXMgaW4gLTA4IHRvIGFkZHJlc3MgdGhpcyByZXZpZXcg LSBpbiBhZGRpdGlvbiB0bw0Kd2hhdCdzIG5vdGVkIGJlbG93LCAtMDggYWxzbyBhZGRyZXNzZXMg W0JdIHcvbW9yZSBjb21wYWN0IHRleHQgdGhhbiBJIGhhZA0Kc3VnZ2VzdGVkLg0KDQpFdmVyeXRo aW5nIHRoYXQgcmVtYWlucyBpcyBkb3duIHRvIGVkaXRvcmlhbCBjb21tZW50cyBvciBuaXRzLiAg SSdsbCBnbyBzZW5kDQphIHJldmlldyBvZiAtMDggdG8gdGhhdCBlZmZlY3QuDQoNClRoYW5rcywN Ci0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGVwaGVu IEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXQ0KPiBTZW50OiBGcmlk YXksIERlY2VtYmVyIDI2LCAyMDE0IDY6NDAgUE0NCj4gVG86IEJsYWNrLCBEYXZpZDsgcGF1bC5o b2ZmbWFuQHZwbmMub3JnOyBtaWtlQHBocmVzaGVlei5jb207IEdlbmVyYWwgQXJlYQ0KPiBSZXZp ZXcgVGVhbSAoZ2VuLWFydEBpZXRmLm9yZyk7IG9wcy1kaXJAaWV0Zi5vcmcNCj4gQ2M6IGlldGZA aWV0Zi5vcmc7IGh0dHAtYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogR2VuLUFSVCBhbmQg T1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1odHRwYXV0aC1ob2JhLTA3DQo+IA0KPiANCj4g SGkgRGF2aWQsDQo+IA0KPiBBZ2FpbiB0aGFua3MgZm9yIHRoZSBmb2xsb3cgdXAuLi4NCj4gDQo+ IE9uIDI0LzEyLzE0IDE4OjQwLCBCbGFjaywgRGF2aWQgd3JvdGU6DQo+ID4gSGkgU3RlcGhlbiwN Cj4gPg0KPiA+IFRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlIGFuZCBpbml0aWFsIHVwZGF0ZXMgLSBh bnl0aGluZyB0aGF0IEkgZG9uJ3QgY29tbWVudA0KPiA+IG9uIGZ1cnRoZXIgaXMgZmluZSwgYW5k IGV2ZXJ5dGhpbmcgaW4gdGhpcyByZXNwb25zZSBzaG91bGQgbm93IGJlIHJlZHVjZWQgdG8NCj4g PiByZXF1ZXN0cyBmb3IgbWlub3IgYWRkaXRpb25hbCB0ZXh0IGNoYW5nZXM6DQo+ID4NCj4gPj4+ IFsyXSBDaGFsbGVuZ2UgdmVyaWZpY2F0aW9uIGFuZCByZXVzZQ0KPiA+Pj4NCj4gPj4+IFRoaXMg c2VudGVuY2Ugb24gcC42IHN0cmlrZXMgbWUgYXMgc3VidGx5IGRhbmdlcm91czoNCj4gPj4+DQo+ ID4+PiAgICBUaGUgY2hhbGxlbmdlIGhvd2V2ZXIgaXMgc2VudCBvdmVyDQo+ID4+PiAgICB0aGUg bmV0d29yayBzbyBhcyB0byBtYWtlIGl0IHNpbXBsZXIgZm9yIGEgc2VydmVyIHRvIGJlIHN0YXRl bGVzcy4NCj4gPj4+ICAgIChPbmUgZm9ybSBvZiBzdGF0ZWxlc3MgY2hhbGxlbmdlIG1pZ2h0IGJl IGEgY2lwaGVydGV4dCB0aGF0IHRoZQ0KPiA+Pj4gICAgc2VydmVyIGRlY3J5cHRzIGFuZCBjaGVj a3MsIGJ1dCB0aGF0IGlzIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC4pDQo+ID4+Pg0KPiA+Pj4g VGhlIGRyYWZ0IGVsc2V3aGVyZSBhc3NlcnRzIG9yIGFzc3VtZXMgdGhhdCBjaGFsbGVuZ2UgcmV1 c2UgY2FuIGJlDQo+ID4+PiBwcmV2ZW50ZWQgYnkgdGhlIHNlcnZlciBvciBiZSB0aW1lLWJvdW5k ZWQgYnkgbWF4LWFnZSwgYW5kIHJlbGllcyBvbg0KPiA+Pj4gdGhvc2UgcmV1c2UgbGltaXRzIGZv ciBzZWN1cml0eSBwcm9wZXJ0aWVzLA0KPiA+DQo+ID4gWy4uLiBzbmlwIC4uLl0NCj4gPg0KPiA+ PiBIbW0uIEkgdGhpbmsgdGhhdCBIT0JBIG91Z2h0IG5vdCBSRVFVSVJFIGZ1bGwgcmVwbGF5IHBy b3RlY3Rpb24NCj4gPj4gaW4gYWxsIGNhc2VzLCB0aGF0IGlzLCBpdCBTSE9VTEQgYmUgcG9zc2li bGUgdG8gZGVwbG95IGEgc2VydmVyDQo+ID4+IHRoYXQgaXMgdnVsbmVyYWJsZSB0byBzb21lIHJl cGxheS4gVGhlIHJlYXNvbiBpcyB0aGF0IHdlJ3JlIHRyeWluZw0KPiA+PiB0byBkaXNwbGFjZSBw YXNzd29yZHMgaGVyZSBhbmQgSSBiZWxpZXZlICh3aXRob3V0IG11Y2ggaGFyZCBldmlkZW5jZQ0K PiA+PiBJJ2xsIGdyYW50IHlvdSkgdGhhdCB3ZSdkIGxvc2Ugc29tZSBkZXBsb3ltZW50IGNoYW5j ZXMgaWYgd2Ugd2VyZQ0KPiA+PiB0byBpbnNpc3Qgb24gZXZlcnkgc2luZ2xlIGNoYWxsZW5nZSBi ZWluZyBmcmVzaC4NCj4gPj4NCj4gPj4gU28gSSdkIGFyZ3VlIGZvciBuby1jaGFuZ2UgaGVyZSwg YnV0IHdvdWxkIHdlbGNvbWUgZnVydGhlciBkaXNjdXNzaW9uDQo+ID4+IGV2aWRlbmNlIG9yIHN1 Z2dlc3Rpb25zIGZvciB0ZXh0IHRoYXQncyBub3QgZ29pbmcgdG8gYmUgc28gb25lcm91cw0KPiA+ PiBhcyB0byB3ZWFrZW4gb3VyIGNoYW5jZXMgb2YgZ2V0dGluZyB0aGlzIGRlcGxveWVkLg0KPiA+ DQo+ID4gVGhlIHdvcmQgInN0YXRlbGVzcyIgaXMgYm90aGVyaW5nIG1lLA0KPiANCj4gVGhhdCdz IEhUVFAgZm9yIHlhOi0pDQo+IA0KPiA+IGFzIGRvaW5nIGEgZ29vZCBqb2Igb2YgcmVwbGF5DQo+ ID4gcHJldmVudGlvbiB1c3VhbGx5IHJlcXVpcmVzIHNhdmluZyBzdGF0ZSB0byByZW1lbWJlciB3 aGF0IGhhcyBhbHJlYWR5DQo+ID4gYmVlbiBzZWVuLiAgVGhlIGZvbGxvd2luZyBjaGFuZ2Ugd291 bGQgYWRkcmVzcyB0aGlzIGNvbmNlcm46DQo+ID4NCj4gPiBPTEQNCj4gPiAgICBUaGUgY2hhbGxl bmdlIGhvd2V2ZXIgaXMgc2VudCBvdmVyDQo+ID4gICAgdGhlIG5ldHdvcmsgc28gYXMgdG8gbWFr ZSBpdCBzaW1wbGVyIGZvciBhIHNlcnZlciB0byBiZSBzdGF0ZWxlc3MuDQo+ID4gTkVXDQo+ID4g ICAgVGhlIGNoYWxsZW5nZSBob3dldmVyIGlzIHNlbnQgb3Zlcg0KPiA+ICAgIHRoZSBuZXR3b3Jr IHNvIGFzIHRvIHJlZHVjZSB0aGUgYW1vdW50IG9mIHN0YXRlIHRoYXQgbmVlZHMgdG8gYmUNCj4g PiAgICBtYWludGFpbmVkIGJ5IHNlcnZlcnMuDQo+IA0KPiBJIGRvbid0IHNlZSBhIHVzZWZ1bCBk aWZmZXJlbmNlLCBidXQgSSBjYW4gYnV5IHRoYXQgeW91ciB3b3JkaW5nDQo+IGlzIG1heWJlIGJl dHRlciBzbyBJJ3ZlIG1hZGUgdGhhdCBjaGFuZ2UuDQo+IA0KPiA+DQo+ID4gVGhlIHJlc3Qgb2Yg dGhlIHRleHQgb24gcmVwbGF5LCBpbmNsdWRpbmcgYWxsb3dpbmcgc29tZSByZXBsYXkgKGUuZy4s DQo+ID4gd2l0aGluIG1heC1hZ2UpIGlzIGZpbmUgdy9tZS4NCj4gPg0KPiA+Pj4gWzRdIFRMUyBy ZXF1aXJlbWVudCBsZXZlbA0KPiA+Pj4NCj4gPj4+IFRMUyBpcyBvbmx5IGEgIlNIT1VMRCIgcmVx dWlyZW1lbnQgZm9yIEhPQkEsIG5vdCBhICJNVVNUIiByZXF1aXJlbWVudCAtDQo+ID4+PiBmaXJz dCBwYXJhZ3JhcGggaW4gU2VjdGlvbiA4LjEgKFByaXZhY3kgQ29uc2lkZXJhdGlvbnMpLg0KPiA+ Pg0KPiA+Pj4gSWYgVExTIGlzIG5vdCBhICJNVVNUIiByZXF1aXJlbWVudCwgYXQgbGVhc3QgYSBk aXNjdXNzaW9uIG9mIG1hbi1pbi10aGUtDQo+ID4+PiBtaWRkbGUgKE1JVE0pIGF0dGFja3Mgc2Vl bXMgdG8gYmUgaW4gb3JkZXIuICBUaGVyZSdzIG5vIG5lZWQgZm9yIGFuPg0KPiBleHRlbnNpdmUN Cj4gPj4+IGRpc2N1c3Npb24gb2YgYWxsIG9mIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIG9mIFRM UywgYnV0IE1JVE0gYXR0YWNrcyBhcmUNCj4gPj4+IGRlZmluaXRlbHkgd29ydGggYSBtZW50aW9u LCBhbmQgdGhhdCBjb3VsZCBiZSBjb21wbGVtZW50ZWQgYnkgYSBwb2ludGVyIHRvDQo+ID4+PiBz dWl0YWJsZSBIVFRQL1RMUyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0ZXh0IGVsc2V3aGVyZS4N Cj4gPj4NCj4gPj4gSSB0aGluayB0aGF0J3MgY292ZXJlZCB3aGVyZSB3ZSBub3RlIHRoZSBwb3Rl bnRpYWwgZm9yIHJlcGxheSwgd2hpY2gNCj4gPj4gaXMgd2hhdCBhIE1pdE0gd291bGQvY291bGQg ZG8gaW4gdGhpcyBjYXNlLiBUaGF0IGlzIG5vdGVkIGluIGJvdGgNCj4gPj4gc2VjdGlvbiAzIGFu ZCBpbiA2LjEgYW5kIGluIHNlY3Rpb24gOC4gSSB0aGluayB3ZSBoYXZlIGl0IGNvdmVyZWQgdG8N Cj4gPj4gYmUgaG9uZXN0Lg0KPiA+DQo+ID4gT2ssIGluIGxvb2tpbmcgZnVydGhlciBhdCB0aGUg dGV4dCBvbiBUTFMsIEkgc3VnZ2VzdCBjbGFyaWZ5aW5nIHRoZSBsYXN0DQo+ID4gc2VudGVuY2Ug aW4gdGhpcyB0ZXh0IGluIHNlY3Rpb24gMToNCj4gPg0KPiA+ICAgIEhPQkEgc2Vzc2lvbiBtYW5h Z2VtZW50IGlzIGlkZW50aWNhbCB0byB1c2VybmFtZS9wYXNzd29yZCBzZXNzaW9uDQo+ID4gICAg bWFuYWdlbWVudCwgd2l0aCBhIHNlcnZlci1zaWRlIHNlc3Npb24gbWFuYWdlbWVudCB0b29sIG9y IHNjcmlwdA0KPiA+ICAgIGluc2VydGluZyBhIHNlc3Npb24gY29va2llIFtSRkM2MjY1XSBpbnRv IHRoZSBvdXRwdXQgdG8gdGhlIGJyb3dzZXIuDQo+ID4gICAgSE9CQSBzdGlsbCByZXF1aXJlcyBU TFMgdG8gcHJldmVudCBzZXNzaW9uIGNvb2tpZSBoaWphY2tpbmcuDQo+ID4NCj4gPiBUaGlzIGlz IG5vdCBhIHJlcXVpcmVtZW50IG9uIEhPQkEgaW50ZXJhY3Rpb25zIC0gaXQncyBvbiB0aGUgb3Zl cmFsbA0KPiA+IEhUVFAgc2Vzc2lvbi4gIFN1Z2dlc3Rpb246DQo+ID4NCj4gPiBPTEQNCj4gPiAg ICBIT0JBIHN0aWxsIHJlcXVpcmVzIFRMUyB0byBwcmV2ZW50IHNlc3Npb24gY29va2llIGhpamFj a2luZy4NCj4gPiBORVcNCj4gPiAgICBVc2Ugb2YgVExTIGZvciB0aGUgSFRUUCBzZXNzaW9uIGlz IHN0aWxsIG5lY2Vzc2FyeSB0byBwcmV2ZW50DQo+ID4gICAgc2Vzc2lvbiBjb29raWUgaGlqYWNr aW5nLg0KPiANCj4gQXMgYWJvdmU6LSkNCj4gDQo+ID4NCj4gPj4+IFs1XSBTZWN0aW9uIDUuMyAt IHVucmVjb2duaXplZCBrZXkNCj4gPj4+DQo+ID4+PiBQYXJhZ3JhcGhzIDQgYW5kIDUgaW4gdGhp cyBzZWN0aW9uIGRvbid0IHNlZW0gdG8gYmVsb25nIGhlcmUsIGFuZCBhcHBlYXINCj4gdG8NCj4g Pj4+IGJlIHdyaXR0ZW4gaW4gYSBzb21ld2hhdCBsb29zZSBmYXNoaW9uLCBwYXJ0aWN1bGFybHkg YXJvdW5kIHVzZXINCj4gdmVyaWZpY2F0aW9uLg0KPiA+Pj4gQSBzZXJ2ZXIgdGhhdCBkb2VzIHdo YXQgaXMgc3VnZ2VzdGVkIGhlcmUgY291bGQgaGF2ZSBzaWduaWZpY2FudCBzZWN1cml0eQ0KPiA+ Pj4gd2Vha25lc3Nlcy4NCj4gPj4NCj4gPj4gV2hpY2ggc3BlY2lmaWMgd2Vha25lc3NlcyBkbyB5 b3UgbWVhbj8NCj4gPg0KPiA+IEluIHRoaXMgdGV4dDoNCj4gPg0KPiA+ICAgIFRoZSBzZXJ2ZXIg Pj5jYW48PCB0aGVuIHVzZSBzb21lIG91dC1vZi1iYW5kIG1ldGhvZCAoc3VjaCBhcyBhDQo+ID4g ICAgY29uZmlybWF0aW9uIGVtYWlsIHJvdW5kIHRyaXAsIFNNUywgb3IgYW4gVUEgdGhhdCBpcyBh bHJlYWR5DQo+ID4gICAgZW5yb2xsZWQpIHRvIHZlcmlmeSB0aGF0IHRoZSAibmV3IiB1c2VyIGlz IHRoZSBzYW1lIGFzIHRoZSBhbHJlYWR5LQ0KPiA+ICAgIGVucm9sbGVkIG9uZS4NCj4gPg0KPiA+ IGFuZCB0aGlzIHRleHQNCj4gPg0KPiA+ICAgIENvbXBsZXRpb24gb2YgdGhlIGpvaW5pbmcgcHJv Y2VzcyA+Pm1pZ2h0PDwgcmVxdWlyZSBjb25maXJtYXRpb24gYnkNCj4gPiAgICBlbWFpbCwgU01T LCBDYXB0Y2hhLCBhbmQgc28gb24uDQo+ID4NCj4gPiB0aGUgdXNlIG9mICJjYW4iIGFuZCAibWln aHQiIGFwcGVhcnMgdG8gbWFrZSB1c2VyIHZlcmlmaWNhdGlvbiBvcHRpb25hbCwNCj4gPiB3aGlj aCBpcyBhIHBvb3IgcmVjb21tZW5kYXRpb24gZm9yIG9idmlvdXMgcmVhc29ucy4NCj4gPg0KPiA+ IFRoZSBzaW1wbGVzdCBmaXggd291bGQgYmUgdG8gY2hhbmdlIGJvdGggb2YgdGhvc2Ugd29yZHMg dG8gIm91Z2h0IHRvIg0KPiA+IG9yICJzaG91bGQiIChsb3dlciBjYXNlKS4NCj4gDQo+IE9rLCBh dCB0aGlzIHBvaW50IEkgdGhpbmsgd2UncmUgbW9yZSBpbnRvIHR3ZWFraW5nIGZvciB0aGUgc2Fr ZSBvZiBpdA0KPiBzbyBJJ3ZlIG5vdCBtYWRlIHRoYXQgY2hhbmdlLg0KPiANCj4gPg0KPiA+Pj4g W0FdIEFCTkYgZW5jb2Rpbmcgb2YgYWxnDQo+ID4+Pg0KPiA+Pj4gSW4gc2VjdGlvbiAyLCBJIHNl ZToNCj4gPj4+DQo+ID4+PiAgICBhbGcgPSAxKjJESUdJVA0KPiA+Pj4NCj4gPj4+ICAgIG8gIGFs Zzogc3BlY2lmaWVzIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtIGJlaW5nIHVzZWQgZW5jb2RlZCBh cyBhbg0KPiA+Pj4gICAgICAgQVNDSUkgY2hhcmFjdGVyIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA5 LjMuDQo+ID4+Pg0KPiA+Pj4gU2VjdGlvbiA5LjMgc3BlY2lmaWVzIGEgc2luZ2xlIGRpZ2l0LiAg SG93IGRvZXMgdGhhdCBiZWNvbWUgMSoyRElHSVQgPw0KPiA+Pg0KPiA+PiBIdWg/IFRoZSBjdXJy ZW50IGFsZ3Mgb25seSB1c2Ugb25lIGRpZ2l0LCBidXQgdGhlIGFibmYgYWxsb3dzIGZvcg0KPiA+ PiBtb3JlLiBOb3RoaW5nIG9kZCB0aGVyZSB0aGF0IEkgY2FuIHNlZS4NCj4gPg0KPiA+IFdoYXQg aWYgc29tZW9uZSB1c2VzICIwMSIgaW5zdGVhZCBvZiAiMSIgPyAgQWRkaW5nIHRoZSBmb2xsb3dp bmcgdmFyaWFudA0KPiA+IG9mIHlvdXIgcmVzcG9uc2UgKHdoaWNoIGlzIGJldHRlciB0aGFuIG15 IGluaXRpYWwgcHJvcG9zYWwpIHdvdWxkIGNsb3NlIG9mZg0KPiA+IHRoaXMgY29ybmVyIGNhc2U6 DQo+ID4NCj4gPiAJQWxnb3JpdGhtcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgdXNlIG9ubHkg b25lIGRpZ2l0OyB0aGUgQUJORg0KPiA+IAlhbGxvd3MgZm9yIHR3byBkaWdpdHMgZm9yIGZ1dHVy ZSBleHBhbnNpb24uDQo+IA0KPiBCdXQgdGhhdCdzIGFscmVhZHkgY2xlYXIuIE5vIGNoYW5nZSBt YWRlIGZvciBub3cuDQo+IA0KPiA+DQo+ID4+PiBbQl0gU2VjdGlvbiA1LjMgLSBDUEsgdnMuIGtp ZA0KPiA+DQo+ID4+PiBJSVVDLCB0aGUgSE9CQSBjbGllbnQgc2VuZHM6DQo+ID4+Pg0KPiA+Pj4g ICAgSE9CQS1SRVMgPSBraWQgIi4iIGNoYWxsZW5nZSAiLiIgbm9uY2UgIi4iIHNpZw0KPiA+Pj4N Cj4gPj4+IElmIHNvLCBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoZSBzZXJ2ZXIgZXh0cmFjdHMg YSBDUEsgZnJvbSB0aGF0Lg0KPiA+Pg0KPiA+PiBWaWEgdGhlIGtpZCB5ZXMuDQo+ID4NCj4gPiBb Li4uIHNuaXAgLi4uXQ0KPiA+DQo+ID4+IEknbSBub3Qgc2VlaW5nIGFuIGFjdGlvbmFibGUgaXNz dWUgdGhhdCBuZWVkcyBhIGNoYW5nZS4NCj4gPg0KPiA+IFRoZSBjbGllbnQgc2VuZHMgYSBraWQs IGJ1dCB0aGUgc2VydmVyIGlzIHN1cHBvc2VkIHRvIHJlY29nbml6ZSB0aGUgQ1BLLg0KPiA+IFRo ZSBkZXNjcmlwdGlvbiBvZiB0aGUgc2VydmVyJ3MgYWN0aW9ucyBuZWVkcyB0byBzdGFydCBmcm9t IHRoZSBraWQsIGFzDQo+ID4ga2lkLT5DUEsgbG9va3VwIG1heSBmYWlsLiAgSGVyZSdzIGEgcG9z c2libGUgdGV4dCBjaGFuZ2U6DQo+ID4NCj4gPiBPTEQNCj4gPiAgICBJbiB0aGUgYXV0aGVudGlj YXRpb24gcGhhc2UsIHRoZSBzZXJ2ZXIgZXh0cmFjdHMgdGhlIENQSyBmcm9tIHRoZQ0KPiA+ICAg IHNpZ25pbmcgcGhhc2UgYW5kIGRlY2lkZXMgaWYgaXQgcmVjb2duaXplcyB0aGUgQ1BLLiAgSWYg dGhlIHNlcnZlcg0KPiA+ICAgIHJlY29nbml6ZXMgdGhlIENQSywgdGhlIHNlcnZlciBtYXkgZmlu aXNoIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24NCj4gPiAgICBwcm9jZXNzLg0KPiA+IE5FVw0K PiA+ICAgIEluIHRoZSBhdXRoZW50aWNhdGlvbiBwaGFzZSwgdGhlIHNlcnZlciB1c2VzIHRoZSBr aWQgdG8gbG9jYXRlIGl0cw0KPiA+ICAgIGNvcHkgb2YgdGhlIGNsaWVudCdzIENQSy4gIElmIHRo ZSBzZXJ2ZXIgZmluZHMgdGhlIENQSyBhbmQgcmVjb2duaXplcw0KPiA+ICAgIHRoYXQgQ1BLIGFz IGFwcHJvcHJpYXRlIGZvciB1c2UsIHRoZSBzZXJ2ZXIgbWF5IGZpbmlzaCB0aGUgY2xpZW50DQo+ ID4gICAgYXV0aGVudGljYXRpb24gcHJvY2Vzcy4NCj4gPg0KPiA+IFRoYXQgcmVzdWx0cyBpbiBh IGNvdXBsZSBvZiBrbm9jay1vbiBjaGFuZ2VzIHRvIGdlbmVyYWxpemUgInJlY29nbml6ZSINCj4g PiB0byAibG9jYXRlIG9yIHJlY29nbml6ZSIgLSBoZXJlJ3MgdGhlIGZpcnN0IG9uZToNCj4gPg0K PiA+IE9MRA0KPiA+ICAgIER1cmluZyB0aGUgYXV0aGVudGljYXRpb24gcGhhc2UsIGlmIHRoZSBz ZXJ2ZXIgZG9lcyBub3QgcmVjb2duaXplIHRoZQ0KPiA+ICAgIENQSywNCj4gPiBORVcNCj4gPiAg ICBEdXJpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIHBoYXNlLCBpZiB0aGUgc2VydmVyIGNhbm5vdCBs b2NhdGUgb3IgZG9lcw0KPiA+ICAgIG5vdCByZWNvZ25pemUgdGhlIENQSywNCj4gPg0KPiA+IFRo ZSBvdGhlciBvbmUgaXMgc2ltaWxhci4NCj4gPg0KPiA+Pj4gW0NdIFJTQSBzaWduYXR1cmUgYWxn b3JpdGhtDQo+ID4NCj4gPiBbLi4uIG5pdCBzbmlwcGVkIC4uLl0NCj4gPg0KPiA+Pj4gVGhlIG1p bm9yIGlzc3VlIGlzDQo+ID4+PiB3aGV0aGVyIHRoYXQgaXMgdGhlIHNpZ25hdHVyZSBhbGdvcml0 aG0gdGhhdCdzIHdhbnRlZCwgb24gd2hpY2ggSSdsbCBkZWZlcg0KPiA+Pj4gdG8gdGhlIGNyeXB0 byBleHBlcnRzIG9uIHRoYXQgKGUuZy4sIEkgc2VlbSB0byByZWNhbGwgYSBuZWdhdGl2ZSBzYWFn DQo+ID4+PiBjb21tZW50IG9uIFBLQ1MgMS41IG1lY2hhbmlzbXMgaW4gdGhlIHBhc3QgY291cGxl IG9mIG1vbnRocykuDQo+ID4+DQo+ID4+IFllcywgaXQncyBmaW5lIGZvciBzZWN1cml0eSBhbmQg aXMgY29ycmVjdCBmb3IgaW50ZXJvcC9kZXBsb3ltZW50DQo+ID4+IHJlYXNvbnMuIFBLQ1N2MS41 IGVuY3J5cHRpb24gaXMgd2hhdCdzIGxlc3MgZGVzaXJhYmxlIGlmIG5vdCBkb25lDQo+ID4+IHdl bGwgYW5kIGF0dGVtcHRpbmcgdG8gbWFuZGF0ZSBQU1MgaGVyZSB3b3VsZCBiZSBhIGJhZCBwbGFu Lg0KPiA+DQo+ID4gT2ssIHRoYXQncyB3aGF0IEkgd2FudGVkIHRvIHNlZSBjaGVja2VkLiAgTm8g cHJvYmxlbS4NCj4gPg0KPiA+Pj4gW0RdIEphdmFzY3JpcHQgbG9jYWwgc3RvcmFnZS4NCj4gPg0K PiA+IEFnYWluLCBvbmUgd29yZCBpcyBib3RoZXJpbmcgbWUgLSBoZXJlJ3MgYSBzdWdnZXN0ZWQg Y2hhbmdlIHRvIHRoZSBhYnN0cmFjdDoNCj4gPg0KPiA+ICAgIEhPQkEgaXMgYW4NCj4gPiAgICBh bHRlcm5hdGl2ZSB0byBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgdGhhdCByZXF1aXJlIHBh c3N3b3JkcyBhbmQNCj4gPiAgICB0aGVyZWZvcmUgYXZvaWRzIGFsbCBwcm9ibGVtcyByZWxhdGVk IHRvIHBhc3N3b3Jkcywgc3VjaCBhcyBsZWFrYWdlDQo+ID4gICAgb2Ygc2VydmVyLXNpZGUgcGFz c3dvcmQgZGF0YWJhc2VzLg0KPiA+DQo+ID4gUmVtb3ZlICJhbGwiIC0gb3IgY2hhbmdlIGl0IHRv ICJtYW55IiBvciAiY29tbW9uIi4NCj4gDQo+IEknbSBnb25uYSBzdGljayB3aXRoIGFsbCAtIGFu IGltcGxlbWVudGF0aW9uIG9mIEhPQkEgY2FuIGJlDQo+IHZ1bG5lcmFibGUgdG8gbWFueSB0aGlu Z3MsIGFuZCBvbmUgbGlrZWx5IGJ1dCB0ZW1wb3JhcnkNCj4gc3R5bGUgb2YgaW1wbGVtZW50YXRp b24gKG5vbi1XZWJDcnlwdG8gaW4gYnJvd3NlcnMpIHdpbGwgYmUNCj4gdnVsbmVyYWJsZSAoYXMg d2Ugbm90ZSkgYnV0IHRoZSBwcm90b2NvbCBpdHNlbGYgZG9lcyBhdm9pZA0KPiBhbGwgcGFzc3dv cmQgcHJvYmxlbXMuDQo+IA0KPiBJJ2xsIHBvc3QgLTA4IGluIGEgZmV3IG1pbnV0ZXMgd2l0aCB0 aG9zZSBjaGFuZ2VzLg0KPiANCj4gQ2hlZXJzLA0KPiBTLg0KPiANCj4gDQo+ID4NCj4gPiBUaGFu a3MsDQo+ID4gLS1EYXZpZA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+IEZyb206IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2Qu aWVdDQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMjQsIDIwMTQgNjoxNSBBTQ0KPiA+ PiBUbzogQmxhY2ssIERhdmlkOyBwYXVsLmhvZmZtYW5AdnBuYy5vcmc7IG1pa2VAcGhyZXNoZWV6 LmNvbTsgR2VuZXJhbCBBcmVhDQo+ID4+IFJldmlldyBUZWFtIChnZW4tYXJ0QGlldGYub3JnKTsg b3BzLWRpckBpZXRmLm9yZw0KPiA+PiBDYzogaWV0ZkBpZXRmLm9yZzsgaHR0cC1hdXRoQGlldGYu b3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBHZW4tQVJUIGFuZCBPUFMtRGlyIHJldmlldyBvZiBkcmFm dC1pZXRmLWh0dHBhdXRoLWhvYmEtMDcNCj4gPj4NCj4gPj4NCj4gPj4gSGkgRGF2aWQsDQo+ID4+ DQo+ID4+IFNvcnJ5IGZvciB0aGUgc2xvdyByZXNwb25zZSwgZW5kIG9mIHllYXIgcnVzaCBhbmQg YWxsIHRoYXQuLi4NCj4gPj4NCj4gPj4gQW5kIHRoYW5rcyBmb3IgdGhlIHJldmlldywgcmVzcG9u c2VzIGlubGluZSBhbmQgYSBwcm90by0wOA0KPiA+PiB2ZXJzaW9uIChoYW5kbGluZyB0aGUgdmFy aW91cyBJRVRGIExDIGNvbW1lbnRzKSBpcyBhdCBbMV0NCj4gPj4gd2l0aCBhIGRpZmYgdnMuIDA3 IGF0IFsyXS4gSSdsbCBwbGFuIHRvIHB1Ymxpc2ggdGhhdCBhcyBhbg0KPiA+PiBvZmZpY2lhbCAt MDggaW4gYSBmZXcgZGF5cyBpZiB0aGVyZSBhcmUgbm8gY29tbWVudHMuDQo+ID4+DQo+ID4+IENo ZWVycywNCj4gPj4gUy4NCj4gPj4NCj4gPj4gWzFdIGh0dHBzOi8vZG93bi5kc2cuY3MudGNkLmll L21pc2MvZHJhZnQtaWV0Zi1odHRwYXV0aC1ob2JhLTA4LnR4dA0KPiA+PiBbMl0NCj4gPj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1odHRwYXV0aC1ob2Jh LQ0KPiA+PiAwNy50eHQmdXJsMj1odHRwczovL2Rvd24uZHNnLmNzLnRjZC5pZS9taXNjL2RyYWZ0 LWlldGYtaHR0cGF1dGgtaG9iYS0wOC50eHQNCj4gPj4NCj4gPj4gT24gMTUvMTIvMTQgMjM6MjUs IEJsYWNrLCBEYXZpZCB3cm90ZToNCj4gPj4+IFRoaXMgaXMgYSBjb21iaW5lZCBHZW4tQVJUIGFu ZCBPUFMtRGlyIHJldmlldy4gIEJvaWxlcnBsYXRlIGZvciBib3RoDQo+IGZvbGxvd3MNCj4gPj4g Li4uDQo+ID4+Pg0KPiA+Pj4gSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3Ig dGhpcyBkcmFmdC4gRm9yIGJhY2tncm91bmQgb24NCj4gPj4+IEdlbi1BUlQsIHBsZWFzZSBzZWUg dGhlIEZBUSBhdDoNCj4gPj4+DQo+ID4+PiA8aHR0cDovL3dpa2kudG9vbHMuaWV0Zi5vcmcvYXJl YS9nZW4vdHJhYy93aWtpL0dlbkFydGZhcT4uDQo+ID4+Pg0KPiA+Pj4gUGxlYXNlIHJlc29sdmUg dGhlc2UgY29tbWVudHMgYWxvbmcgd2l0aCBhbnkgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRzDQo+ ID4+PiB5b3UgbWF5IHJlY2VpdmUuDQo+ID4+Pg0KPiA+Pj4gSSBoYXZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgT3BlcmF0aW9uYWwgZGlyZWN0b3JhdGUncw0KPiBvbmdv aW5nDQo+ID4+PiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9j ZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZQ0KPiBjb21tZW50cw0KPiA+Pj4gd2VyZSB3cml0dGVu IHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIG9wZXJhdGlvbmFsIGFyZWEgZGlyZWN0 b3JzLg0KPiA+Pj4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0 aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55DQo+IG90aGVyDQo+ID4+PiBsYXN0IGNhbGwgY29t bWVudHMuDQo+ID4+Pg0KPiA+Pj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtaHR0cGF1dGgtaG9iYS0w Nw0KPiA+Pj4gUmV2aWV3ZXI6IERhdmlkIEJsYWNrDQo+ID4+PiBSZXZpZXcgRGF0ZTogRGVjIFhY LCAyMDE0DQo+ID4+PiBJRVRGIExDIEVuZCBEYXRlOiBEZWMgMjQsIDIwMTQNCj4gPj4+DQo+ID4+ PiBTdW1tYXJ5OiBUaGlzIGRyYWZ0IGlzIG9uIHRoZSByaWdodCB0cmFjaywgYnV0IGhhcyBvcGVu IGlzc3Vlcw0KPiA+Pj4gIAkJZGVzY3JpYmVkIGluIHRoZSByZXZpZXcuDQo+ID4+Pg0KPiA+Pj4g VGhpcyBkcmFmdCBzcGVjaWZpZXMgYSBzaWduYXR1cmUtYmFzZWQgYXV0aGVudGljYXRpb24gbWVj aGFuaXNtIGZvciBIVFRQDQo+ID4+PiB0aGF0IGlzIGJhc2VkIG9uIGFzeW1tZXRyaWMgKHB1Ymxp Yy1wcml2YXRlKSBrZXkgcGFpcnMgd2l0aG91dCB1c2luZw0KPiA+Pj4gY2VydGlmaWNhdGVzLiAg QSBkaWZmZXJlbnQga2V5IHBhaXIgaXMgdXNlZCBieSBlYWNoIHVzZXIgZm9yIGVhY2ggZm9yDQo+ ID4+PiBlYWNoIGhvc3QgKCJ3ZWItb3JpZ2luIiwgc2VlIFtSRkM2NDU0XSksIGFuZCBlYWNoIHNp Z25hdHVyZSBpcyBiYXNlZA0KPiA+Pj4gb24gYSBzZXJ2ZXItZ2VuZXJhdGVkIGNoYWxsZW5nZS4N Cj4gPj4+DQo+ID4+PiBUaGUgZHJhZnQgaXMgZ2VuZXJhbGx5IHdlbGwtd3JpdHRlbiBhbmQgY2xl YXIgb24gdGhlIGF1dGhlbnRpY2F0aW9uDQo+ID4+PiBtZWNoYW5pY3MsIGJ1dCBoYXMgd2Vha25l c3NlcyBpbiBzcGVjaWZ5aW5nIHRoZSBlbnZpcm9ubWVudCB0aGF0DQo+ID4+PiBzdXJyb3VuZHMg dXNlIG9mIHRoaXMgbWVjaGFuaXNtLiAgU29tZSBvZiB0aGVzZSBpc3N1ZXMgYXJlIGJhc2ljIHRo aW5ncw0KPiA+Pj4gdGhhdCBhbnlvbmUgd29ya2luZyBvbiB3ZWIgdGVjaG5vbG9neSBvciBhcHBs aWVkIGNyeXB0byAianVzdCBrbm93cyIsDQo+ID4+PiBidXQgZXZlbiB0aGUgb2J2aW91cyBuZWVk cyB0byBiZSBzdGF0ZWQgd2hlbiBpdCdzIGludGVncmFsIHRvIHNlY3VyaXR5Lg0KPiA+Pj4NCj4g Pj4+IC0tIE1ham9yIGlzc3VlczogLS0NCj4gPj4+DQo+ID4+PiBbMV0gQ2hhbGxlbmdlIHNpemUg YW5kIHByZWRpY3RhYmlsaXR5DQo+ID4+Pg0KPiA+Pj4gSW4gdGhlIEFCTkY6DQo+ID4+Pg0KPiA+ Pj4gICAgY2hhbGxlbmdlID0gMSpiYXNlNjR1cmxjaGFycw0KPiA+Pj4NCj4gPj4+IEkgZGlkIG5v dCBzZWUgYW55IG90aGVyIGRpc2N1c3Npb24gb2YgbWluaW11bSBsZW5ndGggb2YgY2hhbGxlbmdl DQo+ID4+PiBvciBhbW91bnQgb2YgZW50cm9weSBpbiB0aGUgY2hhbGxlbmdlLiAgRm9yIHRoZSBs YXR0ZXIsIGRvIHRoZSBjaGFsbGVuZ2VzDQo+ID4+PiBuZWVkIHRvIGJlIHVucHJlZGljdGFibGU/ ICBJIHdvdWxkIHRoaW5rIHNvLg0KPiA+Pj4NCj4gPj4+IEkgdGhpbmsgYSByZXF1aXJlbWVudCBv biBtaW5pbXVtIGNoYWxsZW5nZSBzaXplIGFuZCBhIHJlY29tbWVuZGF0aW9uIG9uDQo+ID4+PiBt aW5pbXVtIGFtb3VudCBvZiBlbnRyb3B5IHdvdWxkIGJlIGdvb2QgaWRlYXMuDQo+ID4+DQo+ID4+ IEZhaXIgcG9pbnQuIEFuZCB5b3UncmUgcmlnaHQgdGhhdCB0aGlzIGlzIGFzc3VtZWQgYW5kIG91 Z2h0IGJlDQo+ID4+IGV4cGxpY2l0LCBzbyBnb29kIGNhdGNoLg0KPiA+Pg0KPiA+PiBPTEQ6DQo+ ID4+DQo+ID4+ICAgIG8gIGNoYWxsZW5nZTogTVVTVCBiZSBhIGJhc2U2NHVybCBlbmNvZGVkIGNo YWxsZW5nZSB2YWx1ZSB0aGF0IHRoZQ0KPiA+PiAgICAgICBzZXJ2ZXIgY2hvc2UgdG8gc2VuZCB0 byB0aGUgY2xpZW50DQo+ID4+DQo+ID4+IE5FVzoNCj4gPj4NCj4gPj4gICAgbyAgY2hhbGxlbmdl OiBNVVNUIGJlIGEgYmFzZTY0dXJsIGVuY29kZWQgY2hhbGxlbmdlIHZhbHVlIHRoYXQgdGhlDQo+ ID4+ICAgICAgIHNlcnZlciBjaG9zZSB0byBzZW5kIHRvIHRoZSBjbGllbnQuIFRoZSBjaGFsbGVu Z2UgTVVTVCBiZSBjaG9zZW4NCj4gPj4gICAgICAgc28gdGhhdCBpdCBpcyBpbmZlYXNpYmxlIHRv IGd1ZXNzLCBhbmQgU0hPVUxEIGJlIGluZGlzdGluZ3Vpc2hhYmxlDQo+ID4+ICAgICAgIGZyb20g KHRoZSBiYXNlNjR1cmwgZW5jb2Rpbmcgb2YpIGFuIGF0IGxlYXN0IDEyOC1iaXQgbG9uZyByYW5k b20NCj4gPj4gICAgICAgc3RyaW5nLg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFsyXSBDaGFsbGVuZ2Ug dmVyaWZpY2F0aW9uIGFuZCByZXVzZQ0KPiA+Pj4NCj4gPj4+IFRoaXMgc2VudGVuY2Ugb24gcC42 IHN0cmlrZXMgbWUgYXMgc3VidGx5IGRhbmdlcm91czoNCj4gPj4+DQo+ID4+PiAgICBUaGUgY2hh bGxlbmdlIGhvd2V2ZXIgaXMgc2VudCBvdmVyDQo+ID4+PiAgICB0aGUgbmV0d29yayBzbyBhcyB0 byBtYWtlIGl0IHNpbXBsZXIgZm9yIGEgc2VydmVyIHRvIGJlIHN0YXRlbGVzcy4NCj4gPj4+ICAg IChPbmUgZm9ybSBvZiBzdGF0ZWxlc3MgY2hhbGxlbmdlIG1pZ2h0IGJlIGEgY2lwaGVydGV4dCB0 aGF0IHRoZQ0KPiA+Pj4gICAgc2VydmVyIGRlY3J5cHRzIGFuZCBjaGVja3MsIGJ1dCB0aGF0IGlz IGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC4pDQo+ID4+Pg0KPiA+Pj4gVGhlIGRyYWZ0IGVsc2V3 aGVyZSBhc3NlcnRzIG9yIGFzc3VtZXMgdGhhdCBjaGFsbGVuZ2UgcmV1c2UgY2FuIGJlDQo+ID4+ PiBwcmV2ZW50ZWQgYnkgdGhlIHNlcnZlciBvciBiZSB0aW1lLWJvdW5kZWQgYnkgbWF4LWFnZSwg YW5kIHJlbGllcyBvbg0KPiA+Pj4gdGhvc2UgcmV1c2UgbGltaXRzIGZvciBzZWN1cml0eSBwcm9w ZXJ0aWVzLCBlLmcuLCBhcyBpbiB0aGlzIHNlbnRlbmNlDQo+ID4+PiBuZWFyIHRoZSBlbmQgb2Yg U2VjdGlvbiA2LjE6DQo+ID4+Pg0KPiA+Pj4gICAgTm90ZSB0aGF0IHJlcGxheSBvZiByZWdpc3Ry YXRpb24gKGFuZCBvdGhlciBIT0JBKSBtZXNzYWdlcyBpcyBxdWl0ZQ0KPiA+Pj4gICAgcG9zc2li bGUuICBUaGF0IGhvd2V2ZXIgY2FuIGJlIGNvdW50ZXJhY3RlZCBpZiBjaGFsbGVuZ2UgZnJlc2hu ZXNzIGlzDQo+ID4+PiAgICBlbnN1cmVkLg0KPiA+Pj4NCj4gPj4+IFRoZSBzZW50ZW5jZSBxdW90 ZWQgZnJvbSBwLjYgYXBwZWFycyB0byBhbGxvdyAob3IgZXZlbiBlbmNvdXJhZ2UpDQo+ID4+PiBz dGF0ZWxlc3Mgc2VydmVycyB0byBpbXBsZW1lbnQgcmF0aGVyIHdlYWsgY2hlY2tzIG9uIG5vdCBv bmx5IGNoYWxsZW5nZQ0KPiA+Pj4gcmV1c2UsIGJ1dCBhbHNvIGNoYWxsZW5nZSB2YWxpZGl0eSAo ZS5nLiwgd2hhdCBpZiB0aGUgY2hhbGxlbmdlIHZhbGlkaXR5DQo+ID4+PiB0ZXN0IHdlcmUgImNo YWxsZW5nZSBtb2QgMTAyNCA9PSA3IiA/KS4NCj4gPj4+DQo+ID4+PiBBbGxvd2luZyBzdWNoIHdl YWsgY2hlY2tzIGNvdWxkIGVuYWJsZSBhbiBhdHRhY2tlciB0byBjaG9vc2Ugb3IgaW5mbHVlbmNl DQo+ID4+PiB0aGUgY2hvaWNlIG9mIGNoYWxsZW5nZSB2YWx1ZXMsIHdoaWNoIGNvdWxkIGJlIHVz ZWZ1bCAoZS5nLiwgZm9yDQo+ID4+PiBkaWZmZXJlbnRpYWwgY3J5cHRhbmFseXNpcyBhdHRhY2sg b24gdGhlIGhhc2ggZnVuY3Rpb24pLCBhcyB0aGUNCj4gPj4+IGF0dGFja2VyIChjbGllbnQpIGFs cmVhZHkgY29udHJvbHMgdGhlIG5vbmNlLg0KPiA+Pj4NCj4gPj4+IEFzIHBhcnQgb2YgdGhpcywg dGhlIHNlcnZlciBuZWVkcyB0byBjaGVjayB3aGV0aGVyIGEgY2hhbGxlbmdlIHByZXNlbnRlZA0K PiA+Pj4gb24gb25lIGNvbm5lY3Rpb24gb3Igc2Vzc2lvbiBoYXMgYmVlbiByZXVzZWQgb24gYW5v dGhlci4gIEkgdGhpbmsgdGhlDQo+ID4+PiBmb2xsb3dpbmcgc2VudGVuY2UgaW4gc2VjdGlvbiAz IGlzIGludGVuZGVkIHRvIHByZXZlbnQgdGhpcywgYnV0IGl0J3MNCj4gPj4+IHdlYWtlbmVkIGJ5 IHRoZSAic3RhdGVsZXNzIiBsYW5ndWFnZSBhYm92ZToNCj4gPj4+DQo+ID4+PiAgICAgICBUaGUg Y2hhbGxlbmdlIE1VU1QgYmUNCj4gPj4+ICAgICAgIHVuaXF1ZSBmb3IgZXZlcnkgSFRUUCA0MDEg cmVzcG9uc2UgaW4gb3JkZXIgdG8gcHJldmVudCByZXBsYXkNCj4gPj4+ICAgICAgIGF0dGFja3Mg ZnJvbSBwYXNzaXZlIG9ic2VydmVycy4NCj4gPj4+DQo+ID4+PiBFeHBsaWNpdCBzZXJ2ZXIgY2hl Y2tzIGZvciBjaGFsbGVuZ2UgcmV1c2Ugb3VnaHQgdG8gYmUgUkVRVUlSRUQsIGFuZA0KPiA+Pj4g dGhlIGFib3ZlIHVzZSBvZiAic3RhdGVsZXNzIiBuZWVkcyB0byBiZSBxdWFsaWZpZWQuDQo+ID4+ DQo+ID4+IEhtbS4gSSB0aGluayB0aGF0IEhPQkEgb3VnaHQgbm90IFJFUVVJUkUgZnVsbCByZXBs YXkgcHJvdGVjdGlvbg0KPiA+PiBpbiBhbGwgY2FzZXMsIHRoYXQgaXMsIGl0IFNIT1VMRCBiZSBw b3NzaWJsZSB0byBkZXBsb3kgYSBzZXJ2ZXINCj4gPj4gdGhhdCBpcyB2dWxuZXJhYmxlIHRvIHNv bWUgcmVwbGF5LiBUaGUgcmVhc29uIGlzIHRoYXQgd2UncmUgdHJ5aW5nDQo+ID4+IHRvIGRpc3Bs YWNlIHBhc3N3b3JkcyBoZXJlIGFuZCBJIGJlbGlldmUgKHdpdGhvdXQgbXVjaCBoYXJkIGV2aWRl bmNlDQo+ID4+IEknbGwgZ3JhbnQgeW91KSB0aGF0IHdlJ2QgbG9zZSBzb21lIGRlcGxveW1lbnQg Y2hhbmNlcyBpZiB3ZSB3ZXJlDQo+ID4+IHRvIGluc2lzdCBvbiBldmVyeSBzaW5nbGUgY2hhbGxl bmdlIGJlaW5nIGZyZXNoLg0KPiA+Pg0KPiA+PiBTbyBJJ2QgYXJndWUgZm9yIG5vLWNoYW5nZSBo ZXJlLCBidXQgd291bGQgd2VsY29tZSBmdXJ0aGVyIGRpc2N1c3Npb25tDQo+ID4+IGV2aWRlbmNl IG9yIHN1Z2dlc3Rpb25zIGZvciB0ZXh0IHRoYXQncyBub3QgZ29pbmcgdG8gYmUgc28gb25lcm91 cw0KPiA+PiBhcyB0byB3ZWFrZW4gb3VyIGNoYW5jZXMgb2YgZ2V0dGluZyB0aGlzIGRlcGxveWVk Lg0KPiA+Pg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFszXSBXZWIgb3JpZ2luIGNoZWNrcw0KPiA+Pj4N Cj4gPj4+IEkgZGlkIG5vdCBzZWUgdGV4dCBtYW5kYXRpbmcgdGhhdCBUTFMgKHNlcnZlciBjZXJ0 aWZpY2F0ZSksIEhUVFAgKGFjY2Vzc2VkDQo+ID4+PiBVUkwpIGFuZCBIT0JBIChzaWduYXR1cmUg aW5wdXQpIHVzZSB0aGUgc2FtZSB3ZWIgb3JpZ2luLCBhbmQgc3RhdGluZyB0aGF0DQo+ID4+PiB0 aGUgc2VydmVyIGhhcyB0byBjaGVjay9lbmZvcmNlIHRoaXMuICBEaWQgSSBtaXNzIHNvbWV0aGlu Zz8NCj4gPj4+DQo+ID4+PiBJIHJlYWxpemUgdGhhdCB0aGlzIGlzIGFuIG9idmlvdXMgcmVxdWly ZW1lbnQsIGJ1dCBpdCBkb2VzIG5lZWQgdG8gYmUNCj4gPj4+IHN0YXRlZC4NCj4gPj4NCj4gPj4g RmFpciBlbm91Z2gsIEkgYWdyZWUgZm9sa3MgaGF2ZSBiZWVuIGtub3duIHRvIG5vdCBpbXBsZW1l bnQgZXZlbiB0aGUNCj4gPj4gbW9zdCBvYnZpb3VzIHRoaW5nczotKSBJIGFkZGVkIHRoZSB0ZXh0 IGJlbG93IHRvIHNlY3Rpb24gMzoNCj4gPj4NCj4gPj4gICAgVGhlIHNlcnZlciBNVVNUIGNoZWNr IHRoYXQgdGhlIHNhbWUgd2ViIG9yaWdpbiBpcyB1c2VkIGluIGFsbCBvZiB0aGUNCj4gPj4gICAg c2VydmVyJ3MgVExTIHNlcnZlciBjZXJ0aWZpY2F0ZSwgdGhlIFVSTCBiZWluZyBhY2Nlc3NlZCBh bmQgdGhlIEhPQkENCj4gPj4gICAgc2lnbmF0dXJlLiAgSWYgYW55IG9mIHRob3NlIGNoZWNrcyBm YWlsLCB0aGUgc2VydmVyIHRyZWF0cyB0aGUNCj4gPj4gICAgc2lnbmF0dXJlIGFzIGJlaW5nIGNy eXB0b2dyYXBoaWNhbGx5IGluY29ycmVjdC4NCj4gPj4NCj4gPj4+DQo+ID4+PiBbNF0gVExTIHJl cXVpcmVtZW50IGxldmVsDQo+ID4+Pg0KPiA+Pj4gVExTIGlzIG9ubHkgYSAiU0hPVUxEIiByZXF1 aXJlbWVudCBmb3IgSE9CQSwgbm90IGEgIk1VU1QiIHJlcXVpcmVtZW50IC0NCj4gPj4+IGZpcnN0 IHBhcmFncmFwaCBpbiBTZWN0aW9uIDguMSAoUHJpdmFjeSBDb25zaWRlcmF0aW9ucykuDQo+ID4+ Pg0KPiA+Pj4gSWYgVExTIGlzIG5vdCBhICJNVVNUIiByZXF1aXJlbWVudCwgYXQgbGVhc3QgYSBk aXNjdXNzaW9uIG9mIG1hbi1pbi10aGUtDQo+ID4+PiBtaWRkbGUgKE1JVE0pIGF0dGFja3Mgc2Vl bXMgdG8gYmUgaW4gb3JkZXIuICBUaGVyZSdzIG5vIG5lZWQgZm9yIGFuDQo+ID4+IGV4dGVuc2l2 ZQ0KPiA+Pj4gZGlzY3Vzc2lvbiBvZiBhbGwgb2YgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2Yg VExTLCBidXQgTUlUTSBhdHRhY2tzIGFyZQ0KPiA+Pj4gZGVmaW5pdGVseSB3b3J0aCBhIG1lbnRp b24sIGFuZCB0aGF0IGNvdWxkIGJlIGNvbXBsZW1lbnRlZCBieSBhIHBvaW50ZXIgdG8NCj4gPj4+ IHN1aXRhYmxlIEhUVFAvVExTIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQgZWxzZXdoZXJl Lg0KPiA+Pg0KPiA+PiBJIHRoaW5rIHRoYXQncyBjb3ZlcmVkIHdoZXJlIHdlIG5vdGUgdGhlIHBv dGVudGlhbCBmb3IgcmVwbGF5LCB3aGljaA0KPiA+PiBpcyB3aGF0IGEgTWl0TSB3b3VsZC9jb3Vs ZCBkbyBpbiB0aGlzIGNhc2UuIFRoYXQgaXMgbm90ZWQgaW4gYm90aA0KPiA+PiBzZWN0aW9uIDMg YW5kIGluIDYuMSBhbmQgaW4gc2VjdGlvbiA4LiBJIHRoaW5rIHdlIGhhdmUgaXQgY292ZXJlZCB0 bw0KPiA+PiBiZSBob25lc3QuDQo+ID4+DQo+ID4+Pg0KPiA+Pj4gWzVdIFNlY3Rpb24gNS4zIC0g dW5yZWNvZ25pemVkIGtleQ0KPiA+Pj4NCj4gPj4+IFBhcmFncmFwaHMgNCBhbmQgNSBpbiB0aGlz IHNlY3Rpb24gZG9uJ3Qgc2VlbSB0byBiZWxvbmcgaGVyZSwgYW5kIGFwcGVhcg0KPiB0bw0KPiA+ Pj4gYmUgd3JpdHRlbiBpbiBhIHNvbWV3aGF0IGxvb3NlIGZhc2hpb24sIHBhcnRpY3VsYXJseSBh cm91bmQgdXNlcg0KPiA+PiB2ZXJpZmljYXRpb24uDQo+ID4+PiBBIHNlcnZlciB0aGF0IGRvZXMg d2hhdCBpcyBzdWdnZXN0ZWQgaGVyZSBjb3VsZCBoYXZlIHNpZ25pZmljYW50IHNlY3VyaXR5DQo+ ID4+PiB3ZWFrbmVzc2VzLg0KPiA+Pg0KPiA+PiBXaGljaCBzcGVjaWZpYyB3ZWFrbmVzc2VzIGRv IHlvdSBtZWFuPw0KPiA+Pg0KPiA+Pj4NCj4gPj4+IEkgc3Ryb25nbHkgcmVjb21tZW5kIHJlcGxh Y2luZyB0aG9zZSB0d28gcGFyYWdyYXBocyB3aXRoIGEgc2hvcnQgc2VudGVuY2UNCj4gPj4gdGhh dA0KPiA+Pj4gc2F5czoNCj4gPj4+IAktIGlmIGEga2lkIGlzIHVucmVjb2duaXplZCBvciB0aGUg c2VydmVyIG90aGVyd2lzZSBkZXRlcm1pbmVzDQo+ID4+PiAJCXRoYXQgdGhlIENQSyBpcyBub3Qg dG8gYmUgdXNlZCBmb3IgdGhpcyBIVFRQIGF1dGhlbnRpY2F0aW9uLA0KPiA+Pj4gCS0gdGhlbiB0 aGUgUmVnaXN0cmF0aW9uIChzZWUgNi4xKSBhbmQvb3IgQXNzb2NpYXRpbmcgQWRkaXRpb25hbCBL ZXlzIHRvDQo+ID4+PiAJCWFuIEV4aXRpbmcgQWNjb3VudCAoc2VlIDYuMikgcHJvY2Vzc2VzIE1B WSBiZSB1c2VkIGluc3RlYWQgb2YNCj4gPj4+IAkJdHJlYXRpbmcgdGhpcyBzaXR1YXRpb24gYXMg YW4gYXV0aGVudGljYXRpb24gZmFpbHVyZS4NCj4gPj4+DQo+ID4+PiBhbmQgbW92aW5nIGFsbCBk aXNjdXNzaW9uIG9mIHVzZXIgdmVyaWZpY2F0aW9uIGludG8gU2VjdGlvbnMgNi4xIGFuZCA2LjIu DQo+ID4+DQo+ID4+IFNvcnJ5LCBJIGRvbid0IHRoaW5rIHRoYXQgaXMgbmVlZGVkIGF0IGFsbC4g VGhlIGN1cnJlbnQgdGV4dCBzaW1wbHkNCj4gPj4gcmVmbGVjdHMgdGhlIGtpbmQgb2YgdGhpbmcg dGhhdCB3ZSB0aGluayBkZXBsb3ltZW50cyB3aWxsIGRvIGFuZCB3aWxsDQo+ID4+IG5lZWQgdG8g ZG8gYW5kIEkgZG9uJ3Qgc2VlIHdoYXQgc3BlY2lmaWMgd2Vha25lc3NlcyB5b3UgYXJlIGNsYWlt aW5nDQo+ID4+IG1pZ2h0IGVuc3VlLiBJJ2QgYmUgaGFwcHkgdG8gbm90ZSBhbnkgc3VjaCBvZiBj b3Vyc2UuDQo+ID4+DQo+ID4+IEFsc28sIGZyb20gbXkgcmVhZGluZyB5b3VyIHN1Z2dlc3RlZCB0 ZXh0IGhhcyB0aGUgc2FtZSBpbXBhY3QgYW5kDQo+ID4+IG9ubHkgZGlmZmVycyBpbiB1c2luZyBh IDIxMTkgTUFZIGluc3RlYWQgb2YgY291bGQsIG1pZ2h0IGV0Yy4gQnV0IGlmDQo+ID4+IHlvdSBt ZWFudCBpdCB0byBkaWZmZXIgbW9yZSBzdWJzdGFudGl2ZWx5IHlvdSdsbCBuZWVkIHRvIGV4cGxh aW4gdGhhdA0KPiA+PiB0byBtZSBzb21lIG1vcmUuDQo+ID4+DQo+ID4+Pg0KPiA+Pj4gLS0gTWlu b3IgaXNzdWVzOiAtLQ0KPiA+Pj4NCj4gPj4+IFtBXSBBQk5GIGVuY29kaW5nIG9mIGFsZw0KPiA+ Pj4NCj4gPj4+IEluIHNlY3Rpb24gMiwgSSBzZWU6DQo+ID4+Pg0KPiA+Pj4gICAgYWxnID0gMSoy RElHSVQNCj4gPj4+DQo+ID4+PiAgICBvICBhbGc6IHNwZWNpZmllcyB0aGUgc2lnbmF0dXJlIGFs Z29yaXRobSBiZWluZyB1c2VkIGVuY29kZWQgYXMgYW4NCj4gPj4+ICAgICAgIEFTQ0lJIGNoYXJh Y3RlciBhcyBkZWZpbmVkIGluIFNlY3Rpb24gOS4zLg0KPiA+Pj4NCj4gPj4+IFNlY3Rpb24gOS4z IHNwZWNpZmllcyBhIHNpbmdsZSBkaWdpdC4gIEhvdyBkb2VzIHRoYXQgYmVjb21lIDEqMkRJR0lU ID8NCj4gPj4NCj4gPj4gSHVoPyBUaGUgY3VycmVudCBhbGdzIG9ubHkgdXNlIG9uZSBkaWdpdCwg YnV0IHRoZSBhYm5mIGFsbG93cyBmb3INCj4gPj4gbW9yZS4gTm90aGluZyBvZGQgdGhlcmUgdGhh dCBJIGNhbiBzZWUuDQo+ID4+DQo+ID4+PiBJIHN1Z2dlc3Q6ICJhcyBhbiBBU0NJSSBjaGFyYWN0 ZXIiIC0+ICJhcyBvbmUgb3IgdHdvIEFTQ0lJIGRpZ2l0cyBiYXNlZA0KPiA+Pj4gb24gdGhlIElB TkEgcmVnaXN0cnkgZXN0YWJsaXNoZWQgYnkgU2VjdGlvbiA5LjMiDQo+ID4+DQo+ID4+IEkgdGhp bmsgaXQncyBvayBhcyBpcy4NCj4gPj4NCj4gPj4+IFRoaXMgbWF5IHNlZW0gbGlrZSBhIG5pdCwg YnV0IGFueSBpbXByZWNpc2lvbiBpbiBzaWduYXR1cmUgYWxnb3JpdGhtDQo+ID4+PiBpbnB1dCBj YW4gbGVhZCB0byBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLg0KPiA+Pg0KPiA+PiBZZXMgaXQg Y2FuLiBCdXQgd2UncmUgbm90IGJlaW5nIGltcHJlY2lzZSB0aGF0IEkgY2FuIHNlZS4NCj4gPj4N Cj4gPj4+DQo+ID4+PiBbQl0gU2VjdGlvbiA1LjMgLSBDUEsgdnMuIGtpZA0KPiA+Pj4NCj4gPj4+ ICAgIEluIHRoZSBhdXRoZW50aWNhdGlvbiBwaGFzZSwgdGhlIHNlcnZlciBleHRyYWN0cyB0aGUg Q1BLIGZyb20gdGhlDQo+ID4+PiAgICBzaWduaW5nIHBoYXNlIGFuZCBkZWNpZGVzIGlmIGl0IHJl Y29nbml6ZXMgdGhlIENQSy4gIElmIHRoZSBzZXJ2ZXINCj4gPj4+ICAgIHJlY29nbml6ZXMgdGhl IENQSywgdGhlIHNlcnZlciBtYXkgZmluaXNoIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24NCj4g Pj4+ICAgIHByb2Nlc3MuDQo+ID4+Pg0KPiA+Pj4gVGhhdCBzZWVtcyB3cm9uZy4gIElJVUMsIHRo ZSBIT0JBIGNsaWVudCBzZW5kczoNCj4gPj4+DQo+ID4+PiAgICBIT0JBLVJFUyA9IGtpZCAiLiIg Y2hhbGxlbmdlICIuIiBub25jZSAiLiIgc2lnDQo+ID4+Pg0KPiA+Pj4gSWYgc28sIEkgZG9uJ3Qg dW5kZXJzdGFuZCBob3cgdGhlIHNlcnZlciBleHRyYWN0cyBhIENQSyBmcm9tIHRoYXQuDQo+ID4+ DQo+ID4+IFZpYSB0aGUga2lkIHllcy4NCj4gPj4NCj4gPj4+DQo+ID4+PiBJIHN1c3BlY3QgdGhh dCB3aGF0IHdhcyBpbnRlbmRlZCBpcyB0aGF0IHRoZSBzZXJ2ZXIgZXh0cmFjdHMgYSBrZXkNCj4g Pj4gaWRlbnRpZmllcg0KPiA+Pj4gKGtpZCkgYW5kIHRoZW4gZGV0ZXJtaW5lcyBhKSB3aGV0aGVy IGl0IGtub3dzIGEgQ1BLIGZvciB0aGF0IGtpZCBhbmQgYikNCj4gPj4gd2hldGhlcg0KPiA+Pj4g aXQgYWxsb3dzIHVzZSBvZiB0aGF0IGtpZC9DUEsgZm9yIHRoaXMgYXV0aGVudGljYXRpb24uICBB dCBsZWFzdCBhKSBzZWVtcw0KPiB0bw0KPiA+Pj4gYmUgaW5kaWNhdGVkIGJ5IHRoaXMgdGV4dCBp biBTZWN0aW9uIDM6DQo+ID4+Pg0KPiA+Pj4gICAgVGhlIHNlcnZlciBNVVNUIGNoZWNrIHRoZSBj cnlwdG9ncmFwaGljIGNvcnJlY3RuZXNzIG9mIHRoZSBzaWduYXR1cmUNCj4gPj4+ICAgIGJhc2Vk IG9uIGEgcHVibGljIGtleSBpdCBrbm93cyBmb3IgdGhlIGtpZCBpbiB0aGUgc2lnbmF0dXJlcywN Cj4gPj4NCj4gPj4gSSdtIG5vdCBzZWVpbmcgYW4gYWN0aW9uYWJsZSBpc3N1ZSB0aGF0IG5lZWRz IGEgY2hhbmdlLg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFtDXSBSU0Egc2lnbmF0dXJlIGFsZ29yaXRo bQ0KPiA+Pj4NCj4gPj4+IFNlY3Rpb24gNyBzYXlzOg0KPiA+Pj4NCj4gPj4+ICAgIFJTQSBpcyBk ZWZpbmVkIGluDQo+ID4+PiAgICBTZWN0aW9uIDguMiBvZiBbUkZDMzQ0N10sIGFuZCBTSEEtMSBh bmQgU0hBLTI1NiBhcmUgZGVmaW5lZCBpbiBbU0hTXS4NCj4gPj4+DQo+ID4+PiBTZWN0aW9uIDgu MiBvZiBSRkMgMzQ0NyBzcGVjaWZpZXMgUlNBU1NBLVBLQ1MxLXYxXzUuICBBdCBhIG1pbmltdW0s IHRoYXQNCj4gPj4+IGFsZ29yaXRobSBuYW1lIHNob3VsZCBiZSBzdGF0ZWQgaGVyZSAod2hpY2gg aXMgYSBuaXQpLg0KPiA+Pg0KPiA+PiBEaXNhZ3JlZSAoYWxzbyBhcyBhIG5pdDotKQ0KPiA+Pg0K PiA+Pj4gVGhlIG1pbm9yIGlzc3VlIGlzDQo+ID4+PiB3aGV0aGVyIHRoYXQgaXMgdGhlIHNpZ25h dHVyZSBhbGdvcml0aG0gdGhhdCdzIHdhbnRlZCwgb24gd2hpY2ggSSdsbCBkZWZlcg0KPiA+Pj4g dG8gdGhlIGNyeXB0byBleHBlcnRzIG9uIHRoYXQgKGUuZy4sIEkgc2VlbSB0byByZWNhbGwgYSBu ZWdhdGl2ZSBzYWFnDQo+ID4+PiBjb21tZW50IG9uIFBLQ1MgMS41IG1lY2hhbmlzbXMgaW4gdGhl IHBhc3QgY291cGxlIG9mIG1vbnRocykuDQo+ID4+DQo+ID4+IFllcywgaXQncyBmaW5lIGZvciBz ZWN1cml0eSBhbmQgaXMgY29ycmVjdCBmb3IgaW50ZXJvcC9kZXBsb3ltZW50DQo+ID4+IHJlYXNv bnMuIFBLQ1N2MS41IGVuY3J5cHRpb24gaXMgd2hhdCdzIGxlc3MgZGVzaXJhYmxlIGlmIG5vdCBk b25lDQo+ID4+IHdlbGwgYW5kIGF0dGVtcHRpbmcgdG8gbWFuZGF0ZSBQU1MgaGVyZSB3b3VsZCBi ZSBhIGJhZCBwbGFuLg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFtEXSBKYXZhc2NyaXB0IGxvY2FsIHN0 b3JhZ2UuDQo+ID4+Pg0KPiA+Pj4gVGhlIGZpcnN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDguMiBv biB0aGlzIHRvcGljIGNvbmNsdWRlcyB3aXRoOg0KPiA+Pj4NCj4gPj4+ICAgIEl0J3Mgbm90IGNs ZWFyIHRoYXQgd2UNCj4gPj4+ICAgIGludHJvZHVjZSB1bmlxdWUgdGhyZWF0cyBmcm9tIHdoaWNo IGNsZWFyIHRleHQgcGFzc3dvcmRzIGRvbid0DQo+ID4+PiAgICBhbHJlYWR5IHN1ZmZlci4NCj4g Pj4+DQo+ID4+PiBUaGF0J3MgYXQgb2RkcyB3aXRoIHRoZSB1c2Ugb2YgImFsbCIgaW4gdGhpcyBz ZW50ZW5jZSBpbiB0aGUgYWJzdHJhY3Q6DQo+ID4+Pg0KPiA+Pj4gICAgSE9CQSBpcyBhbg0KPiA+ Pj4gICAgYWx0ZXJuYXRpdmUgdG8gSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIHRoYXQgcmVx dWlyZSBwYXNzd29yZHMgYW5kDQo+ID4+PiAgICB0aGVyZWZvcmUgYXZvaWRzIGFsbCBwcm9ibGVt cyByZWxhdGVkIHRvIHBhc3N3b3Jkcywgc3VjaCBhcyBsZWFrYWdlDQo+ID4+PiAgICBvZiBzZXJ2 ZXItc2lkZSBwYXNzd29yZCBkYXRhYmFzZXMuDQo+ID4+Pg0KPiA+Pj4gT25lIG9mIHRob3NlIHR3 byBwYXJhZ3JhcGhzIG5lZWRzIHNvbWUgZWRpdGluZy4NCj4gPj4NCj4gPj4gSSBkb24ndCB0aGlu ayBzbyBhY3R1YWxseSwgdGhlIGZpcnN0IHF1b3RlZCBzZW50ZW5jZSBhYm92ZSBpcyBpbiB0aGUN Cj4gPj4gY29udGV4dCBvZiBhIHdlYiBzaXRlIHdpdGggWFNTIHZ1bG5lcmFiaWxpdGllcy4gT21p dHRpbmcgdGhhdCBjb250ZXh0DQo+ID4+IHdvdWxkIG1ha2UgZm9yIGJhZCB0ZXh0LCBidXQgdGhl IGltbWVkaWF0ZWx5IHByZWNlZGluZyBzZW50ZW5jZSBpcw0KPiA+PiBmYWlybHkgZXhwbGljaXQg b24gdGhhdC4NCj4gPj4NCj4gPj4gKEluIHBhc3NpbmcsIEkgZGlkIGVkaXQgdGhlIHRvcCBvZiB0 aGF0IHBhcmEgYSBiaXQsIHNpbmNlIHVzaW5nIHRoZQ0KPiA+PiBXZWJDcnlwdG8gQVBJIGlzIG5v dyBwb3NzaWJsZSBzbyBhIHR3ZWFrIHdhcyBuZWVkZWQuKQ0KPiA+Pg0KPiA+Pj4NCj4gPj4+IC0t IE5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOiAtLQ0KPiA+Pj4NCj4gPj4+IFRoaXMgaXMgYnVyaWVk IG5lYXIgdGhlIGVuZCBvZiBzZWN0aW9uIDYuMQ0KPiA+Pj4NCj4gPj4+ICAgIE5vdGUgdGhhdCBy ZXBsYXkgb2YgcmVnaXN0cmF0aW9uIChhbmQgb3RoZXIgSE9CQSkgbWVzc2FnZXMgaXMgcXVpdGUN Cj4gPj4+ICAgIHBvc3NpYmxlLiAgVGhhdCBob3dldmVyIGNhbiBiZSBjb3VudGVyYWN0ZWQgaWYg Y2hhbGxlbmdlIGZyZXNobmVzcyBpcw0KPiA+Pj4gICAgZW5zdXJlZC4NCj4gPj4+DQo+ID4+PiBU aGF0J3Mgbm90IGEgZ29vZCBwbGFjZSBmb3IgdGhlc2UgdHdvIHNlbnRlbmNlcy4gIEhPQkEgcmVn aXN0cmF0aW9uDQo+ID4+PiBtZXNzYWdlcyBkb24ndCBjb250YWluIGEgY2hhbGxlbmdlLCBhbmQg dGhlIGdlbmVyYWwgZGlzY3Vzc2lvbiBvZg0KPiA+Pj4gcmVwbGF5IGF0dGFja3MgYmVsb25ncyB1 bmRlciBTZWN1cml0eSBDb25zaWRlcmF0aW9ucywgbm90IFJlZ2lzdHJhdGlvbi4NCj4gPj4NCj4g Pj4gVGhleSBkbyBjb250YWluIGEgY2hhbGxlbmdlIGluIHRoZSBoZWFkZXIsIHRob3VnaCBub3Qg aW4gdGhlIGJvZHkuDQo+ID4+IEkgdGhpbmsgdGhlIHNlbnRlbmNlIGlzIG9rIHdoZXJlIGl0IGlz Lg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IEluIFNlY3Rpb24gOS40IGFuZCA5LjUsIEkgc2VlIHRoZSBm b2xsb3dpbmcgcHJvcG9zZWQgYXMgcGFydCBvZiBJQU5BDQo+ID4+PiByZWdpc3RyeSBjb250ZW50 czoNCj4gPj4+DQo+ID4+PiAJYW4gdW5mb3JtYXR0ZWQgc3RyaW5nLCBhdCB0aGUgdXNlcidzL1VB J3Mgd2hpbQ0KPiA+Pj4NCj4gPj4+IEkgZ2V0IHRoZSBwb2ludCwgYnV0IGl0J3Mgc3RpbGwgbm90 IGFwcHJvcHJpYXRlIGZvciBhbiBJQU5BIHJlZ2lzdHJ5DQo+ID4+PiAtIHJlbW92ZSAiLCBhdCB0 aGUgdXNlcidzL1VBJ3Mgd2hpbSIuDQo+ID4+DQo+ID4+IEkgd2hpbXNpY2FsbHkgZGlzYWdyZWU6 LSkgSUFOQSBzaG91bGRuJ3QgYmUgYWdhaW5zdCB3aGltc3kuDQo+ID4+DQo+ID4+PiBBcHBlbmRp eCBBIGFwcGVhcnMgIHRvIGFzc3VtZSB0aGF0IGh1bWFuLW1lbW9yYWJsZSBwYXNzd29yZHMgYXJl IHN0b3JlZCBpbg0KPiA+Pj4gdGhlIGNsZWFyIGluIHNlcnZlciBkYXRhYmFzZXMuICBJdCBzaG91 bGQgYWxzbyBicmllZmx5IGRpc2N1c3MgdGhlIHVzZQ0KPiA+Pj4gb2Ygb25lLXdheSBmdW5jdGlv bnMsIGVzcGVjaWFsbHkgY29tcHV0YXRpb25hbGx5IGludGVuc2l2ZSBvbmVzLCB0bw0KPiA+Pj4g Z2VuZXJhdGUgc3RvcmVkIHBhc3N3b3JkIHZlcmlmaWVycy4gIEhPQkEgaXMgc3RpbGwgc3VwZXJp b3IgYnkgY29tcGFyaXNvbiwNCj4gPj4+IGFzIHRoZSBvbmUtd2F5IGZ1bmN0aW9ucyBvbmx5IGlu Y3JlYXNlIHRoZSBkaWZmaWN1bHR5IG9mIGRpY3Rpb25hcnkNCj4gPj4+IGF0dGFjaywgd2hlcmVh cyBkaWN0aW9uYXJ5IGF0dGFjayBvbiBIT0JBIGtleXMgaXMgcG9pbnRsZXNzIHdoZW4NCj4gPj4+ IHN1ZmZpY2llbnRseSBsYXJnZSBrZXlzIGFyZSB1c2VkLg0KPiA+Pg0KPiA+PiBJJ2QgcHJlZmVy IHRvIG5vdCBnZXQgaW50byBtb3JlIGFuYWx5c2lzIG9mIHBhc3N3b3JkcywgYW5kIGV2ZW4gaGFz aGVkDQo+ID4+IHBhc3N3b3JkcyBhcmUgZXNzZW50aWFsbHkgZ3Vlc3NhYmxlLg0KPiA+Pg0KPiA+ Pj4NCj4gPj4+IGlkbml0cyAyLjEzLjAxIGZvdW5kIHRoZSByZWZlcmVuY2VzIHRvIFczQydzIHdl YiBzaXRlICh3d3cudzMub3JnKSBpbg0KPiA+Pj4gU2VjdGlvbiA0LCBlLmcuLA0KPiA+Pj4NCj4g Pj4+IDM4OQkgICBPbmUgZWxlbWVudCBpcyByZXF1aXJlZCBmb3IgSE9CQS1qczogbG9jYWxTdG9y YWdlIChzZWUgaHR0cDovLw0KPiA+Pj4gMzkwCSAgIHd3dy53My5vcmcvVFIvd2Vic3RvcmFnZS8p IGZyb20gSFRNTDUgY2FuIGJlIHVzZWQgZm9yDQo+IHBlcnNpc3RlbnQga2V5DQo+ID4+PiAzOTEJ ICAgc3RvcmFnZS4NCj4gPj4+DQo+ID4+PiBJIHRoaW5rIGlkbml0cyBjYW4gYmUgaWdub3JlZCwg ZXZlbiB0aG91Z2ggdGhlICJyaWdodCB3YXkiIHRvIGZpeCB0aGlzIGlzDQo+IHRvDQo+ID4+PiBt b3ZlIGVhY2ggVVJMIHRvIGEgcmVmZXJlbmNlIGFuZCBjaXRlIHRoZSByZWZlcmVuY2UgaW4gU2Vj dGlvbiA0Lg0KPiA+Pj4NCj4gPj4+IE9UT0gsIGlkbml0cyBkaWQgbm90IGNvbXBsYWluIGFib3V0 IHRoZSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIFJGQyAyMCA7LSkuDQo+ID4+DQo+ID4+IEhlaDot KQ0KPiA+Pg0KPiA+Pj4NCj4gPj4+IC0tLSBTZWxlY3RlZCBSRkMgNTcwNiBBcHBlbmRpeCBBIFEm QSBmb3IgT1BTLURpciByZXZpZXcgLS0tDQo+ID4+Pg0KPiA+Pj4gTW9zdCBvZiB0aGVzZSBxdWVz dGlvbnMgYXJlIG4vYSBiZWNhdXNlIHRoaXMgZHJhZnQgZGVzY3JpYmVzIGFuIGV4dGVuc2lvbg0K PiA+Pj4gdG8gSFRUUCBhdXRoZW50aWNhdGlvbiwgYW5kIFJGQyA1NzA2J3MgY29uY2VybnMgd291 bGQgYXBwbHkgcHJpbWFyaWx5IHRvDQo+ID4+PiBIVFRQIGFuZCBIVFRQIGF1dGhlbnRpY2F0aW9u Lg0KPiA+Pj4NCj4gPj4+IEEuMS4xICAgIEhhcyBkZXBsb3ltZW50IGJlZW4gZGlzY3Vzc2VkPw0K PiA+Pj4NCj4gPj4+IFllcywgc2VjdGlvbiA2IGRpc2N1c3NlcyBob3cgYSB1c2VyIHdvdWxkIGRl cGxveSB0aGlzIGZvciBoZXIgYWNjZXNzIHRvDQo+IHdlYg0KPiA+Pj4gc2VydmVycy4NCj4gPj4+ DQo+ID4+PiBBLjEuNC4gIEhhdmUgdGhlIFJlcXVpcmVtZW50cyBvbiBvdGhlciBwcm90b2NvbHMg YW5kIGZ1bmN0aW9uYWwNCj4gPj4+ICAgICAgICBjb21wb25lbnRzIGJlZW4gZGlzY3Vzc2VkPw0K PiA+Pj4NCj4gPj4+IFllcywgdGhlIGRpc2N1c3Npb24gb2YgaG93IHRoaXMgZnVuY3Rpb25zIHdp dGhpbiBIVFRQIGlzIHN1ZmZpY2llbnQuDQo+ID4+Pg0KPiA+Pj4gTWFqb3IgaXNzdWVzIFszXSBh bmQgWzRdIGZhbGwgaW50byB0aGlzIGNhdGVnb3J5LCBidXQgaW4gYm90aCBjYXNlcywNCj4gPj4+ IEkgdGhpbmsgdGhleSdyZSBwcm9iYWJseSB0ZXh0IG92ZXJzaWdodHMgdGhhdCBhcmUgZWFzeSB0 byBmaXguDQo+ID4+Pg0KPiA+Pj4gQS4yLjcgSXMgc2VjdXJpdHkgbWFuYWdlbWVudCBkaXNjdXNz ZWQ/DQo+ID4+Pg0KPiA+Pj4gTm90IHJlYWxseSwgYnV0IHRoaXMgaXMgYW4gRXhwZXJpbWVudGFs IFJGQy4gIEkgd291bGQgZXhwZWN0IHRoYXQgdGhlDQo+ID4+PiBleHBlcmltZW50YWwgdXNlIG9m IEhPQkEgd2lsbCB5aWVsZCBpbnNpZ2h0IGludG8gc2VydmVyIGtleSBkYXRhYmFzZQ0KPiA+Pj4g c3RydWN0dXJlL21hbmFnZW1lbnQsIGtleSBsaWZlY3ljbGUgbWFuYWdlbWVudCAoZS5nLiwgcmV2 b2NhdGlvbiksDQo+ID4+PiBhY2NvdW50IG1hbmFnZW1lbnQgdGVjaG5pcXVlcy9wcm9jZXNzZXMs IGV0Yy4NCj4gPj4+DQo+ID4+PiBBLjMuICBEb2N1bWVudGF0aW9uDQo+ID4+Pg0KPiA+Pj4gSSBk byBub3QgZXhwZWN0IHNpZ25pZmljYW50IG9wZXJhdGlvbmFsIGltcGFjdC4NCj4gPj4+DQo+ID4+ PiBTZWN0aW9uIDEwIG5vdGVzIHRoZSBleGlzdGVuY2Ugb2YgdHdvIGltcGxlbWVudGF0aW9ucyBv ZiBIT0JBLUpTIGFuZA0KPiA+Pj4gb25lIGltcGxlbWVudGF0aW9uIG9mIEhPQkEtaHR0cC4gIFRo YXQncyBhIGdvb2Qgc3RhcnQgZm9yIGFuIGV4cGVyaW1lbnQuDQo+ID4+DQo+ID4+IEFuZCBub3cg dGhlcmUncyBhIDNyZCENCj4gPj4NCj4gPj4gVGhhbmtzIGFnYWluIGZvciB0aGUgZmluZSByZXZp ZXcsDQo+ID4+IFMuDQo+ID4+DQo+ID4+DQo+ID4+Pg0KPiA+Pj4gVGhhbmtzLA0KPiA+Pj4gLS1E YXZpZA0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+Pj4gRGF2aWQgTC4gQmxhY2ssIERpc3Rpbmd1aXNoZWQgRW5naW5lZXINCj4g Pj4+IEVNQyBDb3Jwb3JhdGlvbiwgMTc2IFNvdXRoIFN0LiwgSG9wa2ludG9uLCBNQSAgMDE3NDgN Cj4gPj4+ICsxICg1MDgpIDI5My03OTUzICAgICAgICAgICAgIEZBWDogKzEgKDUwOCkgMjkzLTc3 ODYNCj4gPj4+IGRhdmlkLmJsYWNrQGVtYy5jb20gICAgICAgIE1vYmlsZTogKzEgKDk3OCkgMzk0 LTc3NTQNCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCg== From nobody Fri Dec 26 19:16:14 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD781A1B43; Fri, 26 Dec 2014 19:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuqB4lc0j1pq; Fri, 26 Dec 2014 19:16:10 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACF91A1B21; Fri, 26 Dec 2014 19:16:09 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBR3G5KK009684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Dec 2014 22:16:05 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com sBR3G5KK009684 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1419650166; bh=8lKZs4pzLTAEBmH5vBVEgwsFQd0=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=OlcpX7G6EkYh4HRUgOqfQ0Jc/X+xlnshothzGiW2GMjq3LByibE/IbH6o8ylNgtAH 4MeyKkM5XAhHbYeA6jSubVYbZJXAYgCDkLuh66KO0rZ41UEF6K63CLMaqWYRXjx4IX bgVpd8+MX/HTZVlTMnInmwPc2iJqWj8Z1sFvqyzw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com sBR3G5KK009684 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd54.lss.emc.com (RSA Interceptor); Fri, 26 Dec 2014 22:14:49 -0500 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBR3Fu7e012210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Dec 2014 22:15:56 -0500 Received: from MXHUB204.corp.emc.com (10.253.68.30) by mxhub24.corp.emc.com (128.222.70.136) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 26 Dec 2014 22:15:55 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB204.corp.emc.com ([10.253.68.30]) with mapi id 14.03.0195.001; Fri, 26 Dec 2014 22:15:55 -0500 From: "Black, David" To: "stephen.farrell@cs.tcd.ie" , "paul.hoffman@vpnc.org" , "mike@phresheez.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-08 Thread-Index: AdAhg2z9pL2pKktfRKq2qd7TNjhE1g== Date: Sat, 27 Dec 2014 03:15:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.251.42.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/DYPEblidwWqNSOW6Q81B8FYf6qM Cc: "Black, David" , "http-auth@ietf.org" , "ietf@ietf.org" Subject: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-08 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 03:16:14 -0000 The -08 draft addresses all of the important issues in the combined Gen-ART and OPS-Dir review of the -07 version, and is a definite improvement over its -07 version. Based on discussion of item [5], there are a couple of remaining editorial nits in Section 5.3: During the authentication phase, if the server cannot determine the correct CPK, it could use HTML and JavaScript to ask the user if they are really a new user or want to associate this new CPK with another CPK. The server can then use some out-of-band method (such as a "can" -> "should" confirmation email round trip, SMS, or an UA that is already enrolled) to verify that the "new" user is the same as the already- enrolled one. Thus, logging in on a new user agent is identical to logging in with an existing account. If the server does not recognize the CPK the server might send the client through a either a join or login-new-UA (see below) process. "might" -> "should" I agree w/the draft editor that these are matters of editorial taste. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, December 15, 2014 6:25 PM > To: stephen.farrell@cs.tcd.ie; paul.hoffman@vpnc.org; mike@phresheez.com; > General Area Review Team (gen-art@ietf.org); ops-dir@ietf.org > Cc: ietf@ietf.org; http-auth@ietf.org; Black, David > Subject: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 >=20 > This is a combined Gen-ART and OPS-Dir review. Boilerplate for both foll= ows > ... >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at: >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > I have reviewed this document as part of the Operational directorate's on= going > effort to review all IETF documents being processed by the IESG. These > comments > were written primarily for the benefit of the operational area directors. > Document editors and WG chairs should treat these comments just like any = other > last call comments. >=20 > Document: draft-ietf-httpauth-hoba-07 > Reviewer: David Black > Review Date: Dec 15, 2014 > IETF LC End Date: Dec 24, 2014 >=20 > Summary: This draft is on the right track, but has open issues > described in the review. >=20 > This draft specifies a signature-based authentication mechanism for HTTP > that is based on asymmetric (public-private) key pairs without using > certificates. A different key pair is used by each user for each for > each host ("web-origin", see [RFC6454]), and each signature is based > on a server-generated challenge. >=20 > The draft is generally well-written and clear on the authentication > mechanics, but has weaknesses in specifying the environment that > surrounds use of this mechanism. Some of these issues are basic things > that anyone working on web technology or applied crypto "just knows", > but even the obvious needs to be stated when it's integral to security. >=20 > -- Major issues: -- >=20 > [1] Challenge size and predictability >=20 > In the ABNF: >=20 > challenge =3D 1*base64urlchars >=20 > I did not see any other discussion of minimum length of challenge > or amount of entropy in the challenge. For the latter, do the challenges > need to be unpredictable? I would think so. >=20 > I think a requirement on minimum challenge size and a recommendation on > minimum amount of entropy would be good ideas. >=20 > [2] Challenge verification and reuse >=20 > This sentence on p.6 strikes me as subtly dangerous: >=20 > The challenge however is sent over > the network so as to make it simpler for a server to be stateless. > (One form of stateless challenge might be a ciphertext that the > server decrypts and checks, but that is an implementation detail.) >=20 > The draft elsewhere asserts or assumes that challenge reuse can be > prevented by the server or be time-bounded by max-age, and relies on > those reuse limits for security properties, e.g., as in this sentence > near the end of Section 6.1: >=20 > Note that replay of registration (and other HOBA) messages is quite > possible. That however can be counteracted if challenge freshness is > ensured. >=20 > The sentence quoted from p.6 appears to allow (or even encourage) > stateless servers to implement rather weak checks on not only challenge > reuse, but also challenge validity (e.g., what if the challenge validity > test were "challenge mod 1024 =3D=3D 7" ?). >=20 > Allowing such weak checks could enable an attacker to choose or influence > the choice of challenge values, which could be useful (e.g., for > differential cryptanalysis attack on the hash function), as the > attacker (client) already controls the nonce. >=20 > As part of this, the server needs to check whether a challenge presented > on one connection or session has been reused on another. I think the > following sentence in section 3 is intended to prevent this, but it's > weakened by the "stateless" language above: >=20 > The challenge MUST be > unique for every HTTP 401 response in order to prevent replay > attacks from passive observers. >=20 > Explicit server checks for challenge reuse ought to be REQUIRED, and > the above use of "stateless" needs to be qualified. >=20 > [3] Web origin checks >=20 > I did not see text mandating that TLS (server certificate), HTTP (accesse= d > URL) and HOBA (signature input) use the same web origin, and stating that > the server has to check/enforce this. Did I miss something? >=20 > I realize that this is an obvious requirement, but it does need to be > stated. >=20 > [4] TLS requirement level >=20 > TLS is only a "SHOULD" requirement for HOBA, not a "MUST" requirement - > first paragraph in Section 8.1 (Privacy Considerations). >=20 > If TLS is not a "MUST" requirement, at least a discussion of man-in-the- > middle (MITM) attacks seems to be in order. There's no need for an exten= sive > discussion of all of the security properties of TLS, but MITM attacks are > definitely worth a mention, and that could be complemented by a pointer t= o > suitable HTTP/TLS security considerations text elsewhere. >=20 > [5] Section 5.3 - unrecognized key >=20 > Paragraphs 4 and 5 in this section don't seem to belong here, and appear = to > be written in a somewhat loose fashion, particularly around user verifica= tion. > A server that does what is suggested here could have significant security > weaknesses. >=20 > I strongly recommend replacing those two paragraphs with a short sentence= that > says: > - if a kid is unrecognized or the server otherwise determines > that the CPK is not to be used for this HTTP authentication, > - then the Registration (see 6.1) and/or Associating Additional Keys to > an Exiting Account (see 6.2) processes MAY be used instead of > treating this situation as an authentication failure. >=20 > and moving all discussion of user verification into Sections 6.1 and 6.2. >=20 > -- Minor issues: -- >=20 > [A] ABNF encoding of alg >=20 > In section 2, I see: >=20 > alg =3D 1*2DIGIT >=20 > o alg: specifies the signature algorithm being used encoded as an > ASCII character as defined in Section 9.3. >=20 > Section 9.3 specifies a single digit. How does that become 1*2DIGIT ? > I suggest: "as an ASCII character" -> "as one or two ASCII digits based > on the IANA registry established by Section 9.3" >=20 > This may seem like a nit, but any imprecision in signature algorithm > input can lead to interoperability problems. >=20 > [B] Section 5.3 - CPK vs. kid >=20 > In the authentication phase, the server extracts the CPK from the > signing phase and decides if it recognizes the CPK. If the server > recognizes the CPK, the server may finish the client authentication > process. >=20 > That seems wrong. IIUC, the HOBA client sends: >=20 > HOBA-RES =3D kid "." challenge "." nonce "." sig >=20 > If so, I don't understand how the server extracts a CPK from that. >=20 > I suspect that what was intended is that the server extracts a key identi= fier > (kid) and then determines a) whether it knows a CPK for that kid and b) > whether > it allows use of that kid/CPK for this authentication. At least a) seems= to > be indicated by this text in Section 3: >=20 > The server MUST check the cryptographic correctness of the signature > based on a public key it knows for the kid in the signatures, >=20 > [C] RSA signature algorithm >=20 > Section 7 says: >=20 > RSA is defined in > Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. >=20 > Section 8.2 of RFC 3447 specifies RSASSA-PKCS1-v1_5. At a minimum, that > algorithm name should be stated here (which is a nit). The minor issue i= s > whether that is the signature algorithm that's wanted, on which I'll defe= r > to the crypto experts on that (e.g., I seem to recall a negative saag > comment on PKCS 1.5 mechanisms in the past couple of months). >=20 > [D] Javascript local storage. >=20 > The first paragraph of Section 8.2 on this topic concludes with: >=20 > It's not clear that we > introduce unique threats from which clear text passwords don't > already suffer. >=20 > That's at odds with the use of "all" in this sentence in the abstract: >=20 > HOBA is an > alternative to HTTP authentication schemes that require passwords and > therefore avoids all problems related to passwords, such as leakage > of server-side password databases. >=20 > One of those two paragraphs needs some editing. >=20 > -- Nits/editorial comments: -- >=20 > This is buried near the end of section 6.1 >=20 > Note that replay of registration (and other HOBA) messages is quite > possible. That however can be counteracted if challenge freshness is > ensured. >=20 > That's not a good place for these two sentences. HOBA registration > messages don't contain a challenge, and the general discussion of > replay attacks belongs under Security Considerations, not Registration. >=20 > In Section 9.4 and 9.5, I see the following proposed as part of IANA > registry contents: >=20 > an unformatted string, at the user's/UA's whim >=20 > I get the point, but it's still not appropriate for an IANA registry > - remove ", at the user's/UA's whim". >=20 > Appendix A appears to assume that human-memorable passwords are stored i= n > the clear in server databases. It should also briefly discuss the use > of one-way functions, especially computationally intensive ones, to > generate stored password verifiers. HOBA is still superior by comparison= , > as the one-way functions only increase the difficulty of dictionary > attack, whereas dictionary attack on HOBA keys is pointless when > sufficiently large keys are used. >=20 > idnits 2.13.01 found the references to W3C's web site (www.w3.org) in > Section 4, e.g., >=20 > 389 One element is required for HOBA-js: localStorage (see http:// > 390 www.w3.org/TR/webstorage/) from HTML5 can be used for persistent k= ey > 391 storage. >=20 > I think idnits can be ignored, even though the "right way" to fix this is= to > move each URL to a reference and cite the reference in Section 4. >=20 > OTOH, idnits did not complain about the normative reference to RFC 20 ;-)= . >=20 > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- >=20 > Most of these questions are n/a because this draft describes an extension > to HTTP authentication, and RFC 5706's concerns would apply primarily to > HTTP and HTTP authentication. >=20 > A.1.1 Has deployment been discussed? >=20 > Yes, section 6 discusses how a user would deploy this for her access to w= eb > servers. >=20 > A.1.4. Have the Requirements on other protocols and functional > components been discussed? >=20 > Yes, the discussion of how this functions within HTTP is sufficient. >=20 > Major issues [3] and [4] fall into this category, but in both cases, > I think they're probably text oversights that are easy to fix. >=20 > A.2.7 Is security management discussed? >=20 > Not really, but this is an Experimental RFC. I would expect that the > experimental use of HOBA will yield insight into server key database > structure/management, key lifecycle management (e.g., revocation), > account management techniques/processes, etc. >=20 > A.3. Documentation >=20 > I do not expect significant operational impact. >=20 > Section 10 notes the existence of two implementations of HOBA-JS and > one implementation of HOBA-http. That's a good start for an experiment. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From nobody Fri Dec 26 19:16:34 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB41E1A1B65; Fri, 26 Dec 2014 19:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYCcEvwAYMvY; Fri, 26 Dec 2014 19:16:23 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D198D1A1B43; Fri, 26 Dec 2014 19:16:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ABAF4BF09; Sat, 27 Dec 2014 03:16:19 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcwHOs10HSYd; Sat, 27 Dec 2014 03:16:18 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.41.53.28]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 98A18BE83; Sat, 27 Dec 2014 03:16:18 +0000 (GMT) Message-ID: <549E2481.5070709@cs.tcd.ie> Date: Sat, 27 Dec 2014 03:16:17 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Black, David" , "paul.hoffman@vpnc.org" , "mike@phresheez.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" References: <549AA03C.5070107@cs.tcd.ie> <549DF1E1.3080308@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/SRXhrCSlIg9f-aKOHLa9xwxro6Q Cc: "http-auth@ietf.org" , "ietf@ietf.org" Subject: Re: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 03:16:27 -0000 On 27/12/14 02:44, Black, David wrote: > in addition to > what's noted below, -08 also addresses [B] Oops - yes I did make changes (which are real improvements) there but didn't note those in my mail. Sorry for the omission - it was simply due to window-bloat but your comment in that case was good. Cheers, S. From nobody Sat Dec 27 02:11:59 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0273D1AD4BC; Sat, 27 Dec 2014 02:11:53 -0800 (PST) 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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvpbTfvfy_QS; Sat, 27 Dec 2014 02:11:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59ABD1AD4BF; Sat, 27 Dec 2014 02:11:51 -0800 (PST) Received: from [192.168.2.160] ([84.187.59.9]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M55BC-1XeutX3Wxi-00zCqf; Sat, 27 Dec 2014 11:11:42 +0100 Message-ID: <549E85D7.8000603@gmx.de> Date: Sat, 27 Dec 2014 11:11:35 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Black, David" , "stephen.farrell@cs.tcd.ie" , "paul.hoffman@vpnc.org" , "mike@phresheez.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:wekNU87e4VEp7no5VvhRUj1S4UlHraiLSnxjTNF/DD7uLN+3kOX 47UHqoPGp/y8yj1J5hWz/iDf4JPOUil8lfGhu13fHVNb1J815qkAznwHqJ9XYNij5/8AsB5 Dby98X4dN4wgl27q5ZNU6DD1GLWLUrcwc2PTa09DyvOhWgTeHJvszUewCKzTJe3W7qRoEkP whpkHD7/BmWBpQ5gVon+w== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/eZulcsqGffSAuQOXIjRLMgB_Ibs Cc: "http-auth@ietf.org" , "ietf@ietf.org" Subject: Re: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-08 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 10:11:53 -0000 On 2014-12-27 04:15, Black, David wrote: > The -08 draft addresses all of the important issues in the combined Gen-ART > and OPS-Dir review of the -07 version, and is a definite improvement over > its -07 version. > > Based on discussion of item [5], there are a couple of remaining editorial > nits in Section 5.3: > > During the authentication phase, if the server cannot determine the > correct CPK, it could use HTML and JavaScript to ask the user if they > are really a new user or want to associate this new CPK with another > CPK. The server can then use some out-of-band method (such as a > > "can" -> "should" > > confirmation email round trip, SMS, or an UA that is already > enrolled) to verify that the "new" user is the same as the already- > enrolled one. Thus, logging in on a new user agent is identical to > logging in with an existing account. > > If the server does not recognize the CPK the server might send the > client through a either a join or login-new-UA (see below) process. > > "might" -> "should" > > I agree w/the draft editor that these are matters of editorial taste. > > Thanks, > --David For the record: I strongly disagree with the proposal to insert lower-cased BCP 14 keywords. Best regards, Julian From nobody Sat Dec 27 08:38:08 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBDA1A8961 for ; Sat, 27 Dec 2014 08:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.274 X-Spam-Level: X-Spam-Status: No, score=0.274 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoN1pdWLP-ni for ; Sat, 27 Dec 2014 08:38:04 -0800 (PST) Received: from mx02.posteo.de (mx02.posteo.de [89.146.194.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B850C1A895D for ; Sat, 27 Dec 2014 08:38:03 -0800 (PST) Received: from dovecot03.posteo.de (unknown [185.67.36.28]) by mx02.posteo.de (Postfix) with ESMTPS id 844E925AF53F; Sat, 27 Dec 2014 17:38:00 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3k8rKx0f5Xz5vMr; Sat, 27 Dec 2014 17:37:56 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Sophie Bremer In-Reply-To: Date: Sat, 27 Dec 2014 17:37:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141210012503.8350.57672.idtracker@ietfa.amsl.com> <548DBA0B.6080201@greenbytes.de> <5495B04B.1000903@gmx.de> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/_mv9R1TxRb0J_JjR1wEI4ZS7hLQ Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 16:38:06 -0000 Hello, > 3.7 Security Protocol Negotiation >=20 > It is useful for a server to be able to know which security > schemes a > client is capable of handling. >=20 > It is possible that a server MAY want to require Digest as its >=20 > s/MAY want/wants/ >=20 > authentication method, even if the server does not know that = the > client supports it. A client is encouraged to fail gracefully = if the > server specifies only authentication schemes it cannot handle. >=20 > When a server receives a request to access a resource, the = server > might challenge the client by responding with "401 = Unauthorized" > status code, and include one or more WWW-Authenticate header = fields. >=20 > s/status code/response/ >=20 > If the server challenges with multiple Digest header fields, = then > each one of these header fields MUST use a different digest >=20 > You could have multiple challenges in a single header field = instance. >=20 > Can you please elaborate? >=20 > The syntax allows it, so you should talk more generally about multiple = challenges in a response, independently in how many header fields they = appear. >=20 > I see. I will adjust the text. Must example 3.9.1 reflect this with a single WWW-Authenticate? Does anyone knows if web browsers actually support this case? =20 > algorithm. The server MUST add these Digest header fields to = the > response in order of preference, starting with the most = preferred > header field, followed by the less preferred header fields. >=20 > most preferred algorithm? >=20 > When the client receives the response it SHOULD use the = topmost > header field that it supports, unless a local policy dictates >=20 > First challenge. >=20 > otherwise. The client SHOULD ignore any challenge it does not > understand. >=20 > MUST, I believe. >=20 > Yes >=20 > Also, this sounds like requirements that are generic to WWW-A, not > specific to Digest, no? >=20 > Yes. it is. Is it specified somewhere else? >=20 > I would think it's said in 7235. >=20 > I could not find such a text in 7235. >=20 >=20 > =20 >=20 > ... > For the username, recipients MUST support all characters = defined in > the "UsernameCasePreserved" profile defined in in Section 3.3 = of > [PRECIS], with the exception of the colon (":") character. >=20 > This is copied from Basic. >=20 > Yes, I mentioned that I will use the same text you provided with = Digest. >=20 > Is it true for Digest as well? >=20 > I thought that was the conclusion based on the following: > http://www.ietf.org/mail-archive/web/http-auth/current/msg02005.html >=20 > Yup, sorry for being unclear. My question was about the colon = character. Is it disallowed in Digest? >=20 > I think so ,because the colon character is used to concatenate the = username, realm, and password when calculating A1. I don not see a problem with the colon character in calculations. Only in URIs it may be some kind of a problem if not %-escaped, because = the colon character is already in use for separation of username and = password: https://Mufasa:Circle%20of%20Life@example.org/dir/index.html Regards, Sophie From nobody Sat Dec 27 08:52:43 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFA41A8970; Sat, 27 Dec 2014 08:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChqFyKxhjudB; Sat, 27 Dec 2014 08:52:29 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9170E1A896B; Sat, 27 Dec 2014 08:52:29 -0800 (PST) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBRGqFQE016639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Dec 2014 11:52:15 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sBRGqFQE016639 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1419699135; bh=b191V3bSFUuJd/qt5PFh+isvhSg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Y4yAVSxfJOZk1HtjF4L4808Z4aH44o9RYOn7hVJskHSa7Ijd7f1CJfmz8WweI7jcJ KZiZTD1MjdDyUuWy1m9ivSawka/+k1el28iDijXhqP96UcFfF6JpvKHnw9o0zDLc3J ENYdSK21mxq0Ne5WIJLRzLezUpBRMAOvV+Bk2dJw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sBRGqFQE016639 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd03.lss.emc.com (RSA Interceptor); Sat, 27 Dec 2014 11:51:48 -0500 Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com [128.222.70.107]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBRGpxpe019607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Dec 2014 11:51:59 -0500 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub40.corp.emc.com (128.222.70.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sat, 27 Dec 2014 11:51:58 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Sat, 27 Dec 2014 11:51:59 -0500 From: "Black, David" To: Julian Reschke , "stephen.farrell@cs.tcd.ie" , "paul.hoffman@vpnc.org" , "mike@phresheez.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Thread-Topic: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-08 Thread-Index: AdAhg2z9pL2pKktfRKq2qd7TNjhE1gAY/puAAAN09PA= Date: Sat, 27 Dec 2014 16:51:57 +0000 Message-ID: References: <549E85D7.8000603@gmx.de> In-Reply-To: <549E85D7.8000603@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.251.33.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/fkgR0BUYB8HWD5LYCzir9ehtaeM Cc: "Black, David" , "http-auth@ietf.org" , "ietf@ietf.org" Subject: Re: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-08 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 16:52:32 -0000 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Saturday, December 27, 2014 5:12 AM > To: Black, David; stephen.farrell@cs.tcd.ie; paul.hoffman@vpnc.org; > mike@phresheez.com; General Area Review Team (gen-art@ietf.org); ops- > dir@ietf.org > Cc: http-auth@ietf.org; ietf@ietf.org > Subject: Re: [http-auth] Gen-ART and OPS-Dir review of draft-ietf-httpaut= h- > hoba-08 >=20 > On 2014-12-27 04:15, Black, David wrote: > > The -08 draft addresses all of the important issues in the combined Gen= -ART > > and OPS-Dir review of the -07 version, and is a definite improvement ov= er > > its -07 version. > > > > Based on discussion of item [5], there are a couple of remaining editor= ial > > nits in Section 5.3: > > > > During the authentication phase, if the server cannot determine the > > correct CPK, it could use HTML and JavaScript to ask the user if th= ey > > are really a new user or want to associate this new CPK with anothe= r > > CPK. The server can then use some out-of-band method (such as a > > > > "can" -> "should" > > > > confirmation email round trip, SMS, or an UA that is already > > enrolled) to verify that the "new" user is the same as the already- > > enrolled one. Thus, logging in on a new user agent is identical to > > logging in with an existing account. > > > > If the server does not recognize the CPK the server might send the > > client through a either a join or login-new-UA (see below) process. > > > > "might" -> "should" > > > > I agree w/the draft editor that these are matters of editorial taste. > > > > Thanks, > > --David >=20 > For the record: I strongly disagree with the proposal to insert > lower-cased BCP 14 keywords. >=20 >=20 > Best regards, Julian If the keyword itself is a concern, "ought to" is an alternative that has been used in the past. Thanks, --David From nobody Tue Dec 30 14:28:22 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AEB1A8852; Tue, 30 Dec 2014 14:28:19 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x79b6lyS3lY4; Tue, 30 Dec 2014 14:28:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A581A8849; Tue, 30 Dec 2014 14:28:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141230222818.28212.98776.idtracker@ietfa.amsl.com> Date: Tue, 30 Dec 2014 14:28:18 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/oDGI3Wa3GFETa8a4gIfhyOfekPs Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-hoba-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 22:28:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : HTTP Origin-Bound Authentication (HOBA) Authors : Stephen Farrell Paul Hoffman Michael Thomas Filename : draft-ietf-httpauth-hoba-09.txt Pages : 26 Date : 2014-12-30 Abstract: HTTP Origin-Bound Authentication (HOBA) is a digital signature based design for an HTTP authentication method. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-hoba-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 30 14:28:25 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3923A1A8852 for ; Tue, 30 Dec 2014 14:28:20 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKmMr8jToanq; Tue, 30 Dec 2014 14:28:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA671A884E; Tue, 30 Dec 2014 14:28:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" , Kathleen.Moriarty.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141230222818.28212.45752.idtracker@ietfa.amsl.com> Date: Tue, 30 Dec 2014 14:28:18 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/hqPxCkJJQc__yLLm1dwTUVDqP4E Subject: [http-auth] New Version Notification - draft-ietf-httpauth-hoba-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 22:28:20 -0000 A new version (-09) has been submitted for draft-ietf-httpauth-hoba: http://www.ietf.org/internet-drafts/draft-ietf-httpauth-hoba-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Dec 31 11:06:24 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BC41ACCEA for ; Wed, 31 Dec 2014 11:06:20 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZCP7tg7cDSk; Wed, 31 Dec 2014 11:06:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE93D1ACCE4; Wed, 31 Dec 2014 11:06:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231190619.10969.73807.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 11:06:19 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Bovd1VjbtoqfpPCGHe2Atd-PQQg Subject: [http-auth] ID Tracker State Update Notice: X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 19:06:21 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/