Something else:
Beside my own actually not working DANE configuration,
if i setup Postfix with
smtpd_use_tls = yes smtp_tls_security_level = dane smtp_dns_support_level = dnssec
i should see „Verified“ and „Untrusted“ TLS connections, right?
There are appearing only „Anonymous“ connections as before.
Regards! Frank
Am 15.01.2015 um 12:54 schrieb Frank Fiene:
Hi Frank,
smtpd_use_tls = yes
smtpd_ != smtp_
smtp_tls_security_level = dane smtp_dns_support_level = dnssec
i should see „Verified“ and „Untrusted“ TLS connections, right?
You should see "Trusted TLS connection established".
Peer
* Frank Fiene ffiene@veka.com:
Something else:
Beside my own actually not working DANE configuration,
if i setup Postfix with
smtpd_use_tls = yes smtp_tls_security_level = dane smtp_dns_support_level = dnssec
i should see „Verified“ and „Untrusted“ TLS connections, right?
Is your DNS resolver DNSSEC capable?
Try this to test and watch out for the 'ad' flag:
p:~$ dig +dnssec dane.sys4.de
; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> +dnssec dane.sys4.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37718 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 3
^^ This means sys4.de is an (DNSSEC) authenticated domain
If you don't see this, Postfix won't be able to DANE identify destinations.
p@rick
The „da" flag is missing!?
Am 15.01.2015 um 13:06 schrieb Patrick Ben Koetter p@sys4.de:
dig +dnssec dane.sys4.de http://dane.sys4.de/
root@mail:/home/ffiene# dig +dnssec dane.sys4.de +m
; <<>> DiG 9.9.5-3-Ubuntu <<>> +dnssec dane.sys4.de +m ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53974 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 5
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dane.sys4.de. IN A
;; ANSWER SECTION: dane.sys4.de. 3298 IN A 194.126.158.134 dane.sys4.de. 3298 IN RRSIG A 8 3 3600 ( 20150122013715 20150115044917 17338 sys4.de. qZLhJ21V2u9Yqvf6ppflnMVC6+BPRRzz91LIT+Eu14Jc aE4EHgcK8bGM8rD25xUR2hloxxQSnXrUnAJWNbUso83C SkF9LwjkvyJfEZclWxz5ZEp6BSrETOtAZHaqwwmBuk/A YVQCZwiy9B2dsuQDoqtXly4FVrlUvrsLzJ/SUBI= )
;; AUTHORITY SECTION: sys4.de. 1301 IN NS ns.schiffbauer.net. sys4.de. 1301 IN NS ns3.ray.net. sys4.de. 1301 IN NS ns.sys4.de. sys4.de. 1301 IN RRSIG NS 8 2 3600 ( 20150119172312 20150112081903 17338 sys4.de. KTwvyGNhOEbGU7gcROBjJSTDZABqP6hZQx7ZZqB9bF7S GOCYczIm183mNiOtt2/QiyMLRwjW0womrbvhJETGde4U dG2blv2tOib4RXAxgp7nfPUysk3Qe/ILqievGZJdMb/F DlpE0fY0GnCc2sZ/ouYh31fnIMgV3ucxBR/Bioc= )
;; ADDITIONAL SECTION: ns.sys4.de. 1942 IN A 194.126.158.143 ns.schiffbauer.net. 10633 IN A 188.40.110.137 ns3.ray.net. 2133 IN A 193.0.187.21 ns.sys4.de. 1942 IN RRSIG A 8 3 3600 ( 20150118175116 20150111103820 17338 sys4.de. c85te9gFPVzTrSPoVAhmuneLWr/flsdfn8VEZmwjaO/7 bXUIzyY7prJYHWqJSJwODkgWt5z/GVdPJrSIkPSKNDhN s+0uVY4nOecBIalb1B5mr5vrYuX8vQzfcJtjsPVTrEBc dXjeEtW9njh9QpHJn5Nfkf6H+LF4nY8/r/4TGT4= )
;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jan 15 13:44:42 CET 2015 ;; MSG SIZE rcvd: 677
Frank
Am Donnerstag, 15. Januar 2015, 13:46:39 schrieb Frank Fiene:
The „da" flag is missing!?
"ad"
Am 15.01.2015 um 13:06 schrieb Patrick Ben Koetter p@sys4.de:
dig +dnssec dane.sys4.de http://dane.sys4.de/
root@mail:/home/ffiene# dig +dnssec dane.sys4.de +m
; <<>> DiG 9.9.5-3-Ubuntu <<>> +dnssec dane.sys4.de +m ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53974 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 5
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dane.sys4.de. IN A
;; ANSWER SECTION:
(...)
Your resolver gets all the dnssec relevant RR of the domain, but does not check if the RRSIG are really correct. Please check the same with a dnssec enabled resolver. 8.8.8.8 for instance does check the signatures.
dig @8.8.8.8 +dnssec sys4.de
you will see, that the "ad" flag ist present in the answer.
Next step: Install a dnssec aware resolver.
Mit freundlichen Grüßen,
Michael Schwartzkopff
Am 15.01.2015 um 14:10 schrieb Michael Schwartzkopff <ms@sys4.de mailto:ms@sys4.de>:
Am Donnerstag, 15. Januar 2015, 13:46:39 schrieb Frank Fiene:
The „da" flag is missing!?
„ad"
Sigh, Apple ...
Am 15.01.2015 um 13:06 schrieb Patrick Ben Koetter <p@sys4.de mailto:p@sys4.de>:
dig +dnssec dane.sys4.de http://dane.sys4.de/ <http://dane.sys4.de/ http://dane.sys4.de/>
root@mail:/home/ffiene# dig +dnssec dane.sys4.de http://dane.sys4.de/ +m
; <<>> DiG 9.9.5-3-Ubuntu <<>> +dnssec dane.sys4.de http://dane.sys4.de/ +m ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53974 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 5
Your resolver gets all the dnssec relevant RR of the domain, but does not check if the RRSIG are really correct. Please check the same with a dnssec enabled resolver. 8.8.8.8 for instance does check the signatures.
dig @8.8.8.8 +dnssec sys4.de http://sys4.de/
you will see, that the "ad" flag ist present in the answer.
Next step: Install a dnssec aware resolver.
On the other mailserver with no local DNS server (the other mailserver has a local DNS server which forwards to the same as this one):
root@mail1:/etc/postfix# dig +dnssec dane.sys4.de http://dane.sys4.de/ +m
; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> +dnssec dane.sys4.de http://dane.sys4.de/ +m ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42645 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
But still anonymous TLS connections only!
Frank
Mit freundlichen Grüßen,
Michael Schwartzkopff
-- [*] sys4 AG
http://sys4.de http://sys4.de/, +49 (89) 30 90 46 64, +49 (162) 165 0044 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Viele Grüße! i.A. Frank Fiene
Sorry about the confusion.
In Patricks and Carstens PDF file there are two examples.
I think they describe outgoing connections, right? There are the keywords „Verified“ and „Untrusted“, so far so good.
But what is about incoming connections? There seems to be no parameter like smtpd_tls_security_level or smtpd_dns_support_level.
Is it not possible to verify incoming connections which in my opinion is more important than outgoing?
And in my log file there are only anonymous TLS connections which means: no CA-signed certificate, right?
Frank
Am 15.01.2015 um 15:25 schrieb Frank Fiene ffiene@veka.com:
Am 15.01.2015 um 14:10 schrieb Michael Schwartzkopff <ms@sys4.de mailto:ms@sys4.de>:
Am Donnerstag, 15. Januar 2015, 13:46:39 schrieb Frank Fiene:
The „da" flag is missing!?
„ad"
Sigh, Apple ...
Am 15.01.2015 um 13:06 schrieb Patrick Ben Koetter <p@sys4.de mailto:p@sys4.de>:
dig +dnssec dane.sys4.de http://dane.sys4.de/ <http://dane.sys4.de/ http://dane.sys4.de/>
root@mail:/home/ffiene# dig +dnssec dane.sys4.de http://dane.sys4.de/ +m
; <<>> DiG 9.9.5-3-Ubuntu <<>> +dnssec dane.sys4.de http://dane.sys4.de/ +m ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53974 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 5
Your resolver gets all the dnssec relevant RR of the domain, but does not check if the RRSIG are really correct. Please check the same with a dnssec enabled resolver. 8.8.8.8 for instance does check the signatures.
dig @8.8.8.8 +dnssec sys4.de http://sys4.de/
you will see, that the "ad" flag ist present in the answer.
Next step: Install a dnssec aware resolver.
On the other mailserver with no local DNS server (the other mailserver has a local DNS server which forwards to the same as this one):
root@mail1:/etc/postfix# dig +dnssec dane.sys4.de http://dane.sys4.de/ +m
; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> +dnssec dane.sys4.de http://dane.sys4.de/ +m ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42645 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
But still anonymous TLS connections only!
Frank
Mit freundlichen Grüßen,
Michael Schwartzkopff
-- [*] sys4 AG
http://sys4.de http://sys4.de/, +49 (89) 30 90 46 64, +49 (162) 165 0044 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Viele Grüße! i.A. Frank Fiene -- Frank Fiene IT-Security Manager VEKA Group
Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene@veka.com mailto:ffiene@veka.com http://www.veka.com http://www.veka.com/
PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW
VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany
Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster
Viele Grüße! i.A. Frank Fiene
Frank Fiene wrote:
But what is about incoming connections? There seems to be no parameter like smtpd_tls_security_level or smtpd_dns_support_level.
A SSL/TLS server cannot determine whether a TLS client properly verified the server's certificate (or raw public key). And DANE is not client authentication.
Ciao, Michael.
* Frank Fiene ffiene@veka.com:
Sorry about the confusion.
In Patricks and Carstens PDF file there are two examples.
I think they describe outgoing connections, right? There are the keywords „Verified“ and „Untrusted“, so far so good.
But what is about incoming connections?
At the moment it is not possible to DANE verify incoming connections.
Future versions DANE versions may support this. I suggested mutual authentication when the DANE WG was re-chartered and the WG accepted it:
http://www.ietf.org/mail-archive/web/dane/current/msg06701.html
p@rick
Yes, now i got it.
It was not designed for client authentication. But what is the problem for Mailserver to Mailserver authentication in both directions?
All well administrated mail system have reverse DNS configured, if that would be DNSSEC secured, perfect! So reverse DNS, then TLSA/DNSSEC plus Certificate validation and everything would be fine for both sides!
But OK.
So I have to test outgoing connections and if I have enabled DANE and DNSSEC and dig gives my an ad flag, my Postfix must tell me if it is Verified or no, even if my DANE isn't running yet, right?
Cheers!
Hey.
Am 15.01.2015 17:39, schrieb Frank fiene:
All well administrated mail system have reverse DNS configured, if that would be DNSSEC secured, perfect! So reverse DNS, then TLSA/DNSSEC plus Certificate validation and everything would be fine for both sides!
You can enable smtpd_tls_ask_ccert which will result in meaningful log entries for incoming connections. Authenticating senders is unfortunately a bit more complicated than looking at DNSSEC secured reverse DNS (you have to match the From-header from the actual mail to have any meaningful authentication, see DKIM).
felix
Frank fiene wrote:
It was not designed for client authentication. But what is the problem for Mailserver to Mailserver authentication in both directions?
Many people do not consider e.g. client certs for authenticating the client to be necessary for establishing the encrypted channel. Also there's currently standard defining how the name check should be done for client certs. IMO client certs could be helpful to fight spam.
All well administrated mail system have reverse DNS configured, if that would be DNSSEC secured, perfect! So reverse DNS, then TLSA/DNSSEC plus Certificate validation and everything would be fine for both sides!
Don't mix different things!
If you're after DNSSEC validation of PTR lookups you could implement a local policy in your DNS resolver like this: If there's a RRSIG RR for a PTR RR and this does not validate correctly then consider the PTR RR to be non-existent. Your MTA would then consider the PTR RR to be not present and apply whatever you've implemented as sender restriction policy for absent reverse lookup.
Ciao, Michael.
On Thu, Jan 15, 2015 at 05:56:21PM +0100, Michael Str?der wrote:
Many people do not consider e.g. client certs for authenticating the client to be necessary for establishing the encrypted channel. Also there's currently standard defining how the name check should be done for client certs. IMO client certs could be helpful to fight spam.
They can't be helpful for that. They can only be helpful for whitelists.
Nobody is going to set the evil bit on their own packets:
https://tools.ietf.org/html/rfc3514
despite the above RFC.
On Thu, Jan 15, 2015 at 05:39:09PM +0100, Frank fiene wrote:
It was not designed for client authentication. But what is the problem for Mailserver to Mailserver authentication in both directions?
All well administrated mail system have reverse DNS configured, if that would be DNSSEC secured, perfect!
It can't be DNSSEC secured. The MiTM attacker can change the apparent IP address of an email stream (source NAT it). Even IPsec won't help, it'll just establish that the source NAT flow is securely coming from the MiTM's IP address.
So reverse DNS, then TLSA/DNSSEC plus Certificate validation and everything would be fine for both sides!
Except that this is useless. It proves nothing about the true origin of the sending entity, nor are PTR records the right name for a client in many cases, as that name space is controlled by the ISP, not the customer.
For client DANE to work with SMTP, it would have to be based on the EHLO name, or some similar name provided in-band via a new SMTP command.
Clients would be free to not send such a name, so these names would not be usable to restrict access, they would only be useful to whitelist.
The apparent symmetry between client and server in "mutual authentication" is mostly an illusion. Authentication of the server protects the channel, while authentication of the client protects the requested resource, and is only useful when the resource supports restricted access, or the protocol support role reversal with the server becoming a client and wanting to know whether the peer is authentic in that new context.
You're getting carried away with an over-simplified security model.
Coming back to my issue with out primary mail relay.
dig gives me the ad flag so my resolving chain should be fine.
; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> +dnssec mail.sys4.de +m ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56266 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;mail.sys4.de. IN A
;; ANSWER SECTION: mail.sys4.de. 3599 IN A 194.126.158.139 mail.sys4.de. 3599 IN RRSIG A 8 3 3600 ( 20150124160722 20150117064917 17338 sys4.de. Tsl3NL+5vhXz4MOHXwSkJcGPjGJmTOl8Xq4R10nv7gfa yy9oimSaVsOeVfQ+FWNOFYV7wL1aoOT+Ltlhgp15hEjx S/RmEL+OHacpD++6cM0f9SiJLi9k+wEHqv+onAEj5tqR 0TpitmXvhBFjEqph+N673gMK3+lNfd/j7kTi1HY= )
But if i send an email to the list, i still get no „Verified“ in my postfix log.
Any suggestions? Frank
Am 20.01.2015 11:48 schrieb Frank Fiene:
dig gives me the ad flag so my resolving chain should be fine. But if i send an email to the list, i still get no „Verified“ in my postfix log.
smtp_dns_support_level = dnssec ? smtp_tls_security_level = dane ?
Yes, exactly this is configured!
Postfix Version 2.11
Am 20.01.2015 um 13:08 schrieb Andreas Schulze andreas.schulze@datev.de:
Am 20.01.2015 11:48 schrieb Frank Fiene:
dig gives me the ad flag so my resolving chain should be fine. But if i send an email to the list, i still get no „Verified“ in my postfix log.
smtp_dns_support_level = dnssec ? smtp_tls_security_level = dane ?
-- Andreas Schulze Internetdienste | P252
DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info@datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70
Vorstand Prof. Dieter Kempf (Vorsitzender) Dr. Robert Mayr (stellv. Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Dr. Peter Krug Jörg Rabe von Pappenheim
Vorsitzender des Aufsichtsrates: Dirk Schmale
Viele Grüße! i.A. Frank Fiene
Andreas Schulze skrev den 2015-01-20 13:08:
Am 20.01.2015 11:48 schrieb Frank Fiene:
dig gives me the ad flag so my resolving chain should be fine. But if i send an email to the list, i still get no „Verified“ in my postfix log.
smtp_dns_support_level = dnssec ? smtp_tls_security_level = dane ?
and in named.conf
dnssec-enable yes; dnssec-lookaside auto; dnssec-validation auto;
2 last options must not be yes, this will disable dane, with auto dane works
in resolv.conf only have nameserver 127.0.0.1
and bind9 must not have any forwarders !
OK, i just have these two:
dnssec-enable yes; dnssec-validation auto;
And i cannot configure this by hand!
Huh!!! No forwarder? So for any DNS query my Resolver must ask the Root-DNS-Servers?
Regards! Frank
Am 20.01.2015 um 13:51 schrieb Benny Pedersen me@junc.eu:
Andreas Schulze skrev den 2015-01-20 13:08:
Am 20.01.2015 11:48 schrieb Frank Fiene:
dig gives me the ad flag so my resolving chain should be fine. But if i send an email to the list, i still get no „Verified“ in my postfix log.
smtp_dns_support_level = dnssec ? smtp_tls_security_level = dane ?
and in named.conf
dnssec-enable yes; dnssec-lookaside auto; dnssec-validation auto;
2 last options must not be yes, this will disable dane, with auto dane works
in resolv.conf only have nameserver 127.0.0.1
and bind9 must not have any forwarders !
Viele Grüße! i.A. Frank Fiene
Am 20.01.2015 14:23 schrieb Frank Fiene:
Huh!!! No forwarder? So for any DNS query my Resolver must ask the Root-DNS-Servers?
sure, that's what root servers are for. but results should be cached, of course.
Are you sure it is a „must not“ not a „should not“.
Because if i ask my DNS with dig for a DNS record, the DO-bit is sent because if not i would not get an answer with an AD flag, right?
Frank
Am 20.01.2015 um 15:18 schrieb Andreas Schulze andreas.schulze@datev.de:
Am 20.01.2015 14:23 schrieb Frank Fiene:
Huh!!! No forwarder? So for any DNS query my Resolver must ask the Root-DNS-Servers?
sure, that's what root servers are for. but results should be cached, of course.
-- Andreas Schulze Internetdienste | P252
DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info@datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70
Vorstand Prof. Dieter Kempf (Vorsitzender) Dr. Robert Mayr (stellv. Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Dr. Peter Krug Jörg Rabe von Pappenheim
Vorsitzender des Aufsichtsrates: Dirk Schmale
Viele Grüße! i.A. Frank Fiene
On Tue, 20 Jan 2015 13:51:04 +0100 Benny Pedersen me@junc.eu wrote:
and in named.conf
dnssec-enable yes; dnssec-lookaside auto; dnssec-validation auto;
2 last options must not be yes, this will disable dane, with auto dane works
The difference is
* "auto" enables validation and the build in trust anchor for the Internet root-dns zone * "yes" enables validation, but the BIND 9 configuration needs to have a trust-anchor manually configured (via "trusted-keys" or "managed-keys" statements)
When using BIND 9 for Internet DNS name resolution, "auto" is the recommended setting. "yes" can be used for lokal, non-Internet trust-anchor or for a local signed copy of the root-zone.
in resolv.conf only have nameserver 127.0.0.1
well, only DNS resolvers that do DNSSEC validation (send the AD flag) reachable over a trusted network.
and bind9 must not have any forwarders !
BIND 9 can have forwarders, but these forwarders should pass the DNSSEC records without changes. If the forwarders strip out data, DNSSEC validation fails.
In general it is recommended to not use forwarders until there is a very good case for it (like no direct connection to the Internet on port 53).
There is nothing wrong with direct iterative name resolution, it is usually faster than using forwarders.
Best regards
Carsten Strotmann
On Tue, Jan 20, 2015 at 11:48:26AM +0100, Frank Fiene wrote:
Coming back to my issue with out primary mail relay.
dig gives me the ad flag so my resolving chain should be fine.
If so, this is now a Postfix question, and should be asked on the postfix-users list. Before posting there, read:
http://www.postfix.org/DEBUG_README.html#mail
Be sure to report the Postfix version, i.e. output of:
postconf -d mail_version
the configuration settings, i.e. output of:
postconf -n
log entries for a delivery showing the problem, showing connection establishment and delivery rcpt, nexthop,
postfix/smtp[samepid]: ... TLS ... postfix/smtp[samepid]: <queue_id>: to=<...> ...
the master.cf entry for the "smtp unix" transport, with recent Postfix releases this is the output of:
postconf -M smtp/unix
smtp unix - - n - - smtp
and if chroot is not disabled (n) for that service:
postmulti -x sh -c 'cat $queue_directory/etc/resolv.conf'
participants (11)
-
Andreas Schulze -
Benny Pedersen -
Carsten Strotmann -
Felix Eckhofer -
Frank fiene -
Frank Fiene
-
Michael Schwartzkopff -
Michael Ströder -
Patrick Ben Koetter -
Peer Heinlein -
Viktor Dukhovni