Re: Avoiding PAM checks Bug 9892
Kirk Augustin <[email protected]> Thu, 31 Jul 2014 11:50:08 -0700
| Newsgroups | gmane.network.open-pegasus.general |
|---|---|
| Message-ID | <[email protected]> |
--61789334-1381223267-1406832608=:61783 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Seems overly complicated to me.=0AThe sessionID should be sent by the clien= t with every single packet transmitted.=0AIf you use a cookie, then the ser= ver will have to request it each time and cause excess wasted traffic.=0AIt= does not matter what is in the sessionID, because the point is only for th= e server to get back what it expects, regardless of what that is, so I don'= t see how the DMTF is involved?=0ACookies can return whatever you put into = them, but is not really intended for session integrity, but maintain contin= uity between sessions.=0AA lot of client systems do not allow cookies becau= se they take up space and are server intrusion on the client.=0ASure cookie= s are small, but attacks planting billions of cookies have been known to ha= ppen, once any cookies are allowed.=0A=0A=A0=0AKirk=A0 Augustin=0A11821 NW = McNamee Rd=0APortland, OR 97231=0A=0A=0AHM: 503-289-4356=0A=0A=0A>_________= _______________________=0A> From: Karl Schopmeyer <[email protected]>= =0A>To: Jan Safranek <[email protected]>; Andreas Maier <[email protected]= m>; OpenPegasus Developer mailing list <[email protected]> =0A>Sent= : Thursday, July 31, 2014 10:47 AM=0A>Subject: Re: Avoiding PAM checks Bug = 9892=0A> =0A>=0A>My real concern was that the design depended on the cookie= header which=0A>without some extension to the DMTF protocol specs meant th= at OpenPegasus=0A>had a "non-compliant" extension as part of its protocol f= or at least cim/xml=0A>and that should be considered for the other protocol= s also (wsman, =0A>etc.). It is=0A>HTTP compliant but not the DMTF specific= ations.=0A>=0A>Given that Andy has agreed that we could propose some part o= f this to =0A>the DMTF cim/xml=0A>team as a proposed extension, and Jan's r= esponses below which really =0A>represent=0A>a fairly simple solution that = only passes the temporary ID back to the =0A>client=0A>in the cookie header= (everything else is stored in the server including the=0A>timeout informat= ion) which the client must return 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 i= n the sessionID.=0A>2. Use of the cookie headers to pass this authenticatio= n state =0A>information (sessionID) versus other=0A>=A0 =A0 means to pass = the information.=0A>=0A>=0A>SessionID=0A>=0A>1. Andy notes that the the exa= ct form of the SessionID is up for =0A>discussion but that=0A>was based on = the SessionID carrying real information whereas Jan defined =0A>it as=0A>ju= st a random number ID (all real information is only in the server).=A0 =0A>= It would=0A>appear that the simple ID proposed is really adequate and that = the =0A>server may elect to=0A>test other information received in WBEM requ= ests containing a cookie (IP =0A>address, etc.)=0A>to what level of securit= y it desires.=0A>=0A>2.=0A>=0A>Protocol Basis for passing session informati= on between server and client=0A>=0A>It is clear from the documentation that= while there are many recognized =0A>deficiencies throughout=0A>the life of= the cookie, it is the dominate mechanism for passing any =0A>type of state= information.=0A>=0A>My only concern was that we do not want anything that = cannot be met by a =0A>conformant WBEM=0A>client (i.e. Open Pegasus secret = sauce).=A0 Thus, if we accept that the =0A>concept of the cookie is=0A>the = logical way to pass state information like this, then the =0A>significant a= dditional requirement on=0A>the DMTF specifications is that a WBEM client m= ay return a cookie if it =0A>receives a Set-Cookie:=0A>response from the WB= EM server and that a WBEM server may include a =0A>Set-Cookie header in=0A>= a WBEM response.=0A>=0A>This is a specialized and specific use of the cooki= e 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 bac= k to that server with the subsequent=0A>=A0 =A0 operations for the same se= ssion and can then discard the cookie.=A0 =0A>This is more specific than=0A= >=A0 =A0 the general use of cookies in a browser/web server environment.= =0A>=A0 =A0 As such, there is no need for the expiration date option (Expi= res=3D) =0A>or the other optional components that=0A>=A0 =A0 are defined i= n RFC 6265 at least for the patches proposed as the =0A>Pegasus implementat= ion.=0A>=0A>2. The concept of session is completely by the server. It creat= es a =0A>session once it=0A>=A0 =A0 has validated the request, creates the= sessionID, times out the =0A>session, and has a way=0A>=A0 =A0 to tell th= e client when the session has timed out ( error 401, =0A>Unauthorized)=0A>= =0A>If defined in an extension to the cim/xml specification, the requiremen= t =0A>would simply be that:=0A>=0A>=A0 =A0 a. The WBEM Server and WBEM cli= ent may use the HTTP cookie header =0A>fields as defined in HTTP=0A>=A0 =A0= =A0 =A0 specifications. Note that the original specification was 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>coo= kie header field=0A>=A0 =A0 =A0 =A0 as defined in the HTTP specifications = that includes cookies =0A>defined in a previous WBEM=0A>=A0 =A0 =A0 =A0 re= sponse message=0A>=0A>=A0 =A0 c. A Client that receives a WBEM response co= ntaining a set-cookie =0A>header should=0A>=A0 =A0 =A0 =A0 return that coo= kie in the subsequent requests for the same session.=0A>=0A>=A0 =A0 d. A S= erver 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>t= hat 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 r= equests.=0A>=0A>Note that the current patch defines the cookie name as "PEG= ASUS_SID" =0A>which is an OpenPegasus=0A>defined name and pretty much ties = this particular cookieto OpenPegasus.=A0 =0A>Since the cookie name is=0A>se= rver generated and is only to be used to send the cookie back to the =0A>se= rver with the next request=0A>for the same session, the actual name is effe= ctively meaningless.=0A>=0A>=0A>=0A>=0A>=0A>=0A>=0A>=0A>On 07/31/2014 02:40= AM, Jan Safranek 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 me to better understand how Jan's proposal works.=0A>>>=0A>= >> I'd like to make 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 the 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 receipt of a CIM request with such a session ID, the=0A>>> s= erver can decide whether it trusts the session ID sufficiently at=0A>>> tha= t moment to bypass the authentication check.=0A>>>=0A>>> I'm fine with that= overall approach, but I kept the description=0A>>> deliberately high level= , because there are some considerations and=0A>>> requirements:=0A>>>=0A>>>= - It depends very much on the data that makes up the session ID. A=0A>>> s= uggestion from one 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 definitely a requirement that the session ID cannot be=0A>>> calcu= lated by an intruder. For example, just using timestamp and=0A>>> userid wo= uld probably be not sufficient. Keep in mind that the code=0A>>> is open so= urce, so the algorithm how exactly the hash is calculated=0A>>> will be kno= wn, and the secret must be in the data, not in the=0A>>> algorithm. Using t= he underlying SSL session ID for example ensures=0A>>> that the same SSL se= ssion 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>> Cu= rrently, the session ID is just cryptographically strong* random=0A>> numbe= r, nothing else. Timestamp, source IP address and client user name=0A>> are= stored (and checked) 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 divisibl= e by 3, so it=0A>> can be base64-encoded without padding. It can be longer,= it's just one=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 i= t more predictable. We may store=0A>> (and check) something on server, if w= e want. I would explicitly avoid=0A>> checking SSL session ID, as the clien= t may use different TCP connection=0A>> (and thus SSL session) for subseque= nt request - that's very common in=0A>> HTTP world, clients (e.g. pywbem) d= on't use Keep-Alive that much.=0A>>=0A>>> - The server must be able to dete= rmine the lifetime of the session=0A>>> ID. The proposed cookie based appro= ach would probably use the cookie=0A>>> lifetime for that, but that could a= lso be done otherwise. 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 the 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), th= e server could remember (in=0A>>> memory) which session IDs it has handed o= ut at any point in time, and=0A>>> match the session ID with an internal re= cord of it that shows the=0A>>> lifetime.=0A>> The cookie lifetime is store= d 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 norm= ally=0A>>> valid session ID is nevertheless dismissed, and that a new sessi= on ID=0A>>> is created. The server can make that determination based upon n= early=0A>>> everything, 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 the client, and returns a new session ID.=0A>> Well, there is= no code for that, but if someone implements such=0A>> detection logic, it'= s just one HashTable.remove() call to forget a=0A>> session. which implies = that the next request will go through proper=0A>> authentication.=0A>>=0A>>= > - As a result, the client must always use the session ID returned by=0A>>= > the last response, because the server could have recalculated it.=0A>> Su= re, that's how HTTP and my client patches work.=0A>>=0A>>> - how the sessio= n ID is transported between client and server, has a=0A>>> number of option= s. It would certainly be some HTTP header. I have=0A>>> seen extension head= ers used for that purpose, it does not necessarily=0A>>> have to be a cooki= e. I find cookies generally suspicious, and don't=0A>>> fully understand to= what extent HTTP infrastructure (e.g. proxies)=0A>>> can have a policy to = not allow them, in which case a cookie based=0A>>> approach would be limiti= ng in such environments.=0A>> Cookie is described as HTTP 1.0 extension in = RFC 2109: HTTP State=0A>> Management Mechanism, released in 1997. It has be= en revised several=0A>> times and it is part of any decent HTTP implementat= ion for ages. To be=0A>> honest, I haven't looked for any other RFC for ses= sion management over=0A>> HTTP, the cookie is really used everywhere.=0A>>= =0A>> RFC 2616 (HTTP 1.1) says: Unrecognized header fields SHOULD be ignore= d=0A>> by the recipient and MUST be forwarded by transparent proxies.=0A>>= =0A>> So, client who do not support cookies SHOULD survive just with Basic= =0A>> authentication in every request, just like now. And proxies MUST forw= ard=0A>> the cookie.=0A>>=0A>>> - Obviously, it must be optional to support= for both client and=0A>>> server. Just to have it mentioned.=0A>> The serv= er is configurable.=0A>>=0A>> What benefit it has to turn it off on _client= _ side? If a client=0A>> receives a cookie, it indicates that the server su= pports it. The client=0A>> just sends it back in subsequent requests. If th= e server decides that=0A>> the cookie is not enough, the client processed 4= 01 Unauthorized response=0A>> as usual.=0A>>=0A>>> - One important consider= ation is whether we want it to work with both=0A>>> HTTP and HTTPS, and wit= h all HTTP authentication mechanisms. Someone=0A>>> needs to draw the matri= x of HTTP/HTTPS with supported authentication=0A>>> mechanisms, and state f= or which ones the session ID approach would be=0A>>> supported. That may sh= ape the design significantly. For example, if=0A>>> we supported it only fo= r HTTPS, the session ID would not need to be=0A>>> encrypted. If we also wa= nted 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, especially without proper handshake protocol to exchange=0A>> k= eys, which you don't have on HTTP.=0A>>=0A>> In addition, it looks quite fu= nny that cookie should be encrypted, while=0A>> Basic authentication (the o= nly one that Pegasus supports now) sends user=0A>> password unencrypted in = a HTTP header.=0A>>=0A>>=0A>>> - There are sufficient screws and decisions = in that whole approach,=0A>>> so that we cannot assume this is just an Open= Pegasus addition.=0A>>> DSP0200 documents all standard HTTP headers that pl= ay 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 ver= y long, once=0A>>> we have agreed upon the details on how to do it.=0A>>>= =0A>>> To me, the open points are: - how to calculate the session ID. This= =0A>>> could be a recommendation for servers to keep them secure, because i= t=0A>>> is opaque for clients. - which mechanism to use to transport the=0A= >>> session ID between 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> --61789334-1381223267-1406832608=:61783 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>Seems overly complicated to me.</span></div><div s= tyle=3D"color: rgb(0, 0, 0); font-size: 13.3333px; font-family: HelveticaNe= ue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-colo= r: transparent; font-style: normal;"><span>The sessionID should be sent by = the client with every single packet transmitted.</span></div><div style=3D"= color: rgb(0, 0, 0); font-size: 13.3333px; font-family: HelveticaNeue,Helve= tica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: trans= parent; font-style: normal;"><span>If you use a cookie, then the server wil= l have to request it each time and cause excess wasted traffic.</span></div= ><div style=3D"color: rgb(0, 0, 0); font-size: 13.3333px; font-family: Helv= eticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><span>It does not matt= er what is in the sessionID, because the point is only for the server to ge= t back what it expects, regardless of what that is, so I don't see how the = DMTF is involved?</span></div><div style=3D"color: rgb(0, 0, 0); font-size:= 13.3333px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucid= a Grande,sans-serif; background-color: transparent; font-style: normal;"><s= pan>Cookies can return whatever you put into them, but is not really intend= ed for session integrity, but maintain continuity between sessions.</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; back= ground-color: transparent; font-style: normal;"><span>A lot of client syste= ms do not allow cookies because they take up space and are server intrusion= on the client.</span></div><div style=3D"color: rgb(0, 0, 0); font-size: 13.3333px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucid= a Grande,sans-serif; background-color: transparent; font-style: normal;"><s= pan>Sure cookies are small, but attacks planting billions of cookies have b= een known to happen, once any cookies are allowed.<br></span></div><div>&nb= sp;</div><div>Kirk Augustin<br>11821 NW McNamee Rd<br>Portland, OR 97= 231</div><div><br><br></div><div>HM: 503-289-4356</div><div><br></div> <div= ></div><blockquote style=3D"border-left: 2px solid rgb(16, 16, 255); margin= -left: 5px; margin-top: 5px; padding-left: 5px;"> <div style=3D"font-famil= y: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-ser= if; font-size: 10pt;"> <div style=3D"font-family: HelveticaNeue, Helvetica = Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;"> <div = dir=3D"ltr"> <hr size=3D"1"> <font face=3D"Arial" size=3D"2"> <b><span sty= le=3D"font-weight:bold;">From:</span></b> Karl Schopmeyer <[email protected]><br> <b><span style=3D"font-weight: bold;">= To:</span></b> Jan Safranek <[email protected]>; Andreas Maier <= [email protected]>; OpenPegasus Developer mailing list <pegasus-l@ope= npegasus.org> <br> <b><span style=3D"font-weight: bold;">Sent:</span></b= > Thursday, July 31, 2014 10:47 AM<br> <b><span style=3D"font-weight: bold;= ">Subject:</span></b> Re: Avoiding PAM checks Bug 9892<br> </font> </div> <= div class=3D"y_msg_container"><br>My real concern was that the design depen= ded on the cookie header which<br clear=3D"none">without some extension to = the DMTF protocol specs meant that OpenPegasus<br clear=3D"none">had a "non= -compliant" extension as part of its protocol for at least cim/xml<br clear= =3D"none">and that should be considered for the other protocols also (wsman= , <br clear=3D"none">etc.). It is<br clear=3D"none">HTTP compliant but not = the DMTF specifications.<br clear=3D"none"><br clear=3D"none">Given that An= dy has agreed that we could propose some part of this to <br clear=3D"none">the DMTF cim= /xml<br clear=3D"none">team as a proposed extension, and Jan's responses be= low which really <br clear=3D"none">represent<br clear=3D"none">a fairly si= mple solution that only passes the temporary ID back to the <br clear=3D"no= ne">client<br clear=3D"none">in the cookie header (everything else is store= d in the server including the<br clear=3D"none">timeout information) which = the client must return to ask the server to <br clear=3D"none">bypass<br cl= ear=3D"none">PAM I think we are down to a couple of issues:<br clear=3D"non= e"><br clear=3D"none">1. Exactly what should be in the sessionID.<br clear= =3D"none">2. Use of the cookie headers to pass this authentication state <b= r clear=3D"none">information (sessionID) versus other<br clear=3D"none">&nb= sp; means to pass the information.<br clear=3D"none"><br clear=3D"n= one"><br clear=3D"none">SessionID<br clear=3D"none"><br clear=3D"none">1. A= ndy notes that the the exact form of the SessionID is up for <br clear=3D"none">discussion but that<br = clear=3D"none">was based on the SessionID carrying real information whereas= Jan defined <br clear=3D"none">it as<br clear=3D"none">just a random numbe= r ID (all real information is only in the server). <br clear=3D"none"= >It would<br clear=3D"none">appear that the simple ID proposed is really ad= equate and that the <br clear=3D"none">server may elect to<br clear=3D"none= ">test other information received in WBEM requests containing a cookie (IP = <br clear=3D"none">address, etc.)<br clear=3D"none">to what level of securi= ty it desires.<br clear=3D"none"><br clear=3D"none">2.<br clear=3D"none"><b= r clear=3D"none">Protocol Basis for passing session information between ser= ver and client<br clear=3D"none"><br clear=3D"none">It is clear from the do= cumentation that while there are many recognized <br clear=3D"none">deficie= ncies throughout<br clear=3D"none">the life of the cookie, it is the domina= te mechanism for passing any <br clear=3D"none">type of state information.<br clear=3D"none"><br clear= =3D"none">My only concern was that we do not want anything that cannot be m= et by a <br clear=3D"none">conformant WBEM<br clear=3D"none">client (i.e. O= pen Pegasus secret sauce). Thus, if we accept that the <br clear=3D"n= one">concept of the cookie is<br clear=3D"none">the logical way to pass sta= te information like this, then the <br clear=3D"none">significant additiona= l requirement on<br clear=3D"none">the DMTF specifications is that a WBEM c= lient may return a cookie if it <br clear=3D"none">receives a Set-Cookie:<b= r clear=3D"none">response from the WBEM server and that a WBEM server may i= nclude a <br clear=3D"none">Set-Cookie header in<br clear=3D"none">a WBEM r= esponse.<br clear=3D"none"><br clear=3D"none">This is a specialized and spe= cific use of the cookie header concept. As <br clear=3D"none">such it would= appear:<br clear=3D"none"><br clear=3D"none">1. The cookie in the WBEM cli= ent has a life of a session where the <br clear=3D"none">session is defined by the server and<br clear= =3D"none"> possibly limited by the WBEM client.<br clear=3D"n= one"> If a Set-Cookie: header is received by the client it se= nds the <br clear=3D"none">cookie back to that server with the subsequent<b= r clear=3D"none"> operations for the same session and can the= n discard the cookie. <br clear=3D"none">This is more specific than<b= r clear=3D"none"> the general use of cookies in a browser/web= server environment.<br clear=3D"none"> As such, there is no = need for the expiration date option (Expires=3D) <br clear=3D"none">or the = other optional components that<br clear=3D"none"> are defined= in RFC 6265 at least for the patches proposed as the <br clear=3D"none">Pe= gasus implementation.<br clear=3D"none"><br clear=3D"none">2. The concept o= f session is completely by the server. It creates a <br clear=3D"none">sess= ion once it<br clear=3D"none"> has validated the request, creates the sessi= onID, times out the <br clear=3D"none">session, and has a way<br clear=3D"n= one"> to tell the client when the session has timed out ( err= or 401, <br clear=3D"none">Unauthorized)<br clear=3D"none"><br clear=3D"non= e">If defined in an extension to the cim/xml specification, the requirement= <br clear=3D"none">would simply be that:<br clear=3D"none"><br clear=3D"no= ne"> a. The WBEM Server and WBEM client may use the HTTP cook= ie header <br clear=3D"none">fields as defined in HTTP<br clear=3D"none">&n= bsp; specifications. Note that the original specifica= tion was RFC <br clear=3D"none">2109 which was superceeded by<br clear=3D"n= one"> 2965, which was, in turn, superceeded by = 6265 so we should be <br clear=3D"none">referenceing 6265 I think.<br clear= =3D"none"> This defines the Cookie: and Set-Coo= kie: header fields<br clear=3D"none"><br clear=3D"none">b. A WBEM server may receive a WBEM requ= est message that includes a <br clear=3D"none">cookie header field<br clear= =3D"none"> as defined in the HTTP specification= s that includes cookies <br clear=3D"none">defined in a previous WBEM<br cl= ear=3D"none"> response message<br clear=3D"none= "><br clear=3D"none"> c. A Client that receives a WBEM respon= se containing a set-cookie <br clear=3D"none">header should<br clear=3D"non= e"> return that cookie in the subsequent reques= ts for the same session.<br clear=3D"none"><br clear=3D"none"> = d. A Server may include a cookie header in a cim/xml response <br clear= =3D"none">containing one or<br clear=3D"none"> = more cookies based on the HTTP specification.<br clear=3D"none"><br clear= =3D"none">In fact the only real changes to the DMTF specification are proba= bly <br clear=3D"none">that a WBEM server response<br clear=3D"none">may include a cookie header (set_co= okie:) and if it does, the WBEM <br clear=3D"none">client may include that = cookie<br clear=3D"none">in subsequent requests.<br clear=3D"none"><br clea= r=3D"none">Note that the current patch defines the cookie name as "PEGASUS_= SID" <br clear=3D"none">which is an OpenPegasus<br clear=3D"none">defined n= ame and pretty much ties this particular cookieto OpenPegasus. <br cl= ear=3D"none">Since the cookie name is<br clear=3D"none">server generated an= d is only to be used to send the cookie back to the <br clear=3D"none">serv= er with the next request<br clear=3D"none">for the same session, the actual= name is effectively meaningless.<br clear=3D"none"><br clear=3D"none"><br = clear=3D"none"><br clear=3D"none"><div class=3D"qtdSeparateBR"><br><br></di= v><div class=3D"yqt8302768016" id=3D"yqtfd39766"><br clear=3D"none">On 07/3= 1/2014 02:40 AM, Jan Safranek wrote:<br clear=3D"none">> On 07/30/2014 0= 4:34 PM, Andreas Maier wrote:<br clear=3D"none">>> Karl, Jan, I have discussed the issue with a numbe= r of folks, and<br clear=3D"none">>> that helped me to better underst= and how Jan's proposal works.<br clear=3D"none">>><br clear=3D"none">= >> I'd like to make the following comments, before I leave for vacati= on<br clear=3D"none">>> (back at home from 8/16 on, back in the offic= e from 8/25 on):<br clear=3D"none">>><br clear=3D"none">>> Just= to recap the overall approach: Upon successful authentication of<br clear= =3D"none">>> a CIM request, if the server supports the new feature, i= t invents a<br clear=3D"none">>> session ID and sends that back with = the CIM response. If the client<br clear=3D"none">>> supports the new= feature, it uses that session ID on subsequent CIM<br clear=3D"none">>&= gt; requests. Upon receipt of a CIM request with such a session ID, the<br = clear=3D"none">>> server can decide whether it trusts the session ID = sufficiently at<br clear=3D"none">>> that moment to bypass the authentication check.<br= clear=3D"none">>><br clear=3D"none">>> I'm fine with that over= all approach, but I kept the description<br clear=3D"none">>> deliber= ately high level, because there are some considerations and<br clear=3D"non= e">>> requirements:<br clear=3D"none">>><br clear=3D"none">>= > - It depends very much on the data that makes up the session ID. A<br = clear=3D"none">>> suggestion from one of our security folks was that = the session ID be<br clear=3D"none">>> a hash of (userid, timestamp, = randon number, underlying SSL session<br clear=3D"none">>> ID). It is= definitely a requirement that the session ID cannot be<br clear=3D"none">&= gt;> calculated by an intruder. For example, just using timestamp and<br= clear=3D"none">>> userid would probably be not sufficient. Keep in m= ind that the code<br clear=3D"none">>> is open source, so the algorit= hm how exactly the hash is calculated<br clear=3D"none">>> will be known, and the secre= t must be in the data, not in the<br clear=3D"none">>> algorithm. Usi= ng the underlying SSL session ID for example ensures<br clear=3D"none">>= > that the same SSL session is still in place. Maybe that is too much<br= clear=3D"none">>> of a requirement, but it is something that needs t= o be carefully<br clear=3D"none">>> considered.<br clear=3D"none">>= ;><br clear=3D"none">> Currently, the session ID is just cryptographi= cally strong* random<br clear=3D"none">> number, nothing else. Timestamp= , source IP address and client user name<br clear=3D"none">> are stored = (and checked) in Pegasus memory, but are *not* transmitted in<br clear=3D"n= one">> the session id.<br clear=3D"none">><br clear=3D"none">> *) = 15 bytes (120 bits), generated by RAND_bytes() call from<br clear=3D"none">= > openssl/rand.h. I've chose 15 as 'long enough' and divisible by 3, so = it<br clear=3D"none">> can be base64-encoded without padding. It can be longe= r, it's just one<br clear=3D"none">> #define.<br clear=3D"none">><br = clear=3D"none">> I think that adding anything else to the session ID won= 't improve<br clear=3D"none">> security in any way, it will just make it= more predictable. We may store<br clear=3D"none">> (and check) somethin= g on server, if we want. I would explicitly avoid<br clear=3D"none">> ch= ecking SSL session ID, as the client may use different TCP connection<br cl= ear=3D"none">> (and thus SSL session) for subsequent request - that's ve= ry common in<br clear=3D"none">> HTTP world, clients (e.g. pywbem) don't= use Keep-Alive that much.<br clear=3D"none">><br clear=3D"none">>>= ; - The server must be able to determine the lifetime of the session<br cle= ar=3D"none">>> ID. The proposed cookie based approach would probably = use the cookie<br clear=3D"none">>> lifetime for that, but that could= also be done otherwise. Can cookie<br clear=3D"none">>> lifetimes be modified by = a client? That would be bad. I would have a<br clear=3D"none">>> bett= er feeling if the lifetime was encoded in the session ID instead<br clear= =3D"none">>> of being a separate piece of clear data. Even if the ses= sion ID is a<br clear=3D"none">>> hash (which cannot be unpacked), th= e server could remember (in<br clear=3D"none">>> memory) which sessio= n IDs it has handed out at any point in time, and<br clear=3D"none">>>= ; match the session ID with an internal record of it that shows the<br clea= r=3D"none">>> lifetime.<br clear=3D"none">> The cookie lifetime is= stored on server, client cannot influence it in<br clear=3D"none">> any= way. As I wrote above, it's not part of session ID, as it would make<br cl= ear=3D"none">> the ID more predictable.<br clear=3D"none">><br clear= =3D"none">>> - The server must be allowed to decide at any point that= a normally<br clear=3D"none">>> valid session ID is nevertheless dismissed, and th= at a new session ID<br clear=3D"none">>> is created. The server can m= ake that determination based upon nearly<br clear=3D"none">>> everyth= ing, including suspicuous client behavior with otherwise<br clear=3D"none">= >> valid requests. If the server dismisses an incoming session ID, it= <br clear=3D"none">>> performs the normal authentication as if no ses= sion ID had been<br clear=3D"none">>> provided by the client, and ret= urns a new session ID.<br clear=3D"none">> Well, there is no code for th= at, but if someone implements such<br clear=3D"none">> detection logic, = it's just one HashTable.remove() call to forget a<br clear=3D"none">> se= ssion. which implies that the next request will go through proper<br clear= =3D"none">> authentication.<br clear=3D"none">><br clear=3D"none">>= ;> - As a result, the client must always use the session ID returned by<= br clear=3D"none">>> the last response, because the server could have r= ecalculated it.<br clear=3D"none">> Sure, that's how HTTP and my client = patches work.<br clear=3D"none">><br clear=3D"none">>> - how the s= ession ID is transported between client and server, has a<br clear=3D"none"= >>> number of options. It would certainly be some HTTP header. I have= <br clear=3D"none">>> seen extension headers used for that purpose, i= t does not necessarily<br clear=3D"none">>> have to be a cookie. I fi= nd cookies generally suspicious, and don't<br clear=3D"none">>> fully= understand to what extent HTTP infrastructure (e.g. proxies)<br clear=3D"n= one">>> can have a policy to not allow them, in which case a cookie b= ased<br clear=3D"none">>> approach would be limiting in such environm= ents.<br clear=3D"none">> Cookie is described as HTTP 1.0 extension in R= FC 2109: HTTP State<br clear=3D"none">> Management Mechanism, released i= n 1997. It has been revised several<br clear=3D"none">> times and it is part of any de= cent HTTP implementation for ages. To be<br clear=3D"none">> honest, I h= aven't looked for any other RFC for session management over<br clear=3D"non= e">> HTTP, the cookie is really used everywhere.<br clear=3D"none">><= br clear=3D"none">> RFC 2616 (HTTP 1.1) says: Unrecognized header fields= SHOULD be ignored<br clear=3D"none">> by the recipient and MUST be forw= arded by transparent proxies.<br clear=3D"none">><br clear=3D"none">>= So, client who do not support cookies SHOULD survive just with Basic<br cl= ear=3D"none">> authentication in every request, just like now. And proxi= es MUST forward<br clear=3D"none">> the cookie.<br clear=3D"none">><b= r clear=3D"none">>> - Obviously, it must be optional to support for b= oth client and<br clear=3D"none">>> server. Just to have it mentioned= .<br clear=3D"none">> The server is configurable.<br clear=3D"none">>= <br clear=3D"none">> What benefit it has to turn it off on _client_ side? If a client<br clear= =3D"none">> receives a cookie, it indicates that the server supports it.= The client<br clear=3D"none">> just sends it back in subsequent request= s. If the server decides that<br clear=3D"none">> the cookie is not enou= gh, the client processed 401 Unauthorized response<br clear=3D"none">> a= s usual.<br clear=3D"none">><br clear=3D"none">>> - One important = consideration is whether we want it to work with both<br clear=3D"none">>= ;> HTTP and HTTPS, and with all HTTP authentication mechanisms. Someone<= br clear=3D"none">>> needs to draw the matrix of HTTP/HTTPS with supp= orted authentication<br clear=3D"none">>> mechanisms, and state for w= hich ones the session ID approach would be<br clear=3D"none">>> suppo= rted. That may shape the design significantly. For example, if<br clear=3D"= none">>> we supported it only for HTTPS, the session ID would not nee= d to be<br clear=3D"none">>> encrypted. If we also wanted to support it for HTT= P, we maybe want to<br clear=3D"none">>> see it encrypted.<br clear= =3D"none">> As the session ID is just a random number, encrypting it on = HTTP won't<br clear=3D"none">> help much, especially without proper hand= shake protocol to exchange<br clear=3D"none">> keys, which you don't hav= e on HTTP.<br clear=3D"none">><br clear=3D"none">> In addition, it lo= oks quite funny that cookie should be encrypted, while<br clear=3D"none">&g= t; Basic authentication (the only one that Pegasus supports now) sends user= <br clear=3D"none">> password unencrypted in a HTTP header.<br clear=3D"= none">><br clear=3D"none">><br clear=3D"none">>> - There are su= fficient screws and decisions in that whole approach,<br clear=3D"none">>= ;> so that we cannot assume this is just an OpenPegasus addition.<br cle= ar=3D"none">>> DSP0200 documents all standard HTTP headers that play = a role in<br clear=3D"none">>> CIM-XML, and it would need to describe this new ab= ility as well. Karl<br clear=3D"none">>> and I are in the CIM-XML WG,= and it should not take very long, once<br clear=3D"none">>> we have = agreed upon the details on how to do it.<br clear=3D"none">>><br clea= r=3D"none">>> To me, the open points are: - how to calculate the sess= ion ID. This<br clear=3D"none">>> could be a recommendation for serve= rs to keep them secure, because it<br clear=3D"none">>> is opaque for= clients. - which mechanism to use to transport the<br clear=3D"none">>&= gt; session ID between client and server.<br clear=3D"none">> I hope I e= xplained my design and implementation above, feel free to ask<br clear=3D"n= one">> anything.<br clear=3D"none">><br clear=3D"none">> Jan<br cl= ear=3D"none">><br clear=3D"none"><br clear=3D"none"></div><br><br></div>= </div> </div> </blockquote><div></div> </div></body></html> --61789334-1381223267-1406832608=:61783--