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