From ynir@checkpoint.com Tue Nov 5 00:14:11 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2621E8087 for ; Tue, 5 Nov 2013 00:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.921 X-Spam-Level: X-Spam-Status: No, score=-9.921 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcSUQXBUOCgX for ; Tue, 5 Nov 2013 00:14:04 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3036621E809C for ; Tue, 5 Nov 2013 00:14:03 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA58A1I7007006 for ; Tue, 5 Nov 2013 10:14:02 +0200 X-CheckPoint: {5278A67A-2-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 10:13:52 +0200 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: First review of the Rest-Auth draft Thread-Index: AQHO2f72X3rY8XRT1kSBqcr+zTyMwg== Date: Tue, 5 Nov 2013 08:13:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.53] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <280FD21046CE4A439354FC60E5BB14E5@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] First review of the Rest-Auth draft X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 08:14:11 -0000 Hi I have reviewed draft-ietf-httpauth-rest-auth-01. This is done with no hats= - it is not a SecDir review, nor a chair or shepherd review. My comments h= ave no more or less weight than those of any other participant. The proposal moves the authentication outside of the HTTP layer, and into t= he application layer. The benefits of this are: 1. Works through unmodified routers and proxies (including TLS proxies) 2. Creates a resource that represents the session, and can be deleted for = a logout. 3. Can re-use many existing mechanisms. 4. RESTful, so it supports clustering. 5. Easily implemented in application interfaces such as CGI, FastCGI, and = others. =20 It should be noted that all this information is in the Abstract, and most o= f it should probably be moved to the Introduction (section 1). Section 1.1 has a longish review of the state of authentication on the web.= We could probably do without it, but as long as it's confined to that one = section, we can leave it at that, but discussion of alternative methods als= o fills up section 2. Section 1.2 outlines the protocol, and section 1.3 discusses API constraint= s. The interesting stuff (the protocol) begins in section 3, about a third = of the way through the document. I find section 3 clear, although I would have rather had the examples close= by rather than all the way down in section 7. Nit: section 3.1 refers to t= he ABNF in the previous section, but the ABNF has moved to section 3.1.2. I would have liked to see examples for and within each sub-section of secti= on 3, because those help me make sense of things better than ABNF. Section 6 describes how the server side of Rest-Auth can be done with a sin= gle server, multiple server or an HTTP "router". For the multi-server case,= it is assumed that they will have some shared media on which to store the = resource representing the session. This is indicated by the three words (ma= ny servers) "sharing server state". I think that this requirement should be= stated more explicitly. For a static site, a cluster could consist of seve= ral replicated servers. Not so for a site implementing Rest-Auth. Section 7 finally has the example to make this all fall into place. However= , looking at figure 3, there is one thing that's still missing: How does th= e client get the resource. See the first transaction in figure 3 looks like= this: C->S: GET /some-resources HTTP/1.1 Host: A.example =20 S->C: HTTP/1.1 401 Unauthorized WWW-Authenticate: RA-SA-SCRAM-SHA-1 \ http://A.example/rest-sa-scram \=20 s=3Dsession-ID,MIC r=3Dno WWW-ChannelBinding-Types: tls-server-end-point =20 And the last one looks like this: S->C: HTTP/1.1 200 Content-Type: application/octet-stream Content-Length: nnn =20 v=3DrmF9pqV8S7suAoZWja4dJRkFsKQ=3D Content-Type: application/octet-stream =20 So the authentication process created some SCRAM-specific parameter "v", an= d a resource called "/restauth-9d0af5f680d4ff46". When the client tries aga= in to fetch "/some-resources", what data should be passed in the Authorizat= ion header? Section 8 looks good. Yoav From ilari.liusvaara@elisanet.fi Wed Nov 6 08:27:16 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A3521E8157 for ; Wed, 6 Nov 2013 08:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Wocsad8Z1vr for ; Wed, 6 Nov 2013 08:27:10 -0800 (PST) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) by ietfa.amsl.com (Postfix) with ESMTP id 257D521E814A for ; Wed, 6 Nov 2013 08:27:07 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 734739013B for ; Wed, 6 Nov 2013 18:27:06 +0200 (EET) Date: Wed, 6 Nov 2013 18:27:06 +0200 From: Ilari Liusvaara To: http-auth@ietf.org Message-ID: <20131106162706.GA8185@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Subject: [http-auth] Quick review of draft-ietf-httpauth-hoba-02 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 16:27:16 -0000 > Abstract > > HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP > authentication method with credentials that are not vulnerable to > phishing attacks, and that does not require any server-side password > database. The design can also be used in Javascript-based > authentication embedded in HTML. HOBA is an alternative to HTTP > authentication schemes that require passwords. Well, technically whatever the database is resembles some forms of password database, albeit with the "passwords" being of much much higher entropy. But that's nitpicking. > Session management with HOBA is identical to username/password > session management. Typically, the session management tool (such as > PHP, Python CGI, and so on) inserts a session cookie into the output > to the browser. HOBA does nothing to help or hurt session cookie > hijacking; TLS is still required for that. If the authentication is not bound to sessions, even TLS can't really help against all attacks that arise. > HOBA also defines some services that are required for modern HTTP > authentication: > > o Since there are always devices and applications in which state of > the art digital signature mechanism runtimes are significant, and > since HTTP authentication in theory requires that every HTTP > request to a given realm have a signature in an "Authorization" > header field, and since HOBA is a challenge response scheme, we > also define a way in which HTTP servers can indicate the duration > for which they will consider a given challenge value to be valid. > As a consequence we also define a way for UAs to fetch a fresh > challenge. Hah, I was under impression that state-of-the-art is faster, not slower. Of course, there is keylength increases. Discrete to ECC, ECC to HECC. Of course, the usual way to lighten the load without sacrificing much security is to have symmetric short-term keys. But yes, there are more and more devices that have very limited processing power. > 2. The HOBA Authentication Scheme > > HOBA-TBS = nonce alg origin [ realm ] kid challenge > nonce = unreserved > alg = 1*2DIGIT > origin = scheme "://" authority ":" port > realm = unreserved > kid = unreserved > challenge = unreserved What's unreserved? I can't quickly find it from httpbis p1, p7 nor from this document. It it includes spaces, there could be multiple ways to take it apart (or multiple things mapping into the same string). Well, given the realm is seemingly the only one that can have spaces, it might not be that bad problem. > 3. Introduction to the HOBA-http Mechanism > > An HTTP server that supports HOBA authentication includes the "HOBA" > auth-scheme value in a WWW-Authenticate header field when it wants > the client to authenticate with HOBA. Note that the HOBA auth-scheme > might not be the only one that the server includes in a WWW- > Authenticate. > > o If the "HOBA" scheme is listed, it MUST be followed by two or more > auth-param values. The auth-param attributes defined by this > specification are below. Other auth-param attributes MAY be used > as well. Unknown auth-param attributes MUST be ignored by > clients, if present. > > o The "challenge" attribute MUST be included. The challenge is the > string made up of the base64url encoded octets that the server > wants the client to sign in its response. The challenge SHOULD be > unique for every HTTP 401 response in order to prevent replay > attacks from passive observers. > > o An "expires" 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. > > o A "realm" attribute MAY be included to indicate the scope of > protection in the manner described in HTTP/1.1, Part 7 > [I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear > more than once. The realm attribute must only appear once? What do other parameters do if present multiple times (nitpicking)? > The server MUST check the cryptographic correctness of the signature > based on a public key it knows for the kid in the signatures, and if > the server cannot do that, or if the signature fails cryptographic > checks, then validation has failed. The server can use any > 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 403 Forbidden > HTTP response. Er, I thought authentication failures trigger 401, authorization failures trigger 403 (except if request isn't authenticated). > Note that a HOBA signature is good for however long the expires > attribute allows. This means that replay is possible within the time > window specified by the "expires" value chosen by the server. > Servers can attempt to detect any such replay and MAY react to such > replays by responding with a second (or subsequent) 401-status HTTP > response containing a new challenge. How could such detection be done in face of cut-and-paste attacks? With TLS, one could include something like TLS-Unique (or what it was). That would defeat most cut'n'paste. > 6.1. Registration > > The registration message sent to server has one mandatory field (pub) > and some optional fields that allow the UA to specify the type and > value of key and device identifiers that the UA wishes to use. Again, what if these are duplicated? :-> > o kidtype: contains the type of key identifier, this is a numeric > value intended to contain one of the values from Section 9.4. If > this is not present then the mandatory to implement "DANE-hash" > option MUST be used. What's "DANE-hash"? > o curtime: the number of milliseconds since the Unix epoch, > formatted as [[ not yet specified ]]. This is based on the > expectation that the synchronization between the browser's and > server's clocks is sufficiently reliable. This is used to guard > against the replay of a legitimate registration message. The > server needs to have a replay cache covering a signature timeout > window. This might be done using a database table that is keyed > (in the database sense of the term) using the signature bits. If > the signature is in the replay table, the server will reject it. > If the timestamp in the signature is outside the current replay > cache window then it also gets rejected. Decimal unix timestamp with three decimal digits? > [[ A comment raised on the list was: how does the UA know that the > registration process has completed successfully or badly? That's not > yet handled. ]] You mean if the request was processed as-is, or more data will be required? (For immediate request, there's HTTP status codes, so I presume it is that "was this final success?" problem). > 6.2. Associating Additional Keys to an Exiting Account > > 6.2.1. Moving private keys > > It is common for a user to have multiple UAs, and to want all those > UAs to be able to authenticate to a single account. One method to > allow a user who has an existing account to be able to authenticate > on a second device is to securely transport the private and public > keys and the origin information from the first device to the second. > If this approach is taken, then there is no impact on the HOBA-http > or HOBA-js so this is a pure UA implementation issue and not > discussed further. There could also be copying private keys between origins/realms. In certain cases, the server could even recognize such keys. > 6.2.2. One time password > > The one-time password should be easy for a user to type into the new > UA, but at the same time needs to have enough randomness to prevent > an attacker from succeeding if they try to use the password during > its short lifetime. After the server gets the password in the new > UA, it verifies the signature and verifies that the password supplied > is in a list of unexpired one-time passwords. If so, the server > knows that the authenticated user is associated with the second CPK. > The server can choose to associate the two CPKs with one account. > Whether to do so is entirely at the server's discretion however, but > the server needs make the outcome clear to the user. Something like S/Key passwords (might not be the best in mobile enviroment)= > Alternatively, if an already-enrolled UA is not available to the user > when they want to associate a new UA with an existing account, and > the site has an out-of-band communication mechanism such as email or > SMS associated with that account, the user can request that a one- > time password be sent to the user out of band. The user receives the > one-time password and, using the new UA, tells it to the server. On > HOBA-http, this is done with the URL ".well-known/hoba/associate- > from-oob" using a POST message [[ more detail is clearly needed here > ]]. What's the difference to the first case from server POV (the URL being different)? > 6.3. Logging Out > > The user can tell the server it wishes to log out. With HOBA-http, > this is done by going to the URL ".well-known/hoba/logout". The UA > SHOULD also delete or modify session cookies associated with the > session so that the user's state is no longer "logged in." Modify? I don't think cookies are modifiable, so that just leaves deleting those. > The server MUST NOT allow TLS session resumption for any logged out > session. [[ Need to determine if this is needed or even a good idea. > ]] Eeh? Specify that server MUST destroy TLS session state on HOBA logout? These things run on totally separate layers... > 8. Security Considerations > > [[ The potential impact on privacy of HOBA needs to be addressed. If > a site can use a 401 and a CPK to track users without permission that > would be not-so-nice so some guidance on how a UA could indicate to a > user that HOBA stuff is going on might be needed. ]] Obviously any authentication mechanism allows tracking within account. > 9.3. Algorithm Names > > TBD, hopefully re-use and existing registry > > "0" means RSA-SHA256 > > "1" means RSA-SHA1 Just RSA? Nothing more modern? > 9.4. Key Identifier Types > > "0" means a hashed public key, as done in DANE. [RFC6698] Er, doesn't that constist of two parts, once all implicit fields are left out? > "1" means a URI, such as a mailto: or acct: URI, but anything > conforming to [RFC3986] is ok.i "ok.i"? Should be "ok."? -Ilari From ilari.liusvaara@elisanet.fi Wed Nov 6 08:29:33 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E77321F9CAD for ; Wed, 6 Nov 2013 08:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[AWL=-2.617, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85VD5emvqmGd for ; Wed, 6 Nov 2013 08:29:27 -0800 (PST) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by ietfa.amsl.com (Postfix) with ESMTP id 1957C21E8151 for ; Wed, 6 Nov 2013 08:29:27 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 0BD33400E for ; Wed, 6 Nov 2013 18:29:24 +0200 (EET) Date: Wed, 6 Nov 2013 18:29:24 +0200 From: Ilari Liusvaara To: http-auth@ietf.org Message-ID: <20131106162924.GB8185@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Subject: [http-auth] Quick review of draft-ietf-httpauth-rest-auth-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 16:29:33 -0000 > 1. Introduction > > We propose a pattern for HTTP [RFC2616] [TODO: add reference to > HTTP/2.0 as well?] authentication mechanisms that, by being > "RESTful", obtains these goals naturally. Reference for HTTP/2.0 would be draft-ietf-httpbis-http2 > 1.1. Motivation > > o various bearer token mechanisms [TODO: add examples, such as > OAuth]; OAuth2 [RFC6749]. IIRC, in most common modes, OAuth1 isn't bearer token. > o various non-bearer token mechanisms which are not generalized or > generalizable to a larger universe of authentication mechanisms > [TODO: add examples, such as BrowserID]. It seems that locating reference for BrowserID isn't trivial, as most refereces seem to go to Mozilla Persona (which is based on BrowserID but probably isn't the same thing). > Enterprises and educational settings also often have RADIUS > [RFC2865], often used via EAP [RFC3748]. These could be supported by > the generic security mechanism based on EAP, RADIUS, and SAML being > developed by the ABFAB WG [TODO: add references!]. These mechanisms > in particular will be difficult to use via Negotiate because they > involve multiple round trips, which Negotiate supports half- > heartedly; see Section 2.1. draft-ietf-abfab-gss-eap draft-ietf-abfab-aaa-saml Don't see anything about RADIUS. > 1.3. API-Imposed Constraints > > A typical constraining characteristic might be that an API assumes > the use of GET with tokens encoded into the URI or into a header, or > that the API makes no room for the use of headers in authentication > message exchanges. > > One way to work around such constraints may be to provide various > options in RESTauth. Another might be to use OAuth 1.0 [RFC5849] or > 2.0 [RFC6749] as a bridge: the API would use this framework under the > covers then obtain OAuth credentials from the server that the > application can then use in any way that the API's form allows for. I can't parse this. How does OAuth come in here? > 2.1. In-band HTTP Authentication > Additionally, Negotiate can require multiple round trips but provides > no mechanism for explicitly associating a given GSS-API security > context token with a given GSS-API security context: it has to be > assumed that all messages are serialized and only one multi-round > trip security context establishment can be ongoing in any given HTTP > connection. ... And this causes major problems if there are proxies... > 3. Protocol > > And for applications that may not use TLS/HTTPS: > > o the use of session keys as an option for integrity protection when > TLS is not used (a light-weight security mode); see > [I-D.williams-websec-session-continue-proto]. Non-bearer-token mechanisms tend to do replay protection... > 3.1. Negotiable Parameters > > 3.1.2. WWW-Authenticate Header Value Prefix Syntax > > For a DIGEST-like mechanism it might look like "WWW-Authenticate: RA- > Digest-SHA-256 tls-server-end-point session-ID no HE4SgWGrd/ > 3+O7t16HqusA==". For example, the mechname for the Kerberos V5 GSS- > API mechanism might be "gss-krb5", and a WWW-Authenticate header > value for it might look like "WWW-Authenticate: RA-gss-krb5 > http://foo.example/restauth-login tls-server-end-point channel-bound- > session-ID r=no". These examples don't look to conform to the grammar given (missing r=, s=, etc...) > 3.1.3. WWW-ChannelBinding-Types Header > > A new header is added by which servers MUST indicate which channel > binding [RFC5056] types -if any- they support for RESTauth > authentication; if the server does not support channel binding then > this header MUST be absent. The header is named WWW-ChannelBinding- > Types. Its values are channel binding types from the channel binding > type registry, such as the TLS channel binding types [RFC5929]. I think the wording is bit odd... > 3.1.4. WWW-ChannelBinding-Type Header > > A new header is added by which clients MUST indicate what channel > binding type they used when POSTing RESTauth authentication messages, > if any; if the client did not use channel binding then this header > MUST be absent. If the mechanism used has its own method for > indicating the use of channel binding, then this header MAY be > ommitted. The header is named WWW-ChannelBinding-Type. Its value is > a channel binding type from the channel binding type registry > [RFC5929]. Same.... > 3.1.6. WWW-ReplayProtection Header > > A new header is added by which clients MUST indicate whether they > desire replay protection when POSTing RESTauth authentication > messages. The header is named WWW-SessionBinding-Type. Its value is > "yes" or "no" (defaults to "no" if absent) as shown in Figure 1. > > Replay protection is to be used only when TLS [RFC5246] is not used, > and only if a session binding type of "MAC" is also requested. Can this result in inconsistencies with session binding types? I.e. X says do Y, but Z says not to do Y. > 3.3. Session Binding Types: Cookie, Channel Bound Session URI, and MAC > > A notion of session binding type is added for binding HTTP requests > to specific RESTauth login sessions. Three types are provided: > > Cookies The traditional HTTP cookie approach to session binding; Bearer token. > Session URI HTTP requests carry a WWW-Session-URI header identifying > the session(s) (similar to cookies, but without all the associated > baggage); Bearer token. > Channel Bound Session URI Like Session URI, but may only be used in > HTTPS connections with the same channel bindings. (This implies > use of the 'tls-server-end-point' channel binding type.) Bearer token, for the one server. > MAC HTTP requests carry a WWW-Session-URI header identifying the > session(s) and a WWW-Session-MAC header that carries a MAC or MACs > binding the session URI(s) to the request. This isn't a bearer token. > 3.3.1. The New WWW-Session-URI Header > > A new HTTP header is added called WWW-Session-URI whose values > consist of session URIs. At least one session URI MUST be included. > Each session URI is an absoluteURI. Session URIs MUST NOT have > unescaped commas (',') embedded in them. Servers MAY fail to > implement support for multiple session URIs being referenced by a > single request, in which case they MUST answer with error code . > Servers MUST validate the session URI before processing the request; > if the session URI is invalid the server MUST respond with a 401 (or > TBD?) status code. > > Note that referencing multiple session URIs is permitted, but this > may not be meaningful for the application, thus the server MAY reject > this (TODO: specify a status code for this?). Maybe, reword the first paragraph, split it in two and remove the second paragraph. Right now it seems bit redundant to me. As for error codes, I think: - Bad sesion URI: 401 - Multiple URIs not supported: 400 > 3.3.2. The New WWW-Session-MAC Header > > [[anchor3: Describe the header, its values, algorithm agility, and > what the MAC is to be taken over. Note too that this cannot apply to > request contents as we have to consider chunking, and besides, a MAC > of contents really has to go as a trailer, not a header.]] Also, if contents are to be MAC'd, one could also want streaming MAC (have fun when you get PUT with content-length of 47,215,243,334 (yes, I have seen one in wild)). These edge cases are what makes MACing payload hard (perhaps too hard in general case). > [[anchor4: We may want to remove this anyways and leave it for a > session continuation spec. Or we may want to require the use of > HTTPS.]] HTTPs won't really solve all the problems this header would. > 3.3.3. To MAC or not to MAC; A MAC Trailer?? > > [[anchor5: ... This is only needed for RESTauth *without* TLS, which > will probably not be the common mode of use for RESTauth... unless we > can produce a MAC trailer extension for HTTP/2.0, in which case this > may well become a common mode of RESTauth usage.]] Yeah, here TLS does protect things so that payload MACing is not needed. > 4. Representation of Authenticated Session Resources > > It will generally be useful to be able to GET a session resource to > obtain information about the authenticated user. A GET on a session > resource which is not fully established SHOULD return an empty body. > > session_key_MAC_req Session key for MACs in requests. > > session_key_MAC_resp Session key for MACs in responses. These seem bit eh, sensitive to include. > > The server MAY exclude any part of this when the entity requesting a > session resource is the session's user. The server MUST exclude (or > respond with 401) all of the session resource's representation when > the entity requesting it is not authenticated or authorized to see > it. The server SHOULD exclude locally-determined authorization_data > and/or user_id information when the entity requesting the resource is > the session's user. If it is not authorized to see it, shouldn't the error be 403 then? > > > 5. Session URI Origin and Scope > > [[anchor9: TODO: Add a notion of session origin and scope. The > origin can probably be determined naturally from the session URI. > The scope should be set by the server. Perhaps we can also have the > scope reflected in the session URI's representation, which would > allow the scope of a session to change over time.]] On some contexts, allowing URL to be valid across servers could be handy (there being authentication servers and other servers). > [[anchor10: Clearly, using a session from one origin at another will > require a channel binding verification operation. This will have to > be added.]] Won't this really cause problems with bearer tokens? > 7.2.1. RESTauth Mechanism Names for SSHv2 Userauth Methods > > For hash agility reasons the hash function name is part of the SSHv2 > RESTauth mechanism name. To avoid "multi-level negotiation" the > SSHv2 userauth method name is also part of the RESTauth mechanism > name. > > The RESTauth mechanism name form for SSHv2 userauth methods, then, > is: ssh--. > > The following RESTauth mechanisms are defined here: > > o ssh-publickey-SHA-256 > > o ssh-hostbased-SHA-256 > > 7.2.2. Nonces > > The client and the server must each contribute 128-bit nonces. How (i.e. what parameter name?) > This entire document deals with security considerations. [Add more, > like about channel binding, same-origin-like constraints on the login > and session absolute URIs', ...] > > Note that though servers can GET/HEAD session resources, they MUST > only do it for session resources for recognized origins. See > Section 8.1.2. If it is for recognized origin, isn't the server likely to have other knowledge of those sessions (or an other way to obtain such knowledge). -Ilari From julian.reschke@gmx.de Wed Nov 6 17:57:26 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5CC21E81A6 for ; Wed, 6 Nov 2013 17:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.347 X-Spam-Level: X-Spam-Status: No, score=-104.347 tagged_above=-999 required=5 tests=[AWL=-1.748, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NI2ynOLml2+p for ; Wed, 6 Nov 2013 17:57:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id ADD0B11E81FA for ; Wed, 6 Nov 2013 17:57:08 -0800 (PST) Received: from [31.133.151.131] ([31.133.151.131]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M1Fe4-1VtRLX1bgG-00tBd7 for ; Thu, 07 Nov 2013 02:57:07 +0100 Message-ID: <527AF374.5040109@gmx.de> Date: Wed, 06 Nov 2013 17:57:08 -0800 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ilari Liusvaara , http-auth@ietf.org References: <20131106162924.GB8185@LK-Perkele-VII> In-Reply-To: <20131106162924.GB8185@LK-Perkele-VII> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jeiUb+yOE8bxizerztBGKFpgJLXOHkRfhWXooxkLGD4zXGamQ2C 9Y4slan8qQ8Un9h9Xa8e3+yD3s+Wcpt0f9N6wYd3fcMidaE+HQrB6xgeDbyFgJ+MAZHiPLG IHNDwx0HmAcWoEeKvNCAA3DhTT2QEEsRVS/bX54m92+7guKe9mkFJbgjG4k1d7XEyROG65a 0uFse6NzAa4W6U31oVa5Q== Subject: Re: [http-auth] Quick review of draft-ietf-httpauth-rest-auth-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 01:57:31 -0000 On 2013-11-06 08:29, Ilari Liusvaara wrote: >> 1. Introduction >> >> We propose a pattern for HTTP [RFC2616] [TODO: add reference to >> HTTP/2.0 as well?] authentication mechanisms that, by being >> "RESTful", obtains these goals naturally. > > Reference for HTTP/2.0 would be draft-ietf-httpbis-http2 Please stop referencing RFC 2616. HTTPbis is past IETF LC. >> 3.1. Negotiable Parameters >> >> 3.1.2. WWW-Authenticate Header Value Prefix Syntax >> >> For a DIGEST-like mechanism it might look like "WWW-Authenticate: RA- >> Digest-SHA-256 tls-server-end-point session-ID no HE4SgWGrd/ >> 3+O7t16HqusA==". For example, the mechname for the Kerberos V5 GSS- >> API mechanism might be "gss-krb5", and a WWW-Authenticate header >> value for it might look like "WWW-Authenticate: RA-gss-krb5 >> http://foo.example/restauth-login tls-server-end-point channel-bound- >> session-ID r=no". > > These examples don't look to conform to the grammar given (missing r=, s=, > etc...) > ... Furthermore, the challenge does not conform to the grammar defined in (nor ). Best regards, Julian From nico@cryptonector.com Thu Nov 7 22:23:16 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCE811E817F for ; Thu, 7 Nov 2013 22:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVxfNLpDlSpI for ; Thu, 7 Nov 2013 22:23:11 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id C981311E817D for ; Thu, 7 Nov 2013 22:23:08 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id E947A2AC064; Thu, 7 Nov 2013 22:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=3Si6NAQw6mxsx5 Tdz7SbkLdgGmc=; b=MUAB2mzY/wv3+xdZQVD1DPqeRS5REM5/izlH0RRuRzKmKI UjWvfZ7JelPta+clX/Zz7paY1/HV8vBu1GSsy8ZtOQTuKKR/8mnlka4LV+IRhoLA wjXo/C46iq2FFn4uJwN/BNE++fACFEXTbAXQJ8/v6b7u/h3Aj+aUaFyzX6I0s= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPA id A4EF82AC023; Thu, 7 Nov 2013 22:23:07 -0800 (PST) Date: Fri, 8 Nov 2013 00:23:06 -0600 From: Nico Williams To: Yoav Nir Message-ID: <20131108062305.GV18713@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "http-auth@ietf.org" Subject: Re: [http-auth] First review of the Rest-Auth draft X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 06:23:16 -0000 On Tue, Nov 05, 2013 at 08:13:51AM +0000, Yoav Nir wrote: > I have reviewed draft-ietf-httpauth-rest-auth-01. This is done with no > hats - it is not a SecDir review, nor a chair or shepherd review. My > comments have no more or less weight than those of any other > participant. Thanks for your review! > The proposal moves the authentication outside of the HTTP layer, and into the application layer. The benefits of this are: > 1. Works through unmodified routers and proxies (including TLS proxies) > 2. Creates a resource that represents the session, and can be deleted for a logout. > 3. Can re-use many existing mechanisms. > 4. RESTful, so it supports clustering. > 5. Easily implemented in application interfaces such as CGI, FastCGI, and others. > > It should be noted that all this information is in the Abstract, and > most of it should probably be moved to the Introduction (section 1). Hmm, yeah, the abstract needs to be short. It's also the place to put the attention grabbers, if you can make them short enough. > Section 1.1 has a longish review of the state of authentication on the > web. We could probably do without it, but as long as it's confined to > that one section, we can leave it at that, but discussion of > alternative methods also fills up section 2. Sure. I'd love to get rid of that. > I find section 3 clear, although I would have rather had the examples > close by rather than all the way down in section 7. [...] Ah, good point. > I would have liked to see examples for and within each sub-section of > section 3, because those help me make sense of things better than > ABNF. I agree. I'll make this change. > Section 6 describes how the server side of Rest-Auth can be done with > a single server, multiple server or an HTTP "router". For the > multi-server case, it is assumed that they will have some shared media > on which to store the resource representing the session. This is > indicated by the three words (many servers) "sharing server state". I > think that this requirement should be stated more explicitly. For a > static site, a cluster could consist of several replicated servers. > Not so for a site implementing Rest-Auth. A static site might not honor session logout, for example, and encode all session state in an encrypted cookie. Or it might use expiring, renewable session state cookes + memcached to record logouts. Session logout, incidentally, can be implemented with a probabilistic data structure (false positives -> re-login, but this can be automatic on the client side). > Section 7 finally has the example to make this all fall into place. > However, looking at figure 3, there is one thing that's still missing: > How does the client get the resource. See the first transaction in > figure 3 looks like this: > > C->S: GET /some-resources HTTP/1.1 > Host: A.example > > S->C: HTTP/1.1 401 Unauthorized > WWW-Authenticate: RA-SA-SCRAM-SHA-1 \ > http://A.example/rest-sa-scram \ > s=session-ID,MIC r=no > WWW-ChannelBinding-Types: tls-server-end-point > > And the last one looks like this: > S->C: HTTP/1.1 200 > Content-Type: application/octet-stream > Content-Length: nnn > > v=rmF9pqV8S7suAoZWja4dJRkFsKQ= > Content-Type: application/octet-stream > > So the authentication process created some SCRAM-specific parameter > "v", and a resource called "/restauth-9d0af5f680d4ff46". When the > client tries again to fetch "/some-resources", what data should be > passed in the Authorization header? The session URI / state cookie and binding. Nico -- From nico@cryptonector.com Thu Nov 7 22:48:38 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C349621E820E for ; Thu, 7 Nov 2013 22:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avAObKWg2LmB for ; Thu, 7 Nov 2013 22:48:34 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1BA21E80AC for ; Thu, 7 Nov 2013 22:48:34 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id C50F3678063; Thu, 7 Nov 2013 22:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0vxv3dOL/37y2e 4An/sIZrfqLCo=; b=AnzCEwW7av4cVfSyhcPQeiK0sLqBLYbmhGl1JHcn2z7u9v xw5nnFrXopFILk7/n/VY8ECrZo6ZdJXik6JrSiFKAa5+cgIcD+owzZaMgjm4oCL3 x50qLvG7TTxahMUHl7/qLUtVPiXTnxfQ+SwyqKfztQqaKHvaM3rAs/Z+Mh+oA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 61B07678057; Thu, 7 Nov 2013 22:48:33 -0800 (PST) Date: Fri, 8 Nov 2013 00:48:32 -0600 From: Nico Williams To: Ilari Liusvaara Message-ID: <20131108064831.GW18713@localhost> References: <20131106162924.GB8185@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131106162924.GB8185@LK-Perkele-VII> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: http-auth@ietf.org Subject: Re: [http-auth] Quick review of draft-ietf-httpauth-rest-auth-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 06:48:38 -0000 On Wed, Nov 06, 2013 at 06:29:24PM +0200, Ilari Liusvaara wrote: Thanks for the detailed review! > > 1. Introduction > > > > We propose a pattern for HTTP [RFC2616] [TODO: add reference to > > HTTP/2.0 as well?] authentication mechanisms that, by being > > "RESTful", obtains these goals naturally. > > Reference for HTTP/2.0 would be draft-ietf-httpbis-http2 Yeah, when I wrote that text I'd no idea what the schedule for HTTP/2.0 was going to be. > OAuth2 [RFC6749]. IIRC, in most common modes, OAuth1 isn't bearer token. Thanks. > > o various non-bearer token mechanisms which are not generalized or > > generalizable to a larger universe of authentication mechanisms > > [TODO: add examples, such as BrowserID]. > > It seems that locating reference for BrowserID isn't trivial, as most > refereces seem to go to Mozilla Persona (which is based on BrowserID but > probably isn't the same thing). I'll include an eref to https://developer.mozilla.org/en-US/Persona/Protocol_Overview > > Enterprises and educational settings also often have RADIUS > > [RFC2865], often used via EAP [RFC3748]. These could be supported by > > the generic security mechanism based on EAP, RADIUS, and SAML being > > developed by the ABFAB WG [TODO: add references!]. These mechanisms > > in particular will be difficult to use via Negotiate because they > > involve multiple round trips, which Negotiate supports half- > > heartedly; see Section 2.1. > > draft-ietf-abfab-gss-eap > draft-ietf-abfab-aaa-saml > > Don't see anything about RADIUS. https://tools.ietf.org/html/draft-ietf-abfab-aaa-saml "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML" I'll add the reference. > > 1.3. API-Imposed Constraints > > > > A typical constraining characteristic might be that an API assumes > > the use of GET with tokens encoded into the URI or into a header, or > > that the API makes no room for the use of headers in authentication > > message exchanges. > > > > One way to work around such constraints may be to provide various > > options in RESTauth. Another might be to use OAuth 1.0 [RFC5849] or > > 2.0 [RFC6749] as a bridge: the API would use this framework under the > > covers then obtain OAuth credentials from the server that the > > application can then use in any way that the API's form allows for. > > I can't parse this. How does OAuth come in here? The thing I had in mind here was the Android credential manager API. That API basically has the app get a token that the app then sends in some HTTP request. No allowance is made for multiple round trips and such things. My workaround for such constraints is to have the CM API run any token exchanges that are longer than .5 round trips and have the app send the last token, say. > > 2.1. In-band HTTP Authentication > > > Additionally, Negotiate can require multiple round trips but provides > > no mechanism for explicitly associating a given GSS-API security > > context token with a given GSS-API security context: it has to be > > assumed that all messages are serialized and only one multi-round > > trip security context establishment can be ongoing in any given HTTP > > connection. > > ... And this causes major problems if there are proxies... Yes, good point. Normally there's no assumption that there must be a 1-1 connection in, connection out mapping in a proxy, but HTTP/Negotiate ruins that. In practice it's not common to have to use Negotiate past a proxy -- this may be a reason why! > > 3. Protocol > > > > And for applications that may not use TLS/HTTPS: > > > > o the use of session keys as an option for integrity protection when > > TLS is not used (a light-weight security mode); see > > [I-D.williams-websec-session-continue-proto]. > > Non-bearer-token mechanisms tend to do replay protection... Right, so they can't be used with this. > > 3.1. Negotiable Parameters > > > > These examples don't look to conform to the grammar given (missing r=, s=, > etc...) I reworked one or the other somewhere in the middle and had pressing deadlines, so this slipped. Thanks for catching this! > > 3.1.6. WWW-ReplayProtection Header > > > > A new header is added by which clients MUST indicate whether they > > desire replay protection when POSTing RESTauth authentication > > messages. The header is named WWW-SessionBinding-Type. Its value is > > "yes" or "no" (defaults to "no" if absent) as shown in Figure 1. > > > > Replay protection is to be used only when TLS [RFC5246] is not used, > > and only if a session binding type of "MAC" is also requested. > > Can this result in inconsistencies with session binding types? > > I.e. X says do Y, but Z says not to do Y. X and Z are the same party though. I'm thinking that "client wants replay protection" is a bad way to put it. It'd be better to say that the client wants no TLS and wants to (must? ideally must, yeah) use MACs for session binding, then replay protection is required. I'll make this change. > > 3.3. Session Binding Types: Cookie, Channel Bound Session URI, and MAC > > > > A notion of session binding type is added for binding HTTP requests > > to specific RESTauth login sessions. Three types are provided: > > > > Cookies The traditional HTTP cookie approach to session binding; > > Bearer token. Yup. > > Session URI HTTP requests carry a WWW-Session-URI header identifying > > the session(s) (similar to cookies, but without all the associated > > baggage); > > Bearer token. Yup. > > Channel Bound Session URI Like Session URI, but may only be used in > > HTTPS connections with the same channel bindings. (This implies > > use of the 'tls-server-end-point' channel binding type.) > > Bearer token, for the one server. Yup. > > MAC HTTP requests carry a WWW-Session-URI header identifying the > > session(s) and a WWW-Session-MAC header that carries a MAC or MACs > > binding the session URI(s) to the request. > > This isn't a bearer token. Right. > As for error codes, I think: > > - Bad sesion URI: 401 > - Multiple URIs not supported: 400 OK. > > 3.3.2. The New WWW-Session-MAC Header > > > > [[anchor3: Describe the header, its values, algorithm agility, and > > what the MAC is to be taken over. Note too that this cannot apply to > > request contents as we have to consider chunking, and besides, a MAC > > of contents really has to go as a trailer, not a header.]] > > Also, if contents are to be MAC'd, one could also want streaming MAC (have > fun when you get PUT with content-length of 47,215,243,334 (yes, I have > seen one in wild)). Good point. > These edge cases are what makes MACing payload hard (perhaps too hard > in general case). Yeah. Doing session crypto at the HTTP layer is very difficult, more difficult than in other non-ordered datagram like protocols (like, say, ONC RPC). > > [[anchor4: We may want to remove this anyways and leave it for a > > session continuation spec. Or we may want to require the use of > > HTTPS.]] > > HTTPs won't really solve all the problems this header would. No, but just MACing the TLS channel binding is good enough. > > 4. Representation of Authenticated Session Resources > > > > It will generally be useful to be able to GET a session resource to > > obtain information about the authenticated user. A GET on a session > > resource which is not fully established SHOULD return an empty body. > > > > session_key_MAC_req Session key for MACs in requests. > > > > session_key_MAC_resp Session key for MACs in responses. > > These seem bit eh, sensitive to include. They wouldn't be sent to clients, but they'd be useful in the clustered server case! Login to one server, then all the others can fetch the session keys: > > The server MAY exclude any part of this when the entity requesting a > > session resource is the session's user. The server MUST exclude (or > > respond with 401) all of the session resource's representation when > > the entity requesting it is not authenticated or authorized to see > > it. The server SHOULD exclude locally-determined authorization_data > > and/or user_id information when the entity requesting the resource is > > the session's user. > > If it is not authorized to see it, shouldn't the error be 403 then? Hmmm, I guess we could have multiple sub-resources so that partial authorization (e.g., observe authenticated ID and session start and expiration times, but not session keys) could be expressed that way, but that seems overly complicated. If you get nothing, you weren't authorized, if you get some things and not others, you were partially authorized. If you get everything, you were fully authorized. > > 5. Session URI Origin and Scope > > > > [[anchor9: TODO: Add a notion of session origin and scope. The > > origin can probably be determined naturally from the session URI. > > The scope should be set by the server. Perhaps we can also have the > > scope reflected in the session URI's representation, which would > > allow the scope of a session to change over time.]] > > On some contexts, allowing URL to be valid across servers could be handy > (there being authentication servers and other servers). Exactly. > > [[anchor10: Clearly, using a session from one origin at another will > > require a channel binding verification operation. This will have to > > be added.]] > > Won't this really cause problems with bearer tokens? Yes. I'll make a note of it. > > The client and the server must each contribute 128-bit nonces. > > How (i.e. what parameter name?) Oops, I'll add that. > > This entire document deals with security considerations. [Add more, > > like about channel binding, same-origin-like constraints on the login > > and session absolute URIs', ...] > > > > Note that though servers can GET/HEAD session resources, they MUST > > only do it for session resources for recognized origins. See > > Section 8.1.2. > > If it is for recognized origin, isn't the server likely to have other > knowledge of those sessions (or an other way to obtain such knowledge). Not if session state is distributed. Being able to use HTTP in the server's side of the world for this is a win (as opposed to proprietary, non-interoperable, vendor lock-in protocols). Nico -- From julian.reschke@gmx.de Fri Nov 8 00:52:26 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C0721E81FC for ; Fri, 8 Nov 2013 00:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.216 X-Spam-Level: X-Spam-Status: No, score=-104.216 tagged_above=-999 required=5 tests=[AWL=-1.617, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxxYkveX2hS7 for ; Fri, 8 Nov 2013 00:52:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 099A221E80B5 for ; Fri, 8 Nov 2013 00:52:10 -0800 (PST) Received: from [31.133.151.131] ([31.133.151.131]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MNqfr-1VYxIR41sZ-007XdV for ; Fri, 08 Nov 2013 09:52:09 +0100 Message-ID: <527CA639.40408@gmx.de> Date: Fri, 08 Nov 2013 00:52:09 -0800 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Nico Williams , Ilari Liusvaara References: <20131106162924.GB8185@LK-Perkele-VII> <20131108064831.GW18713@localhost> In-Reply-To: <20131108064831.GW18713@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:bd+wy2mLD444WJduw/AcOqbyuyTjo4Rahq0qvuWU3z71gd+G4B/ cBO5wgDbF38/Itjwd2LBv8l90uhdrbwKmcGpCm4fN9eajqCABAqxHx+FYvfROp+sp+tHCEz wgoKAo9/ypCU0hIWBSpznfd1JsHjphFUpfYFvEa2KO/R9m+/NbF1BaDv+IYc3ZgHROTDI19 fk8NSOw9cv1RIGsSMYcNw== Cc: http-auth@ietf.org Subject: Re: [http-auth] Quick review of draft-ietf-httpauth-rest-auth-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 08:52:26 -0000 On 2013-11-07 22:48, Nico Williams wrote: > On Wed, Nov 06, 2013 at 06:29:24PM +0200, Ilari Liusvaara wrote: > > Thanks for the detailed review! > >>> 1. Introduction >>> >>> We propose a pattern for HTTP [RFC2616] [TODO: add reference to >>> HTTP/2.0 as well?] authentication mechanisms that, by being >>> "RESTful", obtains these goals naturally. >> >> Reference for HTTP/2.0 would be draft-ietf-httpbis-http2 > > Yeah, when I wrote that text I'd no idea what the schedule for HTTP/2.0 > was going to be. Exactly how is HTTP/2.0 relevant here? From duerst@it.aoyama.ac.jp Fri Nov 8 01:36:16 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A8611E8162 for ; Fri, 8 Nov 2013 01:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.69 X-Spam-Level: X-Spam-Status: No, score=-103.69 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCXyt-vI2Pzc for ; Fri, 8 Nov 2013 01:36:02 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id B28E321E8063 for ; Fri, 8 Nov 2013 01:35:51 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rA89ZIeO032110; Fri, 8 Nov 2013 18:35:18 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 493e_0801_144cf0a0_4859_11e3_b4b7_001e6722eec2; Fri, 08 Nov 2013 18:35:17 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 61145BF54D; Fri, 8 Nov 2013 18:35:17 +0900 (JST) Message-ID: <527CB04B.9080007@it.aoyama.ac.jp> Date: Fri, 08 Nov 2013 18:35:07 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <20131106162924.GB8185@LK-Perkele-VII> <20131108064831.GW18713@localhost> <527CA639.40408@gmx.de> In-Reply-To: <527CA639.40408@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] Quick review of draft-ietf-httpauth-rest-auth-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 09:36:17 -0000 On 2013/11/08 17:52, Julian Reschke wrote: > On 2013-11-07 22:48, Nico Williams wrote: >> On Wed, Nov 06, 2013 at 06:29:24PM +0200, Ilari Liusvaara wrote: >> >> Thanks for the detailed review! >> >>>> 1. Introduction >>>> >>>> We propose a pattern for HTTP [RFC2616] [TODO: add reference to >>>> HTTP/2.0 as well?] authentication mechanisms that, by being >>>> "RESTful", obtains these goals naturally. >>> >>> Reference for HTTP/2.0 would be draft-ietf-httpbis-http2 >> >> Yeah, when I wrote that text I'd no idea what the schedule for HTTP/2.0 >> was going to be. > > Exactly how is HTTP/2.0 relevant here? Lots of people outside the HTTPbis WG seem to confuse the HTTP/1.1 update and HTTP/2.0. Regards, Martin. From ekr@rtfm.com Fri Nov 8 09:17:03 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E8D21E81C4 for ; Fri, 8 Nov 2013 09:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.143 X-Spam-Level: X-Spam-Status: No, score=-104.143 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgboFw8Z-O-8 for ; Fri, 8 Nov 2013 09:16:51 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id AC04421E812C for ; Fri, 8 Nov 2013 09:16:37 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hn9so2500985wib.11 for ; Fri, 08 Nov 2013 09:16:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=6PxCiZzkY5jpuOGl7o9mc3PQNQXXpn881xL51xqvmsc=; b=CHx4xQ5VpfAqNp0zMluDRSXS/oBPAV05LBBaBZNFbx6nZy7Vc0eMsFq2puH7s1eoi2 WRZjiinRq98/iskWk/FUP3/lFxEk7U1FqLcPbp0CuM5bBKFmW8M9Js2oGiC848yMydPe odUqFliUnTnfEs71KvnGw8ZXqpJeyzW1txUoQ0SpMUW4RZ9DjyYTj3qRJQdAM3uVM5Xv iW+JTSmAclxQR8CZTi3NXn0gT+A8ule3XONDPlspq8W+5Oft8AEnQjocH14Zfy0k2vun WaPRv57ubSng1/jqT9gOsCF67aX/90PMKIugtxcJo2KIdgiAac24F4eDlCHDr37I/Cio Pwkw== X-Gm-Message-State: ALoCoQku9pm1owkTf8ZPcy1mb9Owq4Vd/GfpZo3e2F/GNiJZ6oEu9mFeIFFGWHmHrHwid95ozHA7 X-Received: by 10.194.232.4 with SMTP id tk4mr132987wjc.79.1383930996805; Fri, 08 Nov 2013 09:16:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Fri, 8 Nov 2013 09:15:56 -0800 (PST) X-Originating-IP: [2001:67c:370:176:e182:3481:15db:2026] From: Eric Rescorla Date: Fri, 8 Nov 2013 09:15:56 -0800 Message-ID: To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=001a113484727571c004eaad8b43 Subject: [http-auth] My comments from today re:password security X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 17:17:03 -0000 --001a113484727571c004eaad8b43 Content-Type: text/plain; charset=ISO-8859-1 As I was saying at the microphone, the point of a PAKE protocol is that you don't need really high entropy passwords. Accordingly, our guidance should look something like: - Users should choose passwords that aren't trivially guessable. As a wild-ass guess this means something like 10^{5} or 10^{6} bits of entropy. - Servers should have some sort of limited try capability to stop attackers from exhaustively searching low-entropy passwords. This is actually kinda tricky to avoid DoS attacks. Generally, you try to add delays that back off after failed password requests, not just lock out the account. - The server should use encryption to protect the password database. Operationally, the protocol should probably be designed with a lot of key stretching to make exhaustive offline search under password database theft more difficult. -Ekr --001a113484727571c004eaad8b43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As I was saying at the microphone, the point of a PAKE pro= tocol is that you don't need really high entropy passwords. Accordingly= , our guidance should look something like:

