Re: Avoiding PAM checks Bug 9892
Kirk Augustin <[email protected]> Mon, 25 Aug 2014 17:39:54 -0700
| Newsgroups | gmane.network.open-pegasus.general |
|---|---|
| Message-ID | <[email protected]> |
---1593584224-1421366921-1409013594=:3350 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Andreas, =0A=0A=0AIt sounds like your methodology will work fine, but as yo= u described it, I would normally call that a "session token".=0AThe way I u= se the word "cookie" as normally client side, file storage for the server, = and accessed only by the server, not the client.=0AWhat you want I think is= where the server hands it to the client once, who then hands it back to th= e server with every subsequent transaction of the session.=0A=0A=0A=A0=0AKi= rk Augustin=0A11821 NW McNamee Rd=0APortland, OR 97231=0A=0A=0AHM: 503-289-= 4356=0A=0A=0A>________________________________=0A> From: Andreas Maier <MAI= [email protected]>=0A>To: Kirk Augustin <[email protected]> =0A>Cc: Karl= Schopmeyer <[email protected]>; Jan Safranek <[email protected]>; = OpenPegasus Developer mailing list <[email protected]> =0A>Sent: Mo= nday, August 25, 2014 6:13 AM=0A>Subject: Avoiding PAM checks Bug 9892=0A> = =0A>=0A>=0A>Kirk,=0A>On your statement:=0A>> If you use a cookie, then the = server will have to request it each time=0A>and cause excess wasted traffic= .=0A>I was not aware that in order to use cookies, the server has to turn a= round=0A>and ask the client. The proposed approach would cause the server t= o include=0A>the cookie in the response header of the response it sends any= way, and the=0A>client would include the so received cookie in the request = header of any=0A>subsequent requests it sends anyway. That would not incur = any additional=0A>traffic.=0A>Are you saying that the proposed approach can= not work that way?=0A>=0A>On DMTF involvement:=0A>DMTF would be involved to= document the concept as an optional feature in=0A>DSP0200, as it does alre= ady with a number of other HTTP headers (both=0A>standard and extension). R= eason being that DMTF wants to foster=0A>interoperability across *multiple*= implementations, instead of just=0A>allowing a particular implementation b= etween its client and server to do=0A>something that is allowed as per the = HTTP standard, but otherwise not known=0A>outside of that particular implem= entation. Now that is Andy's view on how=0A>DMTF operates, but it is with m= y DMTF hat (particularly the CIM-XML hat)=0A>on.... Plus, IBM uses CIM clie= nts and servers form multiple=0A>implementations, so we have also a company= interest for interoperability.=0A>=0A>Andy=0A>=0A>Andreas Maier=0A>IBM Sen= ior Technical Staff Member, Systems Management Architecture & Design=0A>IBM= Research & Development Laboratory Boeblingen, Germany=0A>[email protected]= , +49-7031-16-3654=0A>_____________________________________________________= ___________________=0A>IBM Deutschland Research & Development GmbH=0A>Vorsi= tzende des Aufsichtsrats: Martina Koederitz=0A>Geschaeftsfuehrung: Dirk Wit= tkopp=0A>Sitz der Gesellschaft: Boeblingen=0A>Registergericht: Amtsgericht = Stuttgart, HRB 243294=0A>=0A>----- Forwarded by Andreas Maier/Germany/IBM o= n 25.08.2014 14:19 -----=0A>=0A>From:=A0=A0=A0 Kirk Augustin <kirk_augustin= @yahoo.com>=0A>To:=A0=A0=A0 Karl Schopmeyer <[email protected]>, Jan = Safranek=0A>=A0 =A0 =A0 =A0 =A0 =A0 <[email protected]>, Andreas Maier/Ge= rmany/IBM@IBMDE,=0A>=A0 =A0 =A0 =A0 =A0 =A0 OpenPegasus Developer mailing l= ist <[email protected]>=0A>Date:=A0=A0=A0 31.07.2014 20:50=0A>Subje= ct:=A0=A0=A0 Avoiding PAM checks Bug 9892=0A>=0A>=0A>=0A>Seems overly compl= icated to me.=0A>The sessionID should be sent by the client with every sing= le packet=0A>transmitted.=0A>If you use a cookie, then the server will have= to request it each time and=0A>cause excess wasted traffic.=0A>It does not= matter what is in the sessionID, because the point is only for=0A>the serv= er to get back what it expects, regardless of what that is, so I=0A>don't s= ee how the DMTF is involved?=0A>Cookies can return whatever you put into th= em, but is not really intended=0A>for session integrity, but maintain conti= nuity between sessions.=0A>A lot of client systems do not allow cookies bec= ause they take up space and=0A>are server intrusion on the client.=0A>Sure = cookies are small, but attacks planting billions of cookies have been=0A>kn= own to happen, once any cookies are allowed.=0A>=0A>Kirk=A0 Augustin=0A>118= 21 NW McNamee Rd=0A>Portland, OR 97231=0A>=0A>=0A>HM: 503-289-4356=0A>=0A>F= rom: Karl Schopmeyer <[email protected]>=0A>To: Jan Safranek <jsafran= [email protected]>; Andreas Maier <[email protected]>;=0A>OpenPegasus Developer = mailing list <[email protected]>=0A>Sent: Thursday, July 31, 2014 1= 0:47 AM=0A>Subject: Re: Avoiding PAM checks Bug 9892=0A>=0A>My real concern= was that the design depended on the cookie header which=0A>without some ex= tension to the DMTF protocol specs meant that OpenPegasus=0A>had a "non-com= pliant" extension as part of its protocol for at least=0A>cim/xml=0A>and th= at should be considered for the other protocols also (wsman,=0A>etc.). It i= s=0A>HTTP compliant but not the DMTF specifications.=0A>=0A>Given that Andy= has agreed that we could propose some part of this to=0A>the DMTF cim/xml= =0A>team as a proposed extension, and Jan's responses below which really=0A= >represent=0A>a fairly simple solution that only passes the temporary ID ba= ck to the=0A>client=0A>in the cookie header (everything else is stored in t= he server including the=0A>timeout information) which the client must retur= n to ask the server to=0A>bypass=0A>PAM I think we are down to a couple of = issues:=0A>=0A>1. Exactly what should be in the sessionID.=0A>2. Use of the= cookie headers to pass this authentication state=0A>information (sessionID= ) versus other=0A>=A0 =A0 means to pass the information.=0A>=0A>=0A>Session= ID=0A>=0A>1. Andy notes that the the exact form of the SessionID is up for= =0A>discussion but that=0A>was based on the SessionID carrying real informa= tion whereas Jan defined=0A>it as=0A>just a random number ID (all real info= rmation is only in the server).=0A>It would=0A>appear that the simple ID pr= oposed is really adequate and that the=0A>server may elect to=0A>test other= information received in WBEM requests containing a cookie (IP=0A>address, = etc.)=0A>to what level of security it desires.=0A>=0A>2.=0A>=0A>Protocol Ba= sis for passing session information between server and client=0A>=0A>It is = clear from the documentation that while there are many recognized=0A>defici= encies throughout=0A>the life of the cookie, it is the dominate mechanism f= or passing any=0A>type of state information.=0A>=0A>My only concern was tha= t we do not want anything that cannot be met by a=0A>conformant WBEM=0A>cli= ent (i.e. Open Pegasus secret sauce).=A0 Thus, if we accept that the=0A>con= cept of the cookie is=0A>the logical way to pass state information like thi= s, then the=0A>significant additional requirement on=0A>the DMTF specificat= ions is that a WBEM client may return a cookie if it=0A>receives a Set-Cook= ie:=0A>response from the WBEM server and that a WBEM server may include a= =0A>Set-Cookie header in=0A>a WBEM response.=0A>=0A>This is a specialized a= nd specific use of the cookie header concept. As=0A>such it would appear:= =0A>=0A>1. The cookie in the WBEM client has a life of a session where the= =0A>session is defined by the server and=0A>=A0 =A0 possibly limited by the= WBEM client.=0A>=A0 =A0 If a Set-Cookie: header is received by the client = it sends the=0A>cookie back to that server with the subsequent=0A>=A0 =A0 o= perations for the same session and can then discard the cookie.=0A>This is = more specific than=0A>=A0 =A0 the general use of cookies in a browser/web s= erver environment.=0A>=A0 =A0 As such, there is no need for the expiration = date option (Expires=3D)=0A>or the other optional components that=0A>=A0 = =A0 are defined in RFC 6265 at least for the patches proposed as the=0A>Peg= asus implementation.=0A>=0A>2. The concept of session is completely by the = server. It creates a=0A>session once it=0A>=A0 =A0 has validated the reques= t, creates the sessionID, times out the=0A>session, and has a way=0A>=A0 = =A0 to tell the client when the session has timed out ( error 401,=0A>Unaut= horized)=0A>=0A>If defined in an extension to the cim/xml specification, th= e requirement=0A>would simply be that:=0A>=0A>=A0 =A0 a. The WBEM Server an= d WBEM client may use the HTTP cookie header=0A>fields as defined in HTTP= =0A>=A0 =A0 =A0 =A0 specifications. Note that the original specification wa= s RFC=0A>2109 which was superceeded by=0A>=A0 =A0 =A0 =A0 2965, which was, = in turn, superceeded by 6265 so we should be=0A>referenceing 6265 I think.= =0A>=A0 =A0 =A0 =A0 This defines the Cookie: and Set-Cookie: header fields= =0A>=0A>b. A WBEM server may receive a WBEM request message that includes a= =0A>cookie header field=0A>=A0 =A0 =A0 =A0 as defined in the HTTP specifica= tions that includes cookies=0A>defined in a previous WBEM=0A>=A0 =A0 =A0 = =A0 response message=0A>=0A>=A0 =A0 c. A Client that receives a WBEM respon= se containing a set-cookie=0A>header should=0A>=A0 =A0 =A0 =A0 return that = cookie in the subsequent requests for the same session.=0A>=0A>=A0 =A0 d. A= Server may include a cookie header in a cim/xml response=0A>containing one= or=0A>=A0 =A0 =A0 =A0 more cookies based on the HTTP specification.=0A>=0A= >In fact the only real changes to the DMTF specification are probably=0A>th= at a WBEM server response=0A>may include a cookie header (set_cookie:) and = if it does, the WBEM=0A>client may include that cookie=0A>in subsequent req= uests.=0A>=0A>Note that the current patch defines the cookie name as "PEGAS= US_SID"=0A>which is an OpenPegasus=0A>defined name and pretty much ties thi= s particular cookieto OpenPegasus.=0A>Since the cookie name is=0A>server ge= nerated and is only to be used to send the cookie back to the=0A>server wit= h the next request=0A>for the same session, the actual name is effectively = meaningless.=0A>=0A>=0A>=0A>=0A>=0A>=0A>On 07/31/2014 02:40 AM, Jan Safrane= k wrote:=0A>> On 07/30/2014 04:34 PM, Andreas Maier wrote:=0A>>> Karl, Jan,= I have discussed the issue with a number of folks, and=0A>>> that helped m= e to better understand how Jan's proposal works.=0A>>>=0A>>> I'd like to ma= ke the following comments, before I leave for vacation=0A>>> (back at home = from 8/16 on, back in the office from 8/25 on):=0A>>>=0A>>> Just to recap t= he overall approach: Upon successful authentication of=0A>>> a CIM request,= if the server supports the new feature, it invents a=0A>>> session ID and = sends that back with the CIM response. If the client=0A>>> supports the new= feature, it uses that session ID on subsequent CIM=0A>>> requests. Upon re= ceipt of a CIM request with such a session ID, the=0A>>> server can decide = whether it trusts the session ID sufficiently at=0A>>> that moment to bypas= s the authentication check.=0A>>>=0A>>> I'm fine with that overall approach= , but I kept the description=0A>>> deliberately high level, because there a= re some considerations and=0A>>> requirements:=0A>>>=0A>>> - It depends ver= y much on the data that makes up the session ID. A=0A>>> suggestion from on= e of our security folks was that the session ID be=0A>>> a hash of (userid,= timestamp, randon number, underlying SSL session=0A>>> ID). It is definite= ly a requirement that the session ID cannot be=0A>>> calculated by an intru= der. For example, just using timestamp and=0A>>> userid would probably be n= ot sufficient. Keep in mind that the code=0A>>> is open source, so the algo= rithm how exactly the hash is calculated=0A>>> will be known, and the secre= t must be in the data, not in the=0A>>> algorithm. Using the underlying SSL= session ID for example ensures=0A>>> that the same SSL session is still in= place. Maybe that is too much=0A>>> of a requirement, but it is something = that needs to be carefully=0A>>> considered.=0A>>>=0A>> Currently, the sess= ion ID is just cryptographically strong* random=0A>> number, nothing else. = Timestamp, source IP address and client user name=0A>> are stored (and chec= ked) in Pegasus memory, but are *not* transmitted in=0A>> the session id.= =0A>>=0A>> *) 15 bytes (120 bits), generated by RAND_bytes() call from=0A>>= openssl/rand.h. I've chose 15 as 'long enough' and divisible by 3, so it= =0A>> can be base64-encoded without padding. It can be longer, it's just on= e=0A>> #define.=0A>>=0A>> I think that adding anything else to the session = ID won't improve=0A>> security in any way, it will just make it more predic= table. We may store=0A>> (and check) something on server, if we want. I wou= ld explicitly avoid=0A>> checking SSL session ID, as the client may use dif= ferent TCP connection=0A>> (and thus SSL session) for subsequent request - = that's very common in=0A>> HTTP world, clients (e.g. pywbem) don't use Keep= -Alive that much.=0A>>=0A>>> - The server must be able to determine the lif= etime of the session=0A>>> ID. The proposed cookie based approach would pro= bably use the cookie=0A>>> lifetime for that, but that could also be done o= therwise. Can cookie=0A>>> lifetimes be modified by a client? That would be= bad. I would have a=0A>>> better feeling if the lifetime was encoded in th= e session ID instead=0A>>> of being a separate piece of clear data. Even if= the session ID is a=0A>>> hash (which cannot be unpacked), the server coul= d remember (in=0A>>> memory) which session IDs it has handed out at any poi= nt in time, and=0A>>> match the session ID with an internal record of it th= at shows the=0A>>> lifetime.=0A>> The cookie lifetime is stored on server, = client cannot influence it in=0A>> any way. As I wrote above, it's not part= of session ID, as it would make=0A>> the ID more predictable.=0A>>=0A>>> -= The server must be allowed to decide at any point that a normally=0A>>> va= lid session ID is nevertheless dismissed, and that a new session ID=0A>>> i= s created. The server can make that determination based upon nearly=0A>>> e= verything, including suspicuous client behavior with otherwise=0A>>> valid = requests. If the server dismisses an incoming session ID, it=0A>>> performs= the normal authentication as if no session ID had been=0A>>> provided by t= he client, and returns a new session ID.=0A>> Well, there is no code for th= at, but if someone implements such=0A>> detection logic, it's just one Hash= Table.remove() call to forget a=0A>> session. which implies that the next r= equest will go through proper=0A>> authentication.=0A>>=0A>>> - As a result= , the client must always use the session ID returned by=0A>>> the last resp= onse, because the server could have recalculated it.=0A>> Sure, that's how = HTTP and my client patches work.=0A>>=0A>>> - how the session ID is transpo= rted between client and server, has a=0A>>> number of options. It would cer= tainly be some HTTP header. I have=0A>>> seen extension headers used for th= at purpose, it does not necessarily=0A>>> have to be a cookie. I find cooki= es generally suspicious, and don't=0A>>> fully understand to what extent HT= TP infrastructure (e.g. proxies)=0A>>> can have a policy to not allow them,= in which case a cookie based=0A>>> approach would be limiting in such envi= ronments.=0A>> Cookie is described as HTTP 1.0 extension in RFC 2109: HTTP = State=0A>> Management Mechanism, released in 1997. It has been revised seve= ral=0A>> times and it is part of any decent HTTP implementation for ages. T= o be=0A>> honest, I haven't looked for any other RFC for session management= over=0A>> HTTP, the cookie is really used everywhere.=0A>>=0A>> RFC 2616 (= HTTP 1.1) says: Unrecognized header fields SHOULD be ignored=0A>> by the re= cipient and MUST be forwarded by transparent proxies.=0A>>=0A>> So, client = who do not support cookies SHOULD survive just with Basic=0A>> authenticati= on in every request, just like now. And proxies MUST forward=0A>> the cooki= e.=0A>>=0A>>> - Obviously, it must be optional to support for both client a= nd=0A>>> server. Just to have it mentioned.=0A>> The server is configurable= .=0A>>=0A>> What benefit it has to turn it off on _client_ side? If a clien= t=0A>> receives a cookie, it indicates that the server supports it. The cli= ent=0A>> just sends it back in subsequent requests. If the server decides t= hat=0A>> the cookie is not enough, the client processed 401 Unauthorized re= sponse=0A>> as usual.=0A>>=0A>>> - One important consideration is whether w= e want it to work with both=0A>>> HTTP and HTTPS, and with all HTTP authent= ication mechanisms. Someone=0A>>> needs to draw the matrix of HTTP/HTTPS wi= th supported authentication=0A>>> mechanisms, and state for which ones the = session ID approach would be=0A>>> supported. That may shape the design sig= nificantly. For example, if=0A>>> we supported it only for HTTPS, the sessi= on ID would not need to be=0A>>> encrypted. If we also wanted to support it= for HTTP, we maybe want to=0A>>> see it encrypted.=0A>> As the session ID = is just a random number, encrypting it on HTTP won't=0A>> help much, especi= ally without proper handshake protocol to exchange=0A>> keys, which you don= 't have on HTTP.=0A>>=0A>> In addition, it looks quite funny that cookie sh= ould be encrypted, while=0A>> Basic authentication (the only one that Pegas= us supports now) sends user=0A>> password unencrypted in a HTTP header.=0A>= >=0A>>=0A>>> - There are sufficient screws and decisions in that whole appr= oach,=0A>>> so that we cannot assume this is just an OpenPegasus addition.= =0A>>> DSP0200 documents all standard HTTP headers that play a role in=0A>>= > CIM-XML, and it would need to describe this new ability as well. Karl=0A>= >> and I are in the CIM-XML WG, and it should not take very long, once=0A>>= > we have agreed upon the details on how to do it.=0A>>>=0A>>> To me, the o= pen points are: - how to calculate the session ID. This=0A>>> could be a re= commendation for servers to keep them secure, because it=0A>>> is opaque fo= r clients. - which mechanism to use to transport the=0A>>> session ID betwe= en client and server.=0A>> I hope I explained my design and implementation = above, feel free to ask=0A>> anything.=0A>>=0A>> Jan=0A>>=0A>=0A>=0A>=0A>= =0A>=0A> ---1593584224-1421366921-1409013594=:3350 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo= nt-size:10pt"><div><span>Andreas, <br></span></div><div style=3D"color: rgb= (0, 0, 0); font-size: 13.3333px; font-family: HelveticaNeue,Helvetica Neue,= Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; fo= nt-style: normal;"><br></div><div style=3D"color: rgb(0, 0, 0); font-size: = 13.3333px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida= Grande,sans-serif; background-color: transparent; font-style: normal;">It = sounds like your methodology will work fine, but as you described it, I wou= ld normally call that a "session token".</div><div style=3D"color: rgb(0, 0= , 0); font-size: 13.3333px; font-family: HelveticaNeue,Helvetica Neue,Helve= tica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-st= yle: normal;">The way I use the word "cookie" as normally client side, file storage for the server, and accessed only by the server, not the client.</= div><div style=3D"color: rgb(0, 0, 0); font-size: 13.3333px; font-family: H= elveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; backg= round-color: transparent; font-style: normal;">What you want I think is whe= re the server hands it to the client once, who then hands it back to the se= rver with every subsequent transaction of the session.<br><span></span></di= v><div style=3D"color: rgb(0, 0, 0); font-size: 13.3333px; font-family: Hel= veticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; backgro= und-color: transparent; font-style: normal;"><span><br></span></div><div>&n= bsp;</div><div>Kirk Augustin<br>11821 NW McNamee Rd<br>Portland, OR 97231</= div><div><br><br></div><div>HM: 503-289-4356</div><div><br></div> <div></di= v><blockquote style=3D"border-left: 2px solid rgb(16, 16, 255); margin-left= : 5px; margin-top: 5px; padding-left: 5px;"> <div style=3D"font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif= ; font-size: 10pt;"> <div style=3D"font-family: HelveticaNeue, Helvetica Ne= ue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;"> <div di= r=3D"ltr"> <hr size=3D"1"> <font face=3D"Arial" size=3D"2"> <b><span style= =3D"font-weight:bold;">From:</span></b> Andreas Maier <[email protected]= ><br> <b><span style=3D"font-weight: bold;">To:</span></b> Kirk Augustin= <[email protected]> <br><b><span style=3D"font-weight: bold;">= Cc:</span></b> Karl Schopmeyer <[email protected]>; Jan Safrane= k <[email protected]>; OpenPegasus Developer mailing list <pegas= [email protected]> <br> <b><span style=3D"font-weight: bold;">Sent:</= span></b> Monday, August 25, 2014 6:13 AM<br> <b><span style=3D"font-weight= : bold;">Subject:</span></b> Avoiding PAM checks Bug 9892<br> </font> </div= > <div class=3D"y_msg_container"><br><br>Kirk,<br>On your statement:<br>>= ; If you use a cookie, then the server will have to request it each time<br>and cause exc= ess wasted traffic.<br>I was not aware that in order to use cookies, the se= rver has to turn around<br>and ask the client. The proposed approach would = cause the server to include<br>the cookie in the response header of the res= ponse it sends anyway, and the<br>client would include the so received cook= ie in the request header of any<br>subsequent requests it sends anyway. Tha= t would not incur any additional<br>traffic.<br>Are you saying that the pro= posed approach cannot work that way?<br><br>On DMTF involvement:<br>DMTF wo= uld be involved to document the concept as an optional feature in<br>DSP020= 0, as it does already with a number of other HTTP headers (both<br>standard= and extension). Reason being that DMTF wants to foster<br>interoperability= across *multiple* implementations, instead of just<br>allowing a particula= r implementation between its client and server to do<br>something that is allowed as per the HTTP standard, but otherwise not known<br>outsi= de of that particular implementation. Now that is Andy's view on how<br>DMT= F operates, but it is with my DMTF hat (particularly the CIM-XML hat)<br>on= .... Plus, IBM uses CIM clients and servers form multiple<br>implementation= s, so we have also a company interest for interoperability.<br><br>Andy<br>= <br>Andreas Maier<br>IBM Senior Technical Staff Member, Systems Management = Architecture & Design<br>IBM Research & Development Laboratory Boeb= lingen, Germany<br><a ymailto=3D"mailto:[email protected]" href=3D"mailto:m= [email protected]">[email protected]</a>, +49-7031-16-3654<br>______________= __________________________________________________________<br>IBM Deutschla= nd Research & Development GmbH<br>Vorsitzende des Aufsichtsrats: Martin= a Koederitz<br>Geschaeftsfuehrung: Dirk Wittkopp<br>Sitz der Gesellschaft: = Boeblingen<br>Registergericht: Amtsgericht Stuttgart, HRB 243294<br><br>----- Forwarded by Andreas Maier/Germany/IBM on 25.08.2014 1= 4:19 -----<br><br>From: Kirk Augustin <<a ymailto=3D"m= ailto:[email protected]" href=3D"mailto:[email protected]">kirk= [email protected]</a>><br>To: Karl Schopmeyer <<a= ymailto=3D"mailto:[email protected]" href=3D"mailto:k.schopmeyer@swb= ell.net">[email protected]</a>>, Jan Safranek<br> &nb= sp; <<a ymailto=3D"mailto:[email protected]" href= =3D"mailto:[email protected]">[email protected]</a>>, Andreas Maier/= Germany/<a ymailto=3D"mailto:IBM@IBMDE" href=3D"mailto:IBM@IBMDE">IBM@IBMDE= </a>,<br> OpenPegasus Developer ma= iling list <<a ymailto=3D"mailto:[email protected]" href=3D"mail= to:[email protected]">[email protected]</a>><br>Date:&nb= sp; 31.07.2014 20:50<br>Subject: Avoiding PAM= checks Bug 9892<br><br><br><br>Seems overly complicated to me.<br>The sessionID shoul= d be sent by the client with every single packet<br>transmitted.<br>If you = use a cookie, then the server will have to request it each time and<br>caus= e excess wasted traffic.<br>It does not matter what is in the sessionID, be= cause the point is only for<br>the server to get back what it expects, rega= rdless of what that is, so I<br>don't see how the DMTF is involved?<br>Cook= ies can return whatever you put into them, but is not really intended<br>fo= r session integrity, but maintain continuity between sessions.<br>A lot of = client systems do not allow cookies because they take up space and<br>are s= erver intrusion on the client.<br>Sure cookies are small, but attacks plant= ing billions of cookies have been<br>known to happen, once any cookies are = allowed.<br><br>Kirk Augustin<br>11821 NW McNamee Rd<br>Portland, OR = 97231<br><br><br>HM: 503-289-4356<br><br>From: Karl Schopmeyer <<a ymailto=3D"mailto:[email protected]" href=3D"mailto:k.schopme= [email protected]">[email protected]</a>><br>To: Jan Safranek <<a = ymailto=3D"mailto:[email protected]" href=3D"mailto:[email protected]">= [email protected]</a>>; Andreas Maier <<a ymailto=3D"mailto:MAIERA@= de.ibm.com" href=3D"mailto:[email protected]">[email protected]</a>>;<br= >OpenPegasus Developer mailing list <<a ymailto=3D"mailto:pegasus-l@open= pegasus.org" href=3D"mailto:[email protected]">pegasus-l@openpegasu= s.org</a>><br>Sent: Thursday, July 31, 2014 10:47 AM<br>Subject: Re: Avo= iding PAM checks Bug 9892<br><br>My real concern was that the design depend= ed on the cookie header which<br>without some extension to the DMTF protoco= l specs meant that OpenPegasus<br>had a "non-compliant" extension as part o= f its protocol for at least<br>cim/xml<br>and that should be considered for= the other protocols also (wsman,<br>etc.). It is<br>HTTP compliant but not= the DMTF specifications.<br><br>Given that Andy has agreed that we could propose so= me part of this to<br>the DMTF cim/xml<br>team as a proposed extension, and= Jan's responses below which really<br>represent<br>a fairly simple solutio= n that only passes the temporary ID back to the<br>client<br>in the cookie = header (everything else is stored in the server including the<br>timeout in= formation) which the client must return to ask the server to<br>bypass<br>P= AM I think we are down to a couple of issues:<br><br>1. Exactly what should= be in the sessionID.<br>2. Use of the cookie headers to pass this authenti= cation state<br>information (sessionID) versus other<br> means= to pass the information.<br><br><br>SessionID<br><br>1. Andy notes that th= e the exact form of the SessionID is up for<br>discussion but that<br>was b= ased on the SessionID carrying real information whereas Jan defined<br>it a= s<br>just a random number ID (all real information is only in the server).<br>It would<br>appear that the simple ID proposed is really adequ= ate and that the<br>server may elect to<br>test other information received = in WBEM requests containing a cookie (IP<br>address, etc.)<br>to what level= of security it desires.<br><br>2.<br><br>Protocol Basis for passing sessio= n information between server and client<br><br>It is clear from the documen= tation that while there are many recognized<br>deficiencies throughout<br>t= he life of the cookie, it is the dominate mechanism for passing any<br>type= of state information.<br><br>My only concern was that we do not want anyth= ing that cannot be met by a<br>conformant WBEM<br>client (i.e. Open Pegasus= secret sauce). Thus, if we accept that the<br>concept of the cookie = is<br>the logical way to pass state information like this, then the<br>sign= ificant additional requirement on<br>the DMTF specifications is that a WBEM= client may return a cookie if it<br>receives a Set-Cookie:<br>response from the WBEM server and that a WBEM server may in= clude a<br>Set-Cookie header in<br>a WBEM response.<br><br>This is a specia= lized and specific use of the cookie header concept. As<br>such it would ap= pear:<br><br>1. The cookie in the WBEM client has a life of a session where= the<br>session is defined by the server and<br> possibly limi= ted by the WBEM client.<br> If a Set-Cookie: header is receive= d by the client it sends the<br>cookie back to that server with the subsequ= ent<br> operations for the same session and can then discard t= he cookie.<br>This is more specific than<br> the general use o= f cookies in a browser/web server environment.<br> As such, th= ere is no need for the expiration date option (Expires=3D)<br>or the other = optional components that<br> are defined in RFC 6265 at least = for the patches proposed as the<br>Pegasus implementation.<br><br>2. The concept of session is completely by the server. It creates a<br>sessio= n once it<br> has validated the request, creates the sessionID= , times out the<br>session, and has a way<br> to tell the clie= nt when the session has timed out ( error 401,<br>Unauthorized)<br><br>If d= efined in an extension to the cim/xml specification, the requirement<br>wou= ld simply be that:<br><br> a. The WBEM Server and WBEM client = may use the HTTP cookie header<br>fields as defined in HTTP<br>  = ; specifications. Note that the original specification was RF= C<br>2109 which was superceeded by<br> 2965, whi= ch was, in turn, superceeded by 6265 so we should be<br>referenceing 6265 I= think.<br> This defines the Cookie: and Set-Coo= kie: header fields<br><br>b. A WBEM server may receive a WBEM request messa= ge that includes a<br>cookie header field<br> as defined in the HTTP specifications that includes cookies<br>defi= ned in a previous WBEM<br> response message<br><= br> c. A Client that receives a WBEM response containing a set= -cookie<br>header should<br> return that cookie = in the subsequent requests for the same session.<br><br> d. A = Server may include a cookie header in a cim/xml response<br>containing one = or<br> more cookies based on the HTTP specificat= ion.<br><br>In fact the only real changes to the DMTF specification are pro= bably<br>that a WBEM server response<br>may include a cookie header (set_co= okie:) and if it does, the WBEM<br>client may include that cookie<br>in sub= sequent requests.<br><br>Note that the current patch defines the cookie nam= e as "PEGASUS_SID"<br>which is an OpenPegasus<br>defined name and pretty mu= ch ties this particular cookieto OpenPegasus.<br>Since the cookie name is<br>server generated and is only to be used to send the cookie back= to the<br>server with the next request<br>for the same session, the actual= name is effectively meaningless.<br><br><br><br><br><br><br>On 07/31/2014 = 02:40 AM, Jan Safranek wrote:<br>> On 07/30/2014 04:34 PM, Andreas Maier= wrote:<br>>> Karl, Jan, I have discussed the issue with a number of = folks, and<br>>> that helped me to better understand how Jan's propos= al works.<br>>><br>>> I'd like to make the following comments, = before I leave for vacation<br>>> (back at home from 8/16 on, back in= the office from 8/25 on):<br>>><br>>> Just to recap the overal= l approach: Upon successful authentication of<br>>> a CIM request, if= the server supports the new feature, it invents a<br>>> session ID a= nd sends that back with the CIM response. If the client<br>>> support= s the new feature, it uses that session ID on subsequent CIM<br>>> requests. Upon receipt of a CIM request with such a sessio= n ID, the<br>>> server can decide whether it trusts the session ID su= fficiently at<br>>> that moment to bypass the authentication check.<b= r>>><br>>> I'm fine with that overall approach, but I kept the = description<br>>> deliberately high level, because there are some con= siderations and<br>>> requirements:<br>>><br>>> - It depe= nds very much on the data that makes up the session ID. A<br>>> sugge= stion from one of our security folks was that the session ID be<br>>>= a hash of (userid, timestamp, randon number, underlying SSL session<br>>= ;> ID). It is definitely a requirement that the session ID cannot be<br>= >> calculated by an intruder. For example, just using timestamp and<b= r>>> userid would probably be not sufficient. Keep in mind that the c= ode<br>>> is open source, so the algorithm how exactly the hash is calculated<br>>> will be known, and the secret must be in th= e data, not in the<br>>> algorithm. Using the underlying SSL session = ID for example ensures<br>>> that the same SSL session is still in pl= ace. Maybe that is too much<br>>> of a requirement, but it is somethi= ng that needs to be carefully<br>>> considered.<br>>><br>> C= urrently, the session ID is just cryptographically strong* random<br>> n= umber, nothing else. Timestamp, source IP address and client user name<br>&= gt; are stored (and checked) in Pegasus memory, but are *not* transmitted i= n<br>> the session id.<br>><br>> *) 15 bytes (120 bits), generated= by RAND_bytes() call from<br>> openssl/rand.h. I've chose 15 as 'long e= nough' and divisible by 3, so it<br>> can be base64-encoded without padd= ing. It can be longer, it's just one<br>> #define.<br>><br>> I thi= nk that adding anything else to the session ID won't improve<br>> security in any way, it will just make it more predictable. We may store<b= r>> (and check) something on server, if we want. I would explicitly avoi= d<br>> checking SSL session ID, as the client may use different TCP conn= ection<br>> (and thus SSL session) for subsequent request - that's very = common in<br>> HTTP world, clients (e.g. pywbem) don't use Keep-Alive th= at much.<br>><br>>> - The server must be able to determine the lif= etime of the session<br>>> ID. The proposed cookie based approach wou= ld probably use the cookie<br>>> lifetime for that, but that could al= so be done otherwise. Can cookie<br>>> lifetimes be modified by a cli= ent? That would be bad. I would have a<br>>> better feeling if the li= fetime was encoded in the session ID instead<br>>> of being a separat= e piece of clear data. Even if the session ID is a<br>>> hash (which = cannot be unpacked), the server could remember (in<br>>> memory) which session IDs it has handed out at any point in time, and<br>&= gt;> match the session ID with an internal record of it that shows the<b= r>>> lifetime.<br>> The cookie lifetime is stored on server, clien= t cannot influence it in<br>> any way. As I wrote above, it's not part o= f session ID, as it would make<br>> the ID more predictable.<br>><br>= >> - The server must be allowed to decide at any point that a normall= y<br>>> valid session ID is nevertheless dismissed, and that a new se= ssion ID<br>>> is created. The server can make that determination bas= ed upon nearly<br>>> everything, including suspicuous client behavior= with otherwise<br>>> valid requests. If the server dismisses an inco= ming session ID, it<br>>> performs the normal authentication as if no= session ID had been<br>>> provided by the client, and returns a new = session ID.<br>> Well, there is no code for that, but if someone implements such<br>> detection logic, it's just one HashTable.remove() = call to forget a<br>> session. which implies that the next request will = go through proper<br>> authentication.<br>><br>>> - As a result= , the client must always use the session ID returned by<br>>> the las= t response, because the server could have recalculated it.<br>> Sure, th= at's how HTTP and my client patches work.<br>><br>>> - how the ses= sion ID is transported between client and server, has a<br>>> number = of options. It would certainly be some HTTP header. I have<br>>> seen= extension headers used for that purpose, it does not necessarily<br>>&g= t; have to be a cookie. I find cookies generally suspicious, and don't<br>&= gt;> fully understand to what extent HTTP infrastructure (e.g. proxies)<= br>>> can have a policy to not allow them, in which case a cookie bas= ed<br>>> approach would be limiting in such environments.<br>> Cookie is described as HTTP 1.0 extension in RFC 210= 9: HTTP State<br>> Management Mechanism, released in 1997. It has been r= evised several<br>> times and it is part of any decent HTTP implementati= on for ages. To be<br>> honest, I haven't looked for any other RFC for s= ession management over<br>> HTTP, the cookie is really used everywhere.<= br>><br>> RFC 2616 (HTTP 1.1) says: Unrecognized header fields SHOULD= be ignored<br>> by the recipient and MUST be forwarded by transparent p= roxies.<br>><br>> So, client who do not support cookies SHOULD surviv= e just with Basic<br>> authentication in every request, just like now. A= nd proxies MUST forward<br>> the cookie.<br>><br>>> - Obviously= , it must be optional to support for both client and<br>>> server. Ju= st to have it mentioned.<br>> The server is configurable.<br>><br>>= ; What benefit it has to turn it off on _client_ side? If a client<br>> receives a cookie, it indicates that the server supports it= . The client<br>> just sends it back in subsequent requests. If the serv= er decides that<br>> the cookie is not enough, the client processed 401 = Unauthorized response<br>> as usual.<br>><br>>> - One important= consideration is whether we want it to work with both<br>>> HTTP and= HTTPS, and with all HTTP authentication mechanisms. Someone<br>>> ne= eds to draw the matrix of HTTP/HTTPS with supported authentication<br>>&= gt; mechanisms, and state for which ones the session ID approach would be<b= r>>> supported. That may shape the design significantly. For example,= if<br>>> we supported it only for HTTPS, the session ID would not ne= ed to be<br>>> encrypted. If we also wanted to support it for HTTP, w= e maybe want to<br>>> see it encrypted.<br>> As the session ID is = just a random number, encrypting it on HTTP won't<br>> help much, especially without proper handshake protocol to exchange<br>> keys, whi= ch you don't have on HTTP.<br>><br>> In addition, it looks quite funn= y that cookie should be encrypted, while<br>> Basic authentication (the = only one that Pegasus supports now) sends user<br>> password unencrypted= in a HTTP header.<br>><br>><br>>> - There are sufficient screw= s and decisions in that whole approach,<br>>> so that we cannot assum= e this is just an OpenPegasus addition.<br>>> DSP0200 documents all s= tandard HTTP headers that play a role in<br>>> CIM-XML, and it would = need to describe this new ability as well. Karl<br>>> and I are in th= e CIM-XML WG, and it should not take very long, once<br>>> we have ag= reed upon the details on how to do it.<br>>><br>>> To me, the o= pen points are: - how to calculate the session ID. This<br>>> could b= e a recommendation for servers to keep them secure, because it<br>>> is opaque for clients. - which mechanism to use to transpor= t the<br>>> session ID between client and server.<br>> I hope I ex= plained my design and implementation above, feel free to ask<br>> anythi= ng.<br>><br>> Jan<br>><br><br><br><br><br><br></div> </div> </div>= </blockquote><div></div> </div></body></html> ---1593584224-1421366921-1409013594=:3350--