[fi-rg] [Fvga-wg] New document on a protocol specificatin for dynamicopening of firewall ports

Thu Mar 5 08:04:40 CST 2009

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 