> -----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
