List:Commits« Previous MessageNext Message »
From:Vladislav Vaintroub Date:May 10 2011 12:53pm
Subject:RE: bzr commit into mysql-5.5 branch (rafal.somla:3477) Bug#11879051
View as plain text  

> -----Original Message-----
> From: Rafal Somla [mailto:rafal.somla@stripped]
> Sent: Dienstag, 10. Mai 2011 14:16
> To: Vladislav Vaintroub
> Cc: commits@stripped; Georgi Kodinov
> Subject: Re: bzr commit into mysql-5.5 branch (rafal.somla:3477)
> Bug#11879051
> 
> On 10/05/2011 12:45, Vladislav Vaintroub wrote:
> >
> >
> >> -----Original Message-----
> >> From: Rafal Somla [mailto:rafal.somla@stripped]
> >> Sent: Dienstag, 10. Mai 2011 12:02
> >> To: Vladislav Vaintroub
> >> Cc: commits@stripped; Georgi Kodinov
> >> Subject: Re: bzr commit into mysql-5.5 branch (rafal.somla:3477)
> >> Bug#11879051
> >>
> >> Hi Wlad,
> >>
> >> On 09/05/2011 21:37, Vladislav Vaintroub wrote:
> >>
> >>> I  think  the analysis  is not completely correct here.
> >>>
> >>> The way Windows authentication works  is such that0) Server sends
> >>> welcome packet. 1) client sends client authentication packet that
> >>> contains authentication method but without payload. 2) then server
> >>> sends UPN to client 3) then client puts UPN into
> >>> InitializeSecurityContext() and sends the resulting blob to server.
> >>> (following steps omitted)
> >>>
> >>> The 255 limit is would be a limit in step 1).  But since payload is
> >>> not used in this step , there is also no limit.
> >
> >> My understanding is different. Basically, the UPN sent first by server
> >> is wrapped in the welcome packet already and then the first
> >> authentication payload from client is wrapped inside the normal client
> >> authentication packet (in hope that all will be settled during this
> >> standard, 2 packet sequence).
> >
> > When server sends welcome packet (and this is the first packet ever sent
in
> > client-server communication), it  does not send UPN, because it does not
> yet
> > know that client wants Windows authentication.
> > UPN comes attached to change_plugin "packet", as described in
> > http://bugs.mysql.com/bug.php?id=57442
> >
> > Client, in theory, can send some plugin specific payload in
scramble_buff in
> > client authentication packet. In this case 255 limit would apply .
> > But in Windows authentication case, client does not do send anything in
> > scramble_buff.   To create the plugin specific payload
> > (InitializeSecurityContext blobs), it needs to know the UPN,  which
server
> > has not yet sent.
> 
> Good points. But I am still not sure if the situation described in
> bug#11879051 could not happen in certain situations.
> Here are my guesses
> only:
> 
> 1. Server can be configured to use Windows authentication as the default
> method. It that case it might perhaps send UPN already in the first
> packet and client send its reply in the following client authentication
> packet.

Client would not be prepared for it.  It expects this sequence:

Client connects (opens a socket)=> Server sends welcome => Client sends
client authentication packet, setting authentication method after the
database name  indicating its interest in Windows authentication => Server
replies (with change_plugin that has UPN attached or just UPN)=>Client sends
InitializeSecurityContext blob =>....


> 1. I am not sure if the client authentication packet is re-sent when
> authentication is re-started due to change of authentication method. In
> that case the first client reply would again be sent as content of
> scramble_buff.

This is COM_CHANGE_USER case . 
Client sends COM_CHANGE_USER=>Server sends change plugin with UPN attached
=>Client sends a blob from InitializeSecurityContext()=>...

I do not exclude any possibility that "change_plugin" junk bytes
0xfe"auth_windows" are optional if server is configured with windows
default. 

Again, nowhere in this conversation client would be using scramble_buff part
of the client authentication packet. 


> Rafal
> 
> --
> MySQL Code Commits Mailing List
> For list archives: http://lists.mysql.com/commits
> To unsubscribe:
> http://lists.mysql.com/commits?unsub=1


Thread
bzr commit into mysql-5.5 branch (rafal.somla:3477) Bug#11879051Rafal Somla28 Apr
  • RE: bzr commit into mysql-5.5 branch (rafal.somla:3477) Bug#11879051Vladislav Vaintroub9 May
    • Re: bzr commit into mysql-5.5 branch (rafal.somla:3477) Bug#11879051Rafal Somla10 May
      • RE: bzr commit into mysql-5.5 branch (rafal.somla:3477) Bug#11879051Vladislav Vaintroub10 May
        • Re: bzr commit into mysql-5.5 branch (rafal.somla:3477) Bug#11879051Rafal Somla10 May
          • RE: bzr commit into mysql-5.5 branch (rafal.somla:3477) Bug#11879051Vladislav Vaintroub10 May