- Users shoul= d choose passwords that aren't trivially guessable.
=A0 =A0As a wild-ass guess this means something like 10^{5} or 10^{6} = bits
=A0 =A0of entropy.

- Servers should= have some sort of limited try capability to stop attackers
=A0 f= rom exhaustively searching low-entropy passwords. This is actually
=A0 kinda tricky to avoid DoS attacks. Generally, you try to add delay= s
=A0 that back off after failed password requests, not just lock= out the account.

- The server should use encrypti= on to protect the password database.

Operationally, the protocol should probably be designed= with a lot of
key stretching to make exhaustive offline search u= nder
password database theft more difficult.

-Ekr

--001a113484727571c004eaad8b43-- From y.oiwa@aist.go.jp Fri Nov 8 09:27:55 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD8521E813B for ; Fri, 8 Nov 2013 09:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.52 X-Spam-Level: X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SShiiVunJNDb for ; Fri, 8 Nov 2013 09:27:50 -0800 (PST) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id 759DE21E813C for ; Fri, 8 Nov 2013 09:27:50 -0800 (PST) Received: from mail-ve0-f172.google.com ([209.85.128.172]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUn0fFaNz99VFODhnnfE/6KR3g7H6Iz5M@postini.com; Fri, 08 Nov 2013 09:27:50 PST Received: by mail-ve0-f172.google.com with SMTP id oz11so429916veb.31 for ; Fri, 08 Nov 2013 09:27:49 -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=EXVylES4pDTY8eLXI+PTgp2PxtLizhSr+LTvDRobFcA=; b=hSJJO/joziCDdko4+/A7/2KXGX23QYjtE43iRmd7Qf0JwGW9NUavHey1c0E51pg9SX /fU6GHRALRMlx9OZUu7VhRmKBFJ+TDZtmC23STMog6x2HEPDhpSvRmPIqujP8n6dWUIF IRQb34nj15SiCBlmKevFO7FWOCG143v6awYn0= 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=EXVylES4pDTY8eLXI+PTgp2PxtLizhSr+LTvDRobFcA=; b=ACLUjnlXfU86eWt2WE4gYveDy2DhaPbbJzNAMwtklsvQ9ArRek8iZXW7S6phu0lZps k7uWds4K4AIrSyBNGHLAPXI2YKSWEUCuBzVHxARIekUS0bCedPIwsNyk8yUEuNuJnQtK uvKbUqU4ElixATHb3ABpD4dzVvicCRZA9v1Rpp1rfm3zirtoycOastqqxGXOYDSDdFqV LxyCTUQuM3+garO0UXFwvWis/uxZ/gAN0e3FI5BRENefRF7m40pX3KgZGZ8AR/OFj3Ok CZYeG+HzfSM/0xxDuTtXawQGQ+w8YzPuOzizZvgyHtHbA6x0q2Eckxm1j+M6ulomnwaJ y7Mg== X-Gm-Message-State: ALoCoQlMeb3Q7Z4Sy6kQrOcF8K8GY/9L9FS0ky6CWLD8Sa7bhSs+/vXPW6rjATafYYRWioyBVqWJXITruj0THlU6vTsrUuTDB6txd4Q4gWumGmp+XOvna7+i6EpWJ9gATZMZ4gX0X8+5Kdwf+QLfaysxkg3myveLeA== X-Received: by 10.58.210.39 with SMTP id mr7mr12823469vec.18.1383931669082; Fri, 08 Nov 2013 09:27:49 -0800 (PST) X-Received: by 10.58.210.39 with SMTP id mr7mr12823462vec.18.1383931668926; Fri, 08 Nov 2013 09:27:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.145 with HTTP; Fri, 8 Nov 2013 09:27:28 -0800 (PST) In-Reply-To: References: From: Yutaka OIWA Date: Sat, 9 Nov 2013 02:27:28 +0900 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7bd6c5d0852b3104eaadb371 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] My comments from today re:password security X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 17:27:55 -0000 --047d7bd6c5d0852b3104eaadb371 Content-Type: text/plain; charset=ISO-8859-1 Thank you for very well phrased, compact text. I'd like to use these texts probably in the -02 draft or around. More comments from people are still welcome. > Operationally, the protocol should probably be designed with a lot of > key stretching to make exhaustive offline search under > password database theft more difficult. I am considering to incorporate PBKDF2 or some of similar things as a key stretching mechanism, proposed by some people. I personally think this is a right direction for the draft improvement. It will replace current simple SHA256- (or SHA512-) based generation of numerical password equivalent. 2013/11/9 Eric Rescorla > As I was saying at the microphone, the point of a PAKE protocol is that > you don't need really high entropy passwords. Accordingly, our guidance > should look something like: > > - Users should choose passwords that aren't trivially guessable. > As a wild-ass guess this means something like 10^{5} or 10^{6} bits > of entropy. > > - Servers should have some sort of limited try capability to stop attackers > from exhaustively searching low-entropy passwords. This is actually > kinda tricky to avoid DoS attacks. Generally, you try to add delays > that back off after failed password requests, not just lock out the > account. > > - The server should use encryption to protect the password database. > > Operationally, the protocol should probably be designed with a lot of > key stretching to make exhaustive offline search under > password database theft more difficult. > > -Ekr > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group 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] --047d7bd6c5d0852b3104eaadb371 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you for very well phrased, compact text.
I'd like to use these texts probably in the -02 draft or around= .
More comments from people are still welcome.

