On Sat, 2010-06-05 at 03:51 -0400, Richard E. Silverman wrote:
> In constructing the SPNEGO
> token, which contains an AP_REQ with no application data in sight (not an
> empty application data field somewhere), they do indeed pass a zero-length
> buffer -- not a null in_data pointer -- to krb5_mk_r
> tlyu> Richard Silverman writes:
> >> On Fri, 4 Jun 2010, Greg Hudson wrote:
> >>
> >>> On Fri, 2010-06-04 at 12:24 -0400, Richard E. Silverman wrote:
> >>> I tracked down the bug.
> >>
> >> With apologies for being a pain in the butt, I'm not sure we understand
> >> the situati
> "KR" == Ken Raeburn writes:
KR> On Jun 4, 2010, at 14:47, Richard Silverman wrote:
>>> Providing zero-length input data is not the same as not providing
>>> any input data.
>>
>> I don't understand your point here -- from a calling perspective of
>> course they are
On Jun 4, 2010, at 14:47, Richard Silverman wrote:
>> Providing zero-length input data is not the same as not providing any
>> input data.
>
> I don't understand your point here -- from a calling perspective of course
> they are distinguishable, but they *mean* the same thing, do they not? I
> me
Richard Silverman writes:
> On Fri, 4 Jun 2010, Greg Hudson wrote:
>
>> On Fri, 2010-06-04 at 12:24 -0400, Richard E. Silverman wrote:
>>> I tracked down the bug.
>>
>> With apologies for being a pain in the butt, I'm not sure we understand
>> the situation well enough to safely make a change.
>
On Fri, 4 Jun 2010, Greg Hudson wrote:
> On Fri, 2010-06-04 at 12:24 -0400, Richard E. Silverman wrote:
>> I tracked down the bug.
>
> With apologies for being a pain in the butt, I'm not sure we understand
> the situation well enough to safely make a change.
Not at all; it has to be done right.
On Fri, 2010-06-04 at 12:24 -0400, Richard E. Silverman wrote:
> I tracked down the bug.
With apologies for being a pain in the butt, I'm not sure we understand
the situation well enough to safely make a change.
Providing zero-length input data is not the same as not providing any
input data. Th
I tracked down the bug. The routine krb5_mk_req_extended() in
src/lib/krb5/krb/mk_req_ext.c creates the authenticator for an AP_REQ.
This authenticator includes a checksum over the AP_REQ application data.
The routine recognized a null in_data pointer as indicating that no
application data was pr
On Thu, 2010-06-03 at 00:06 -0400, Richard Silverman wrote:
> Thanks for looking at it. I don't know that 1.7 is OK, though;
> the latest release I know does *not* have the problem, is 1.6.3.
I was also able to get a trunk gss-client to authenticate to a 1.6
gss-server with a 1.6 KDC, with only R
On Wed, 2 Jun 2010, Greg Hudson wrote:
> On Wed, 2010-06-02 at 03:33 -0400, Richard E. Silverman wrote:
>> After upgrading to MIT Kerberos 1.8.1, I get KRB5KRB_AP_ERR_MODIFIED while
>> trying to authenticate to certain devices; so far, a NetApp filer, and
>> Windows hosts running BitVise WinSSHD a
On Wed, 2010-06-02 at 03:33 -0400, Richard E. Silverman wrote:
> After upgrading to MIT Kerberos 1.8.1, I get KRB5KRB_AP_ERR_MODIFIED while
> trying to authenticate to certain devices; so far, a NetApp filer, and
> Windows hosts running BitVise WinSSHD and MS SQL Server (alll part of a
> Windows AD
After upgrading to MIT Kerberos 1.8.1, I get KRB5KRB_AP_ERR_MODIFIED while
trying to authenticate to certain devices; so far, a NetApp filer, and
Windows hosts running BitVise WinSSHD and MS SQL Server (alll part of a
Windows AD realm). Clients are OpenSSH, Samba, and FreeTDS on Solaris.
The same
12 matches
Mail list logo
