Hello and good evening, Ivan.
Ivan Vučica wrote in <CAGPLYoS56mnejYzLpqBT5X3=ujNksr9dH7sf8qCWs2F3+eTk\
=a...@mail.gmail.com>:
|On Wed, Jun 19, 2019 at 2:56 PM Steffen Nurpmeso <stef...@sdaoden.eu> \
|wrote:
|>> What would be further useful debugging or tracing information to
|>> share?
|>
|> In general our -d or -vv switches would be nice. ^_^
|
|Here's with -d:
...
|>>> T2 AUTHENTICATE GSSAPI
|>>> SERVER: +
|>>> YIIFhgOMITTING-WHAT-LOOKS-LIKE-CREDENTIALS3tM=
|>>> SERVER: + YIGVBOMITTING-WHAT-LOOKS-LIKE-CREDENTIALSZIXw=
|[6655] 1560952720.212835: Read AP-REP, time 1560952720.212831, subkey
|aes256-cts/B91D, seqnum 73895367
|>>>
|>>> SERVER: + BQOMITTINGu58=
|>>> BQCREDENTIALS8E=
|>>> SERVER: T2 NO [AUTHENTICATIONFAILED] Authentication failed.
|IMAP error: [AUTHENTICATIONFAILED] Authentication failed.
|
|It is really hard to follow the debug info given, and the amount of
|info changed between the old and new s-nail. But eyeballing the
|credentials sent in both versions, there is nothing obviously damaged
|in authentication lines.
I should have warned you that the password and credentials will be
included in the debug output.
You could of course do "set verbose" twice when in interactive
mode, then the entire load phase would not be logged.
Doing logging right is hard; maybe, some day, it will be possible
to have some log filter, which can select by source, or so.
In days where you can inspect/adjust running kernels via DTrace
and BPF, almost anything is very primitive in comparison.
Hm. I am sorry, but i think there was another false length
calculation.
Yes, the thing is that i had "implemented" SMTP GSSAPI, and that
uses string buffers etc. and not (sn)printf(3) on a stack buffer
to do simple string concatenations, and when i "fixed" the GSSAPI
token length calculation in commit [384c8e2e] (before we included
the C string terminator NUL, which is not valid according to
GSSAPI standard, yet it worked for almost two decades), i did that
by having the IMAP and the SMTP GSSAPI headers side-by-side. I am
afraid that i got pi.s.d when seeing the snprintf()s and the
string length calls (even if the length is known) in the IMAP one.
Also, you know, IMAP code had been removed from the codebase for
over a year, it was reinstantiated on user request only. (Again
signal jumps and blocking I/O, and IMAP being the largest piece of
code going that route. And that is not the way i want this
software to go, as it means the entire codebase is stuck at
a single place, it is entirely sequential, whereas i want the
possibility to have multiple boxes open at the same time, for
example. Which does not work, currently. For example.)
Dear Ivan. If you are willing to test once again, at [1] there is
a complete ball, but you could also simply apply the attached
patch instead, which is very much smaller.
I am sorry for the inconvenience, and i hope this fixes GSSAPI.
It would be great if you could report success! (I will not be able
to setup a GSSAPI box before the 22nd, when my internet limit is
refreshed. (I have exceeded my limit and the ISDN that i should
get nonetheless seems to be implemented virtually via some kind of
scheduler, and that is a killer.))
[1]
https://git.sdaoden.eu/cgit/s-nail.git/snapshot/s-nail-6b070335d77251308e1910f9efb2e08754a1f176.tar.xz
|I could be wrong, of course.
No, i think there was another mutilated length involved.
|> ...
|>|ivucica@myhostname:~$ klist
|>|Credentials cache: FILE:/tmp/krb5cc_501
|>| Principal: ivuc...@ds.mydomainname.net
|>|
|>| Issued Expires Principal
|>|Jun 19 11:25:37 2019 Jun 19 21:25:37 2019 krbtgt/DS.MYDOMAINNAME.NET@D\
|>|S.MYDOMAINNAME.NET \
|> ...
|> fail
|> ...
|
|No, this is actually success. I kdestroyed the ticket cache
|beforehand, and kinited.
And isn't that cooler than OAUTH? And no advertising, neither
yesterday nor today and very likely also tomorrow not.
|This is the 'krbtgt' - 'kerberos ticket-granting-ticket' which is used
|to get service-specific tickets.
|
|I pasted this to demonstrate that GSSAPI is invoked correctly to
|obtain the service-specific ticket when launching the newly-built
|s-nail. That is: GSSAPI manages to get
|imap/myhostname.ds.mydomain....@ds.mydomainname.net ticket, usable to
|authenticate against Dovecot.
Thank you. Yes, a pity. All my fault.
|>|ivucica@myhostname:~$ klist
|>|Credentials cache: FILE:/tmp/krb5cc_501
|>| Principal: ivuc...@ds.mydomainname.net
|>|
|>| Issued Expires Principal
|>|Jun 19 11:25:37 2019 Jun 19 21:25:37 2019 krbtgt/DS.MYDOMAINNAME.NET@D\
|>|S.MYDOMAINNAME.NET \
|>|
|>|Jun 19 11:25:42 2019 Jun 19 21:25:37 2019 imap/myhostname.ds.mydomainn\
|>|ame....@ds.mydomainname.net \
|> ...
|> ok
|> ...
|>
|> But say, the succeeding klist shows one more issued principal?
|> I must admit that for the last four years i have done GSSAPI
|> changes only according to the "GSS-API Programming Guide" from Sun
|> Microsystems, rather than via live testing. (._.)
|
|My understanding of Kerberos comes from Kerberos: The Definitive Guide
|and some online reading.
|
|It is correct that the service-specific ticket appears only after
|s-nail is launched.
|
|> Oh, and i don't think i will find any time to setup a postfix /
|> dovecot / GSSAPI environment this week.
|>
|> *Really not ok*???
|
|Yeah, old s-nail works, new s-nail doesn't authenticate.
And hopefully this changed, finally.
Sorry for not carefully looking over all changes that mentioned
commit brought to the IMAP GSSAPI file!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
diff --git a/src/mx/obs-imap-gssapi.h b/src/mx/obs-imap-gssapi.h
index 4a961b2b..18d0844a 100644
--- a/src/mx/obs-imap-gssapi.h
+++ b/src/mx/obs-imap-gssapi.h
@@ -299,13 +299,14 @@ jebase64:
/* First octet: bit-mask with protection mechanisms (1 = no protection
* mechanism).
* Second to fourth octet: maximum message size in network byte order.
- * Fifth and following octets: user name string */
- su_mem_copy(&o[4], ccred->cc_user.s, ccred->cc_user.l +1);
+ * Fifth and following octets: user name string.
+ */
o[0] = 1;
o[1] = 0;
- o[2] = o[3] = S(char,0xFF);
- send_tok.length = 4 + ccred->cc_user.l;
+ o[2] = o[3] = (char)0377;
+ snprintf(&o[4], sizeof o - 4, "%s", ccred->cc_user.s);
send_tok.value = o;
+ send_tok.length = su_cs_len(&o[4]) -1 + 4;
maj_stat = gss_wrap(&min_stat, gss_context, 0, GSS_C_QOP_DEFAULT, &send_tok,
&conf_state, &recv_tok);
f |= a_F_RECV_TOK;