> Operationally, the protocol = should probably be designed with a lot of
> key stretching to = make exhaustive offline search under
> password database theft= more difficult.

I am considering to incorporate PBKDF2 or some of similar th= ings
as a key stretching mechanism, proposed by some people.<= br>I personally think this is a right direction for the draft improvement.<= br>
It will replace current simple SHA25= 6- (or SHA512-) based
generation of num= erical password equivalent.

2013/11/9 Eric Rescorla <ekr@rtfm.com>
As I was saying at the microphone, the point of a PAKE pro= tocol is that you don't need really high entropy passwords. Accordingly= , our guidance should look something like:

- Users shoul= d choose passwords that aren't trivially guessable.
=A0 =A0As a wild-ass guess this means something like 10^{5} or 10^{6} = bits
=A0 =A0of entropy.

- Servers should= have some sort of limited try capability to stop attackers
=A0 f= rom exhaustively searching low-entropy passwords. This is actually
=A0 kinda tricky to avoid DoS attacks. Generally, you try to add delay= s
=A0 that back off after failed password requests, not just lock= out the account.

- The server should use encrypti= on to protect the password database.

Operationally, the protocol should probably be designed= with a lot of
key stretching to make exhaustive offline search u= nder
password database theft more difficult.

-Ekr


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




--
Yutaka OIWA, Ph.D. = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Leader, System Life-cycle Research Group=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Research In= stitute for Secure Systems (RISEC)
=A0 =A0 =A0National Institute of Adva= nced Industrial Science and Technology (AIST)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mail addresses: <y.oiwa@aist.go.jp>, = <yutaka@oiwa.jp&= gt;
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D =A03139 8677 9BD2 = 4405 46B5]
--047d7bd6c5d0852b3104eaadb371-- From ilari.liusvaara@elisanet.fi Fri Nov 8 11:54:11 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA1A21E8195 for ; Fri, 8 Nov 2013 11:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.842 X-Spam-Level: X-Spam-Status: No, score=-4.842 tagged_above=-999 required=5 tests=[AWL=-2.243, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj38HmvL3bFZ for ; Fri, 8 Nov 2013 11:53:57 -0800 (PST) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) by ietfa.amsl.com (Postfix) with ESMTP id D7A4C11E81B4 for ; Fri, 8 Nov 2013 11:53:56 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id CAC71817F2; Fri, 8 Nov 2013 21:53:54 +0200 (EET) Date: Fri, 8 Nov 2013 21:53:54 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20131108195354.GA7509@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Cc: http-auth@ietf.org Subject: Re: [http-auth] My comments from today re:password security X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 19:54:11 -0000 On Fri, Nov 08, 2013 at 09:15:56AM -0800, Eric Rescorla wrote: > As I was saying at the microphone, the point of a PAKE protocol is that you > don't need really high entropy passwords. Accordingly, our guidance should > look something like: > > - Users should choose passwords that aren't trivially guessable. > As a wild-ass guess this means something like 10^{5} or 10^{6} bits > of entropy. You mean 10^5-10^6 choices (roughly 17-20 bits), right (10^5 bits of entropy is kinda wild)? :-) > - The server should use encryption to protect the password database. You mean something like hashing or something else? -Ilari From mike@mtcc.com Fri Nov 8 12:02:22 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110E011E8267 for ; Fri, 8 Nov 2013 12:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IILIRnD0sXiE for ; Fri, 8 Nov 2013 12:02:16 -0800 (PST) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE2811E826A for ; Fri, 8 Nov 2013 12:02:05 -0800 (PST) Received: from takifugu.mtcc.com (mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id rA8K24Nb012430 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 8 Nov 2013 12:02:04 -0800 Message-ID: <527D433C.8030204@mtcc.com> Date: Fri, 08 Nov 2013 12:02:04 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: http-auth@ietf.org References: <20131108195354.GA7509@LK-Perkele-VII> In-Reply-To: <20131108195354.GA7509@LK-Perkele-VII> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] My comments from today re:password security X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:02:22 -0000 On 11/08/2013 11:53 AM, Ilari Liusvaara wrote: > On Fri, Nov 08, 2013 at 09:15:56AM -0800, Eric Rescorla wrote: >> As I was saying at the microphone, the point of a PAKE protocol is that you >> don't need really high entropy passwords. Accordingly, our guidance should >> look something like: >> >> - Users should choose passwords that aren't trivially guessable. >> As a wild-ass guess this means something like 10^{5} or 10^{6} bits >> of entropy. > You mean 10^5-10^6 choices (roughly 17-20 bits), right (10^5 bits of entropy > is kinda wild)? :-) > > I don't know if this is pertinent, but what people should do and do-do are manifestly different. If anybody's positing that the "should" will happen as a prerequisite to something else... well, there should be the tooth fairy too. Mike From ekr@rtfm.com Fri Nov 8 12:05:55 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCDE21F9F4F for ; Fri, 8 Nov 2013 12:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.768 X-Spam-Level: X-Spam-Status: No, score=-102.768 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdBAJnkSF0wl for ; Fri, 8 Nov 2013 12:05:50 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id A550311E8115 for ; Fri, 8 Nov 2013 12:05:48 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so2469737wgg.16 for ; Fri, 08 Nov 2013 12:05:48 -0800 (PST) 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=i2IDGv3fYzzTDEO2ykcGi3tL+l+41l5otC/yc87+T1o=; b=BHGoB8dz/yDzEWFp/q3Vbn3HSpTqu7uIKi77C8/XpcPgD41EIvu6iJUQ3XqflL3phz MpZD0Y0ao0Rbta8pvzWRHYoeTZq3WcnZajeC+PPdjw86hQ9p7L1D8J2u9p5ZbH0Ktwpb xMn55nHorfyXQL4Uh/jmzqAEdMX9zNCwao9gQzK6e33Hgy+ycoIfwm/6ReUrepk6VEw8 iDiyHAvtb2RImC+R9v3vRAjrzvDeHsODhJ5HT8KIE9r7vg+9V0q98ln2a8mWfgPr2L00 f9QYdaEetfQaknhjd7oDbVDLf2Ig8jpkzpNMe3Unu95YrbcFcvxFWS+69v0cDRZpaPK1 hsKA== X-Gm-Message-State: ALoCoQmGYB/JWSqUu1+heZSQd1YKMnnqlMpDEE+TZU3j7B2g6VklYbkamZWNogOoi3RYhIMrqof9 X-Received: by 10.180.211.71 with SMTP id na7mr3753716wic.5.1383941147919; Fri, 08 Nov 2013 12:05:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Fri, 8 Nov 2013 12:05:07 -0800 (PST) X-Originating-IP: [2001:67c:370:176:1cb5:a47c:e38f:895a] In-Reply-To: <20131108195354.GA7509@LK-Perkele-VII> References: <20131108195354.GA7509@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 8 Nov 2013 12:05:07 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c347e0831db304eaafe854 Cc: http-auth@ietf.org Subject: Re: [http-auth] My comments from today re:password security X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:05:55 -0000 --001a11c347e0831db304eaafe854 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 8, 2013 at 11:53 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Fri, Nov 08, 2013 at 09:15:56AM -0800, Eric Rescorla wrote: > > As I was saying at the microphone, the point of a PAKE protocol is that > you > > don't need really high entropy passwords. Accordingly, our guidance > should > > look something like: > > > > - Users should choose passwords that aren't trivially guessable. > > As a wild-ass guess this means something like 10^{5} or 10^{6} bits > > of entropy. > > You mean 10^5-10^6 choices (roughly 17-20 bits), right (10^5 bits of > entropy > is kinda wild)? :-) Yeah. Long week at the standards factory. > - The server should use encryption to protect the password database. > > You mean something like hashing or something else? No, I actually meant encryption at rest, because if you use low entropy passwords then DB theft becomes a really serious risk. I know this is a half measure... -Ekr > > -Ilari > --001a11c347e0831db304eaafe854 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Nov 8, 2013 at 11:53 AM, Ilari Liusvaara = <ilari.= liusvaara@elisanet.fi> wrote:
On Fri, Nov 08, 2013 at 09= :15:56AM -0800, Eric Rescorla wrote:
> As I was saying at the microphone, the point of a PAKE protocol is tha= t you
> don't need really high entropy passwords. Accordingly, our guidanc= e should
> look something like:
>
> - Users should choose passwords that aren't trivially guessable. > =A0 =A0As a wild-ass guess this means something like 10^{5} or 10^{6} = bits
> =A0 =A0of entropy.

