From r.niederberger at fz-juelich.de Thu Mar 5 08:04:40 2009 From: r.niederberger at fz-juelich.de (Ralph Niederberger) Date: Thu, 05 Mar 2009 15:04:40 +0100 Subject: [fi-rg] [Fvga-wg] New document on a protocol specificatin for dynamicopening of firewall ports Message-ID: <49AFDBF8.6040106@fz-juelich.de> Dear Gian Luca, comments inside. Thanks a lot. Gian Luca Volpato schrieb: > Dear All, > > I would like to share with you some comments and thoughts about the > latest version of our FiTP document. > > First some questions about the conceptual design of FiTP: > - the use of SSH-NONE with HMAC cipher protocol guarantees that > messages cannot be modified while transferred from the user-CH to the > auth-CH. However only user-CH and auth-CH can verify the integrity of > the messages; firewalls along the communication path have no > possibility to verify message integrity. > Is there any risk that an attacker modifies an FiTP command or an FiTP > reply with the purpose of deceiving an FiTP-aware firewall and making > it to enforce an unauthorized access rule? > If this is the case we should consider the possibility to sign message > digests with the private key of the sender instead of with the secret > key shared between user-CH and auth-CH. > in principle you are right with your argumentations. But the idea is that the receiver of the packets acknowleges every request, sending again the request back to the client which asked for access. So if there is an intruder who modifies the packet, the receiver, i.e. authentication server; will respond with a negative reply. Let's assume the path is symmetric: If the intruder hacks the packet before the firewall, let us assume he changes the port range to be opened, the destination server would send a negative acknowlegement to the source, since HMAC shows that the packet was changed. Since the intruder is on the path outside before the firewall, he cannot change the acknowledgement packet. So the firewall recognizes the negative response. If the intruder hacks the packet on the path after the packet traverses the firewall, i.e. inside the local destination domain, the firewall knows about the original port range request. So independent of the intruder only the right port range could be opened. But this would not work, since again the destination server sends a negative response, since he detects the hacked packet. So if the firewall only opens the ports after the packets have been acknowledged, there is no insecurity. Let's assume furtheron the hacker also modifies the NACK packet sent by the destination server before it traverses the firewall on its way back to the client. So the firewall would see a request and a positive acknowledgement. But again the client would see that the potential ACK packet was hacked. Then he would close the control connection and this would imply closing all data connection requests already received by the firewall. > - what happens when the auth-PI crashes? > During the restart operation, are all granted rules invalidated and > accordingly are commands to FiTP-unaware firewalls sent? > This should happen because an FiTP-unaware firewall cannot understand > that a major failure (closing) on the control connection implies > deleting all access grants. > An FiTP aware firewall closes all data sessions when the control connection dies. For an FiTP unaware firewall you are right, that we need to have some checkpoints where we can setup again. So at least we need a mechanism for invalidating open ports. So this could be a table where all ports opened by FiTP are stored. Then those entries could be checked and discarded. Thanks for the hint, we have to think about a good solution. > > And now some minor remarks on the document: > - page 6, definition of access-rule: why in the case of IP or IPSEC > protocol are sport1,sport2,dport1,dport2 ignored? IP doesn't have ports. Ports are on layer 4 of the ISO/OSI protocol. > - page 8, the definition of user-CH is missing I will include this. Thanks > - page 11, in the definition of the command syntax > "[4_digit_message_code],GAcR,Auth,[textstring"]: what is the meaning > of parameter "Auth" ? This was a fragment coming from cut and paste. Already delete in Document Version 2.7.1 > > - page 15, in the structure of FiTP reply codes: why do we define > reply codes 1xyz and 2xyz and then we never explain nor use them in > the document? That is a historical reason. I first thought about implemnting all things itself. So we would have needed a "Key Exchange Phase" and a "Authentication and AUthorization Phase". Later on there came up the idea of using SSH NONE Cipher doing this already. So in principle, you are right, this coul be deleted. I would like to wait for the discussions going on, if we should go the way using SSH protocol. If this will be the way we will delete those entries. Otherwise we will need those phases and codes. > - page 20, in the command "9000,PathCntl,Encrypted(9000,PathCntl)": > what is the meaning of the parameter "Encrypted(9000,PathCntl)" ? > > Same answer as above. First I thought to do the HMAC itself, sending any command also encrypted for crosschecking by receiver. We do not need it anymore. This is a fragment from the old version, which has been deleted in Doc vers. 2.7.1 already. Sorry for that, but I assume there are a lot of other typos left. > I wish you a very useful FVGA session at OGF25. > Kind regards > /Gian Luca > Thanks a lot for reading and checking the document. We will let you know about any new thnigs coming up tomorrow. Best regards Ralph > ------------------------------------------------------------------------ > > _______________________________________________ > fvga-wg mailing list > fvga-wg at ogf.org > http://www.ogf.org/mailman/listinfo/fvga-wg > -- *************************************************** Ralph Niederberger Juelich Supercomputing Centre Institute for Advanced Simulation Phone: +49 2461 61-4772 Fax: +49 2461 61-6656 E-Mail: r.niederberger at fz-juelich.de WWW: http://www.fz-juelich.de/jsc/ JSC is the coordinator of the John von Neumann Institute for Computing and member of the Gauss Centre for Supercomputing *************************************************** Forschungszentrum J?lich GmbH 52425 J?lich Sitz der Gesellschaft: J?lich Eingetragen im Handelsregister des Amtsgerichts D?ren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in B?rbel Brumme-Bothe Gesch?ftsf?hrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt *************************************************** -- *************************************************** Ralph Niederberger Juelich Supercomputing Centre Institute for Advanced Simulation Phone: +49 2461 61-4772 Fax: +49 2461 61-6656 E-Mail: r.niederberger at fz-juelich.de WWW: http://www.fz-juelich.de/jsc/ JSC is the coordinator of the John von Neumann Institute for Computing and member of the Gauss Centre for Supercomputing *************************************************** Forschungszentrum J?lich GmbH 52425 J?lich Sitz der Gesellschaft: J?lich Eingetragen im Handelsregister des Amtsgerichts D?ren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in B?rbel Brumme-Bothe Gesch?ftsf?hrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt *************************************************** -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Nachrichtenteil als Anhang Url: http://www.ogf.org/pipermail/fi-rg/attachments/20090305/7f5cbc65/attachment-0001.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5143 bytes Desc: S/MIME Cryptographic Signature Url : http://www.ogf.org/pipermail/fi-rg/attachments/20090305/7f5cbc65/attachment-0001.bin