You mean 10^5-10^6 choices (roughly 17-20 bits), right (10^5 bits of = entropy
is kinda wild)? :-)

Yeah. Long week at the = standards factory.


> - The server should use encryption to protect the password database.
You mean something like hashing or something else?
<= br>
No, I actually meant encryption at rest, because if you use l= ow entropy
passwords then DB theft becomes a really serious risk.= I know this is a
half measure...

-Ekr
=A0
-Ilari

--001a11c347e0831db304eaafe854-- From jstoke@wgu.edu Sun Nov 10 09:14:37 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B55C11E8147 for ; Sun, 10 Nov 2013 09:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 125Cux6T-WgJ for ; Sun, 10 Nov 2013 09:14:33 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id 67CDF11E80F8 for ; Sun, 10 Nov 2013 09:14:32 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id eo20so3239685lab.23 for ; Sun, 10 Nov 2013 09:14:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=M9VTt5RgFZOe323AKfyZW9JYx+H4EcGzSdLxqJi0twk=; b=OwEAACluJG4VPyRjsrx67bnlVjkgtlWgUUrqMzS9l2wNbvACVZfl3mtmPNnSRCEVck /VB+99qJUdwHCaCHd86Cemq7uMkNNLp31sFiSijK0WVAlw/ORMkPQqZr317ta36d5NQ0 rgYgmxFuCLx8VfKrdWgSa9jkRZes1gtFJ6htRW1+o/xvJ6j814gtmpB8PmaiiHH2Q/3Q QPmkKkpj1Pw/rkDqyACvXcwC1FIsRghfBUXe2mSyFKcooLWDS0lERB755Mta3viARFIw RM4C9Ke4dGT3Smloae3ST0lH2DS14UaJqHeDwpK+8QMHWrfy/Kva7UipQCIUmzJsy9mp 9RBw== X-Gm-Message-State: ALoCoQlpm8w43GEubX2K7/UPmUYz/w/Ch132t5haRimoejcX6nB3TNR6+iF7pj8DkmiNF9PrgRZC MIME-Version: 1.0 X-Received: by 10.112.89.232 with SMTP id br8mr18797285lbb.20.1384103671237; Sun, 10 Nov 2013 09:14:31 -0800 (PST) Received: by 10.114.182.166 with HTTP; Sun, 10 Nov 2013 09:14:31 -0800 (PST) Date: Sun, 10 Nov 2013 10:14:31 -0700 Message-ID: From: Jonathan Stoke To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=001a11c36f44a81bfd04ead5bff4 Subject: [http-auth] password security and entropy - BCP needed X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jstoke@my.wgu.edu List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 17:17:22 -0000 --001a11c36f44a81bfd04ead5bff4 Content-Type: text/plain; charset=ISO-8859-1 Internet-Draft J. STOKE Request for Comments: nnnn March 2013 Intended Status: Proposed Standard BCP for Password-based Authentication File Name: draft-ietf-httpauth-stoke-password-policy-00.txt Expiration Date: January 9, 2014 Abstract There is no BCP for password-based authentication on the Internet. This form of authentication is common and prevalent. A BCP statement is long overdue, and it will require a paradigm shift on the part of the IETF to accomplish the goal. The first necessary step will be to arrive at a consensus that the goal must be accomplished and that the proper venue is the IETF. Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. STOKE Internet-Draft [page 1] RFC nnnn BCP for Password-based Authentication March 2013 1. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. "Username" means an ASCII string unique to one individual entity per realm. "Password" means an ASCII string associated to a username intended as a secret authentication factor known only to the authority performing credential-based authentication and the authorized user for whom it serves as a credential for authentication. 2. Introduction Historically Internet standards have generally been concerned with the technical specifications for hardware and software required for computer communication across interconnected networks. However, since the Internet itself is composed of networks operated by a great variety of organizations, with diverse goals and rules, good user service requires that the operators and administrators of the Internet follow some common guidelines for policies and operations. The lack of standards, policy, or guidelines regarding password-based authentication has resulted in widely varying and often incompatible or conflicting rule sets to which Internet users are expected to adapt. The limitations of human memory are well recognized as a result of many published studies. The rapid increase in the number of sites requiring passwords coupled with the admonitions to change passwords frequently and to use a unique password for every website now exceeds the design limitations of the average human user of the Internet. A BCP can help resolve this by providing certainty for Internet users, software designers, and site administrators. 3. Proposed Framework In order for an authentication portal to claim compliance with this RFC the following minimum requirements MUST be attained. Nothing in this RFC is intended to preclude any other schemes or policies. The permitted character set MUST include the numbers 0-9 (ASCII 48-57 decimal), capital A-Z (ASCII 65-90 decimal), lower case a-z (ASCII 97-122 decimal), and the symbols on a standard keyboard appearing above the numbers 0-9, !@#$%^&*(), (ASCII 33, 64, 35, 36, 37, 94, 38, 42, 40, 41 decimal). The prohibited character set MUST include the period (ASCII 46 decimal) and the comma (ASCII 44 decimal). STOKE Internet-Draft [page 2] RFC nnnn BCP for Password-based Authentication March 2013 The user MUST be permitted to select their username-password credential pair. By this it is meant that the username MUST be selected by the user and not assigned by the site administrator, or if a default for either the username and/or the password is assigned, then the user MUST have the option to modify either or both. The user MUST have the option to register a notification address, such as an email address or text-capable device, with the authentication portal administrator. The user MUST be permitted to update either the username, or the password, or both, at any time and all changes MUST be reported to the registered notification address. The user MUST NOT be required to update either the username, or the password, or both; except in the case when an initial, default username and/or password is assigned. The user MUST be afforded a mechanism by which to report a compromised account and such reports MUST be addressed in less than one business day. The user MUST have the option of a secure logon using https links secured by sites offering credentials signed by a recognized Certification Authority (CA) using the latest secure methods for accessing a web site (which at present is the latest version of TLS [RFC5246]). The user's credentials stored in a database MUST be adequately secured with encryption equivalent to or stronger than 128-bit AES encryption and strong access controls. The user's credentials MUST be protected against brute force attack by implementation of a failed login policy and that policy MUST NOT divulge information useful to an attacker (e.g. the message MUST NOT state "username does not exist"). The user MUST be informed of the credential requirements, including minimum length, maximum length, and permitted character set. The user MUST be informed if access to the single account is granted to more than one credential pair, and MUST be informed whenever more than one credential pair is valid for access to the account. The user MUST be informed of any available forgotten password reset mechanisms, and MUST NOT be required to enable or configure a reset mechanism. STOKE Internet-Draft [page 3] RFC nnnn BCP for Password-based Authentication March 2013 4. Discussion The purpose of this RFC is to focus discussion on the issue of a lack of defining standards for password-based authentication on the Internet. No proposed solutions in this document are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate policy, leading eventually to the adoption of a BCP. For instance, the discussion of what symbols from the ASCII character set will be part of the standard permitted symbols for use would consider security in determining if a period or a comma would be permitted. These characters are often used in scripting, and script injection attacks would be diminished if these characters were not permitted. On the other hand, if these characters were permitted, and Internet users were aware of this fact as part of a BCP, then the user would have a larger character set from which to create passwords thus significantly increasing security. Discussion will eventually need to take place for internationalization of a BCP document. To become a BCP, a consensus would need to emerge concerning such details as a minimum password length, a minimum encryption standard for protection of the credential database, and the failed logon lockout policy, to name just a few key decisions. Complex decisions, such as inclusion or exclusion of unprintable control characters (ASCII 0 through 31 and 127 decimal) and the nonprinting space character (ASCII 32 decimal) will require consideration and discussion. Definitions will need to be standardized, beginning with definitions for "username" and "password". This proposed framework resembles a statement of user rights and responsibilities. It digresses from the paradigm that users must be protected from themselves, and instead moves toward the paradigm that users shall be given adequate information to make and implement informed decisions. The crucial hurdle that must be overcome, however, is that of requiring a paradigm shift on the part of the IETF. The IETF has thus far avoided this difficult issue for reasons apparently based in tradition and history rather than logic and need. 5. Interest This RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers. STOKE Internet-Draft [page 4] RFC nnnn BCP for Password-based Authentication March 2013 6. Security Considerations The entire purpose and focus of this BCP is to foster and enhance a secure environment for internet users dependent upon credential-based authentication. 7. IANA Considerations IANA considerations are truly believed to be irrelevant to this document. 8. References 8.1. Normative References [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 8.2. Informative References [ISO10646] International Organization for Standardization, "Information Technology -- Universal Multiple- Octet Coded Character Set (UCS)", ISO/ IEC 10646:2003, December 2003. [US-ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4-1968, 1968. [Unicode] The Unicode Consortium, "The Unicode Standard, Version 5.0", 2006. (Addison-Wesley, 2006. ISBN 0-321-48091-0). [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC1704] Haller, N. & R. Atkinson, "On Internet Authentication", RFC 1704, October 1994. [FIPS197] National Bureau of Standards, "Advanced Encryption Standard", Federal Information Processing Printing Office, Washington, DC, November 2001. STOKE Internet-Draft [page 5] RFC nnnn BCP for Password-based Authentication March 2013 Author's Address jonathan stoke 4608 E. Baytree Court Boise, ID 83716 Phone: 208-344-4805 Email: jstoke@my.wgu.edu File Name: draft-ietf-httpauth-stoke-password-policy-00.txt Expiration Date: January 9, 2014 STOKE Internet-Draft [page 6] --001a11c36f44a81bfd04ead5bff4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 J. STOKE
Request for Comments: nnnn=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 March 2013
Intended Status: Proposed Standar= d

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 BCP for Pa= ssword-based Authentication
File Name:=A0 draft-ietf-httpauth-stoke-password-policy-00.txt
Expi= ration Date:=A0 January 9, 2014
Abstract
=A0=A0 There i= s no BCP for password-based authentication on the Internet.
=A0=A0 This = form of authentication is common and prevalent. A BCP
=A0=A0 statement is long overdue, and it will require a paradigm shift on=A0=A0 the part of the IETF to accomplish the goal. The first necessary=A0=A0 step will be to arrive at a consensus that the goal must be
=A0= =A0 accomplished and that the proper venue is the IETF.
Status of this Memo
=A0=A0 This document specifies an Intern= et Best Current Practices for
=A0=A0 the Internet Community, and request= s discussion and suggestions
=A0=A0 for improvements.=A0 Distribution of= this memo is unlimited.
=A0=A0
=A0=A0 This Internet-Draft is submitted in full conformance with= the
=A0=A0 provisions of BCP 78 and BCP 79. Internet-Drafts are working=
=A0=A0 documents of the Internet Engineering Task Force (IETF). Note th= at
=A0=A0 other groups may also distribute working documents as
=A0=A0 Internet-Drafts. The list of current Internet-Drafts is at
=A0=A0= http://datatracker.= ietf.org/drafts/current.
=A0=A0 Internet-Drafts are draft doc= uments valid for a maximum of six months
=A0=A0 and may be updated, replaced, or obsoleted by other documents at any=
=A0=A0 time. It is inappropriate to use Internet-Drafts as reference=A0=A0 material or to cite them other than as "work in progress."= ;
Copyright Notice
=A0=A0 Copyright (c) 2013 IETF Trust and the per= sons identified as the
=A0=A0 document authors. All rights reserved.
=A0=A0 This document is subject to BCP 78 and the IETF Trust's L= egal
=A0=A0 Provisions Relating to IETF Documents
=A0=A0 (http://trustee.ietf.org/license-info) in = effect on the date of
=A0=A0 publication of this document. Please review= these documents
=A0=A0 carefully, as they describe your rights and restrictions with respec= t
=A0=A0 to this document. Code Components extracted from this document = must
=A0=A0 include Simplified BSD License text as described in Section = 4.e of
=A0=A0 the Trust Legal Provisions and are provided without warranty as
= =A0=A0 described in the Simplified BSD License.
=A0=A0
STOKE=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Internet-Draft=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [page 1]=0C
RFC nnnn=A0=A0=A0=A0=A0=A0=A0=A0 BCP for Password-based Authenticat= ion=A0=A0=A0=A0=A0=A0=A0 March 2013
1. Definitions
=A0=A0 The key words "MUST", "= MUST NOT", "REQUIRED", "SHALL", "SHALL NOT&qu= ot;,
=A0=A0 "SHOULD", "SHOULD NOT", "RECOMMENDE= D", "MAY", and "OPTIONAL" in this
=A0=A0 document are to be interpreted as described in RFC 2119.
= =A0=A0 "Username" means an ASCII string unique to one individual = entity per
=A0=A0 realm.
=A0=A0 =A0
=A0=A0 "Password" me= ans an ASCII string associated to a username intended as
=A0=A0 a secret authentication factor known only to the authority performin= g
=A0=A0 credential-based authentication and the authorized user for who= m it
=A0=A0 serves as a credential for authentication.
2. Intr= oduction
=A0=A0 Historically Internet standards have generally been concerned w= ith
=A0=A0 the technical specifications for hardware and software requir= ed for
=A0=A0 computer communication across interconnected networks. How= ever,
=A0=A0 since the Internet itself is composed of networks operated by a grea= t
=A0=A0 variety of organizations, with diverse goals and rules, good us= er
=A0=A0 service requires that the operators and administrators of the<= br>=A0=A0 Internet follow some common guidelines for policies and operation= s.
=A0=A0 The lack of standards, policy, or guidelines regarding password= -based
=A0=A0 authentication has resulted in widely varying and often in= compatible
=A0=A0 or conflicting rule sets to which Internet users are e= xpected to
=A0=A0 adapt.
=A0=A0 The limitations of human memory are well rec= ognized as a
=A0=A0 result of many published studies. The rapid increase= in the number
=A0=A0 of sites requiring passwords coupled with the admo= nitions to change
=A0=A0 passwords frequently and to use a unique password for every website<= br>=A0=A0 now exceeds the design limitations of the average human user of t= he
=A0=A0 Internet. A BCP can help resolve this by providing certainty f= or
=A0=A0 Internet users, software designers, and site administrators.
3. Proposed Framework
=A0=A0 In order for an authentication = portal to claim compliance with this
=A0=A0 RFC the following minimum re= quirements MUST be attained. Nothing in
=A0=A0 this RFC is intended to p= reclude any other schemes or policies.
=A0=A0 The permitted character set MUST include the numbers 0-9
=A0= =A0 (ASCII 48-57 decimal), capital A-Z (ASCII 65-90 decimal), lower case=A0=A0 a-z (ASCII 97-122 decimal), and the symbols on a standard keyboard<= br>=A0=A0 appearing above the numbers 0-9, !@#$%^&*(), (ASCII 33, 64, 3= 5, 36,
=A0=A0 37, 94, 38, 42, 40, 41 decimal).
=A0=A0 The prohibited cha= racter set MUST include the period (ASCII 46
=A0=A0 decimal) and the com= ma (ASCII 44 decimal).
STOKE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [page 2]
=0C
RFC nnnn=A0=A0=A0=A0=A0=A0=A0=A0 BCP for Password-based Authenticati= on=A0=A0=A0=A0=A0=A0=A0 March 2013
=A0=A0 The user MUST be permit= ted to select their username-password
=A0=A0 credential pair. By this it= is meant that the username MUST be
=A0=A0 selected by the user and not assigned by the site administrator, or<= br>=A0=A0 if a default for either the username and/or the password is assig= ned,
=A0=A0 then the user MUST have the option to modify either or both.=
=A0=A0 The user MUST have the option to register a notification address,=A0=A0 such as an email address or text-capable device, with the
=A0=A0= authentication portal administrator.
=A0=A0 The user MUST be per= mitted to update either the username, or the
=A0=A0 password, or both, at any time and all changes MUST be reported to=A0=A0 the registered notification address.
=A0=A0 The user MUS= T NOT be required to update either the username, or the
=A0=A0 password,= or both; except in the case when an initial, default
=A0=A0 username and/or password is assigned.
=A0=A0 The user MUST= be afforded a mechanism by which to report a
=A0=A0 compromised account= and such reports MUST be addressed in less than
=A0=A0 one business day= .
=A0=A0 The user MUST have the option of a secure logon using https links=A0=A0 secured by sites offering credentials signed by a recognized
=A0= =A0 Certification Authority (CA) using the latest secure methods for
=A0= =A0 accessing a web site (which at present is the latest version of TLS
=A0=A0 [RFC5246]).
=A0=A0 The user's credentials stored in a = database MUST be adequately
=A0=A0 secured with encryption equivalent to= or stronger than 128-bit AES
=A0=A0 encryption and strong access contro= ls.
=A0=A0 The user's credentials MUST be protected against brute force att= ack
=A0=A0 by implementation of a failed login policy and that policy MU= ST NOT
=A0=A0 divulge information useful to an attacker (e.g. the messag= e MUST NOT
=A0=A0 state "username does not exist").
=A0=A0 The use= r MUST be informed of the credential requirements, including
=A0=A0 mini= mum length, maximum length, and permitted character set.
=A0=A0 T= he user MUST be informed if access to the single account is granted
=A0=A0 to more than one credential pair, and MUST be informed whenever more=
=A0=A0 than one credential pair is valid for access to the account.
=A0=A0 The user MUST be informed of any available forgotten password= reset
=A0=A0 mechanisms, and MUST NOT be required to enable or configure a reset<= br>=A0=A0 mechanism.
=A0=A0
STOKE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [page 3]
=0C
RFC nnnn=A0=A0=A0= =A0=A0=A0=A0=A0 BCP for Password-based Authentication=A0=A0=A0=A0=A0=A0=A0 = March 2013
4. Discussion
=A0=A0 The purpose of this RFC is to focus dis= cussion on the issue of a lack
=A0=A0 of defining standards for password= -based authentication on the
=A0=A0 Internet. No proposed solutions in t= his document are intended as
=A0=A0 standards for the Internet. Rather, it is hoped that a general
= =A0=A0 consensus will emerge as to the appropriate policy, leading
=A0= =A0 eventually to the adoption of a BCP.
=A0=A0 For instance, the= discussion of what symbols from the ASCII character
=A0=A0 set will be part of the standard permitted symbols for use would
= =A0=A0 consider security in determining if a period or a comma would be
= =A0=A0 permitted. These characters are often used in scripting, and script<= br>=A0=A0 injection attacks would be diminished if these characters were no= t
=A0=A0 permitted. On the other hand, if these characters were permitted, an= d
=A0=A0 Internet users were aware of this fact as part of a BCP, then t= he
=A0=A0 user would have a larger character set from which to create pa= sswords
=A0=A0 thus significantly increasing security.
=A0=A0 Discussion = will eventually need to take place for
=A0=A0 internationalization of a = BCP document.
=A0=A0 To become a BCP, a consensus would need to e= merge concerning such
=A0=A0 details as a minimum password length, a minimum encryption standard<= br>=A0=A0 for protection of the credential database, and the failed logon=A0=A0 lockout policy, to name just a few key decisions.
=A0=A0
= =A0=A0 Complex decisions, such as inclusion or exclusion of unprintable
=A0=A0 control characters (ASCII 0 through 31 and 127 decimal) and the
= =A0=A0 nonprinting space character (ASCII 32 decimal) will require
=A0= =A0 consideration and discussion.
=A0=A0
=A0=A0 Definitions will nee= d to be standardized, beginning with definitions
=A0=A0 for "username" and "password".
=A0=A0 = This proposed framework resembles a statement of user rights and
=A0=A0 = responsibilities. It digresses from the paradigm that users must be
=A0= =A0 protected from themselves, and instead moves toward the paradigm that =A0=A0 users shall be given adequate information to make and implement
= =A0=A0 informed decisions.
=A0=A0 The crucial hurdle that must be= overcome, however, is that of
=A0=A0 requiring a paradigm shift on the = part of the IETF. The IETF has
=A0=A0 thus far avoided this difficult issue for reasons apparently based i= n
=A0=A0 tradition and history rather than logic and need.
5. = Interest
=A0=A0 This RFC is being distributed to members of the I= nternet community in
=A0=A0 order to solicit their reactions to the proposals contained in it.=A0=A0 While the issues discussed may not be directly relevant to the
= =A0=A0 research problems of the Internet, they may be interesting to a
= =A0=A0 number of researchers and implementers.
=A0=A0
STOKE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 [page 4]
=0C
RFC nnnn=A0=A0=A0=A0=A0=A0=A0=A0 BCP for Pa= ssword-based Authentication=A0=A0=A0=A0=A0=A0=A0 March 2013
6. Se= curity Considerations
=A0=A0 The entire purpose and focus of this= BCP is to foster and enhance a
=A0=A0 secure environment for internet users dependent upon credential-base= d
=A0=A0 authentication.
7. IANA Considerations
=A0= =A0 IANA considerations are truly believed to be irrelevant to this
=A0= =A0 document.
8. References
8.1.=A0 Normative References
=A0=A0=A0=A0= =A0=A0
=A0=A0 [RFC3629]=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yergeau, F., "U= TF-8, a transformation format of
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 ISO 10646", STD 63, RFC 3629, November 2003.<= /div>
=A0=A0 [RFC2119]=A0=A0=A0=A0=A0=A0=A0=A0=A0 Bradner, S., "Key wor= ds for use in RFCs to
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Indicate Requirement Levels", BCP 14, RFC 2119,
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 March 1997.
=A0=A0 [RFC5246]=A0=A0=A0=A0=A0=A0=A0=A0=A0 Dierks, T. and E. Resco= rla, "The Transport Layer
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Security (T= LS) Protocol Version 1.2", RFC 5246,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 August 2008.
8.2.=A0 Informativ= e References
=A0=A0 [ISO10646]=A0=A0=A0=A0=A0=A0=A0=A0 Internatio= nal Organization for Standardization,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "Infor= mation Technology -- Universal Multiple-
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Octet Coded Character Set (UCS)", IS= O/
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IEC 1= 0646:2003, December 2003.
=A0=A0=A0=A0=A0=A0
=A0=A0 [US-ASCII]=A0=A0= =A0=A0=A0=A0=A0=A0 American National Standards Institute, "Coded
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Character S= et -- 7-bit American Standard Code for
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Information Interchange", ANSI X3.4-196= 8, 1968.
=A0=A0 [Unicode]=A0=A0=A0=A0=A0=A0=A0=A0=A0 The Unicode = Consortium, "The Unicode Standard,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Version 5.0= ", 2006. (Addison-Wesley, 2006.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ISBN 0-321-48091-0).
=A0=A0=A0=A0=A0=A0 <= br>=A0=A0 [RFC2818]=A0=A0=A0=A0=A0=A0=A0=A0=A0 Rescorla, E., "HTTP Ove= r TLS", RFC 2818, May 2000.
=A0=A0
=A0=A0 [RFC1704]=A0=A0=A0=A0=A0=A0=A0=A0=A0 Haller, N. & R. Atkinson, &= quot;On Internet
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Authentication", RFC 1704, October 1994.
=A0=A0=A0=A0=A0= =A0
=A0=A0 [FIPS197]=A0=A0=A0=A0=A0=A0=A0=A0=A0 National Bureau of Stan= dards, "Advanced Encryption
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Standard&qu= ot;, Federal Information Processing
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 Printing Office, Washington, DC, November 2001.=
STOKE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 [page 5]
=0C
RFC nnnn=A0=A0=A0=A0=A0=A0=A0=A0 BCP for Password-based Authenticati= on=A0=A0=A0=A0=A0=A0=A0 March 2013=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0=
Author's Address
jonathan stoke
4608 E. Baytree Court=
Boise, ID=A0 83716
Phone: 208-344-4805
Email: jstoke@my.wgu.edu
File Name:=A0 draft-ietf-httpauth-stoke-password-policy-00.txt
Expirati= on Date:=A0 January 9, 2014
=A0
=A0
=A0
=
=A0
=A0
=A0
=A0
=A0
=A0
= =A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
<= div>=A0
STOKE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 [page 6]
=0C
--001a11c36f44a81bfd04ead5bff4-- From ilari.liusvaara@elisanet.fi Sun Nov 10 16:37:30 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B7D21E8096 for ; Sun, 10 Nov 2013 16:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.562 X-Spam-Level: X-Spam-Status: No, score=-4.562 tagged_above=-999 required=5 tests=[AWL=-1.962, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBp0sh8oHTav for ; Sun, 10 Nov 2013 16:37:16 -0800 (PST) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) by ietfa.amsl.com (Postfix) with ESMTP id 29B9921F9FB7 for ; Sun, 10 Nov 2013 16:37:14 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 4E2C918877F; Mon, 11 Nov 2013 02:37:12 +0200 (EET) Date: Mon, 11 Nov 2013 02:37:12 +0200 From: Ilari Liusvaara To: jstoke@my.wgu.edu Message-ID: <20131111003711.GA5425@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Cc: http-auth@ietf.org Subject: Re: [http-auth] password security and entropy - BCP needed X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 00:37:40 -0000 On Sun, Nov 10, 2013 at 10:14:31AM -0700, Jonathan Stoke wrote: > Intended Status: Proposed Standard > > BCP for Password-based Authentication Intended status is PS, but title suggest it should be BCP? > "Username" means an ASCII string unique to one individual entity per > realm. It might not be ASCII string. > "Password" means an ASCII string associated to a username intended as > a secret authentication factor known only to the authority performing > credential-based authentication and the authorized user for whom it > serves as a credential for authentication. Again, might not be ASCII string. > 3. Proposed Framework > In order for an authentication portal to claim compliance with this > RFC the following minimum requirements MUST be attained. Nothing in > this RFC is intended to preclude any other schemes or policies. > The permitted character set MUST include the numbers 0-9 > (ASCII 48-57 decimal), capital A-Z (ASCII 65-90 decimal), lower case > a-z (ASCII 97-122 decimal), and the symbols on a standard keyboard > appearing above the numbers 0-9, !@#$%^&*(), (ASCII 33, 64, 35, 36, > 37, 94, 38, 42, 40, 41 decimal). > The prohibited character set MUST include the period (ASCII 46 > decimal) and the comma (ASCII 44 decimal). Is this for usernames? Or passwords? If it is for passwords, why? Well-implemented password system SHOULD NOT have troubles with handling all sorts of stuff, especially not in pritable ASCII range. Also, that list of characters above numbers is layout dependent. For me it is !"#¤%&/()=. Note, one of those is non-ASCII (¤ is C2 A4 in UTF-8). For me, all ASCII printables are easily typeable. But that might not be true on non-latin-based keyboard layouts... An ':' in username could create actual trouble... Or '*'. > The user's credentials stored in a database MUST be adequately > secured with encryption equivalent to or stronger than 128-bit AES > encryption and strong access controls. Database encryption (as opposed to just hash and salt)? > The user's credentials MUST be protected against brute force attack > by implementation of a failed login policy and that policy MUST NOT > divulge information useful to an attacker (e.g. the message MUST NOT > state "username does not exist"). No mention of password hashing /w salting. Or password stretching. > For instance, the discussion of what symbols from the ASCII character > set will be part of the standard permitted symbols for use would > consider security in determining if a period or a comma would be > permitted. These characters are often used in scripting, and script > injection attacks would be diminished if these characters were not > permitted. On the other hand, if these characters were permitted, and > Internet users were aware of this fact as part of a BCP, then the > user would have a larger character set from which to create passwords > thus significantly increasing security. Mechanisms to restrict the set of characters to counter injection attacks later tend to be brittle... On the other hand, sometimes character set needs to be restricted in order to appropriately handle the strings later (if some internal special notations are used). E.g. On one site, creating account name with '*' in it or account name consisting entierely of numbers. In contrast, using anything from non-ASCII Unicode (even astrals) should be no problem (except if the characters are too exotic, the name might not display properly). -Ilari From y.oiwa@aist.go.jp Mon Nov 11 13:17:22 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE77111E8150 for ; Mon, 11 Nov 2013 13:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.553 X-Spam-Level: X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1pp8gfs0-MG for ; Mon, 11 Nov 2013 13:17:11 -0800 (PST) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6D211E8145 for ; Mon, 11 Nov 2013 13:17:10 -0800 (PST) Received: from mail-vb0-f54.google.com ([209.85.212.54]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUoFJVJMlbJAI8Sbs0qvVtwmCUgtWZqJv@postini.com; Mon, 11 Nov 2013 13:17:10 PST Received: by mail-vb0-f54.google.com with SMTP id q4so712998vbe.41 for ; Mon, 11 Nov 2013 13:17:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=TSCGJr0icC/ypDLwpfpgQfZ4m+2HFHvRGKIHN1FfjKU=; b=kXj9OJNqagXQAgpL5Bgt98X22u/+DJcigktr2+SZLE+DuRuQesutQOmC3MqpnJBDUZ nfcVlrz4Y0A9JncrnzbleqvdSX3F1zEEYrZMW8WTawa39KMVkf/Q1qFBypo+AQnI2y6d +lGC74KFmvJfZ8OvpY9gTTUSQsLpTDk3LWIgE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=TSCGJr0icC/ypDLwpfpgQfZ4m+2HFHvRGKIHN1FfjKU=; b=MJOcawupgs4HLoApjVet6XUalr8xTF/CGI75bE4EFbXIHZpB9KSg0Vk7JacSCP46KD DXNttBV33kL5DU78FAcvNJCWBK64Y1/5D5aKxIlclPgduABO1/PYvbXMv+u0BN3rB0g1 GZi10gx9vJw6stm4kv54xbFs1hNLKEQ6k52BBGfI16IPmttbRO03WK+ch3JbwF8PWJ30 c6xFCy0YnQsfCIRWzUIPrWfxM9DAsDgT1c25FOK8mkZy6aDrHrGCwFQLN63Rrj/e+3U0 B5VCf1p+v18i1zlgRAYcUD1daMs3fBv0/PWpIQJnAvncwuSN57jjzET+GPGaVFr8eZiS ijPg== X-Gm-Message-State: ALoCoQkSzcizNF7LEHR30tpKBRvAkoU7wHH5S5odE23p3L4+783RrOvo+i7u52ylQ/Y7KpWbP4OtzBr9erN6gCzzrF6NJMsxuKHbPkMy5LieOk5O/UIDC6b/jfIW7hNqiPkGFPjhuJBkD70YZ3XrFpOg67UC57Z0CQ== X-Received: by 10.220.186.202 with SMTP id ct10mr26129628vcb.14.1384204627771; Mon, 11 Nov 2013 13:17:07 -0800 (PST) X-Received: by 10.220.186.202 with SMTP id ct10mr26129622vcb.14.1384204627685; Mon, 11 Nov 2013 13:17:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.145 with HTTP; Mon, 11 Nov 2013 13:16:47 -0800 (PST) From: Yutaka OIWA Date: Tue, 12 Nov 2013 06:16:47 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [http-auth] Commonarities discussion: technical side, feature sets X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:17:22 -0000 Dear all, We had a discussion on possible merging of common features between drafts in Vancouver. Commonalities lies in two aspects: basic technical functionality (e.g. key management) and a user-interface/application-semantics facilities (e.g. log-out). This mail is about the former. In the past, I wrote a draft http://tools.ietf.org/id/draft-oiwa-httpauth-multihop-template-00.txt as a possible starting point at that time. I'm not sticked to this previous proposal, but it might be a good starting point for exploring "what features" the commonarities might have. The requirements and the provision of my previous drafts are as follows: Requirements: the key exchange primitives to be implemented must: * exchange two or more messages between servers and clients. (currently limited to client-first type of exchange, but it can be extended) * generate a shared key between peers after that. The shared key agrees between peers when authentication succeeds, of differs when authentication fails. ...yes, these are quite simple. Provisions: the template will then provide the following common facilities: * a discovery mechanism for required authentication algorithms (as usual as the 401 message in Basic, in an RFC 2617 way) * opportunistic shared key caching between peers - time- and number-based expiry of shared keys - nonce management for preventing replay attacks - automatic renegotiation for expired keys - both peer may freely drop/forget almost any cached keys and protocols still work * short-cut exchange (sometimes called reauthentication) using cached shared keys - 1RT with known URL, with cached keys - normal RTs with known URL, keys expired - +1RT for unknown URL, for an additional 401 message * channel binding with lower layers (HTTP and TLS) * (optional) channel binding with higher layers (binding key provision) How do you think about these feature sets? Do we have something missing? If you have any idea on the missing features, please let me know. Thanks, -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group 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]