Stephen Hanna writes: > I have posted a new version of the AD VPN Problem > Statement that adds clarifying text to requirements > 6 and 7, as suggested by Tero. Please review and > comment. Is everyone (especially Tero) OK with the > new text?
Those requirement 6 and 7 seems to be ok, but I am still bit concerned about the requirement 5. It seems to be bit too strict, and will forbid all kind of trusted 3rd party where the trusted 3rd party is any of the ADVPN peers. This of course rules out that temporary credentials cannot be any kind of shared secrets given out by the spoke, but it also forbids the spoke to act as introductioner and sending for example the hash of the end-points public key to the other end-point, and saying this public key hash matches that peer. The requirement 5 is: ---------------------------------------------------------------------- 5. One ADVPN peer MUST NOT be able to impersonate another ADVPN peer. This requirement is driven by use case 2.1. ADVPN peers (especially spokes) become compromised fairly often. The compromise of one ADVPN peer SHOULD NOT affect the security of other peers. ---------------------------------------------------------------------- If endpoint receives any kind of intrduction, or credential information from any other node from the ADVPN, that means that the node giving that information out can impersonate that other ADVPN peer. I.e. if endpoint A asks from spoke or hub S how endpoint B is authenticated, and where it is located, so it can take direct connection to it, the compromised spoke or hub S can provide incorrect credentials for the endpoint A claiming endpoint A's public key is Sp instead Bp, and do the same for endpoint B. It can also claim that endpoint B is located in his ownIP-address, so when endpoint A tries to move to point-to-point communication mode, it actually still goes through the S, as S can impersonate to be the other end. If the requirement 5 stays as it is, the only way I can think how authentication can be done is by using some other 3rd party which is not ADVPN peer. I think what is tried to be said here, is that any of the ADVPN peers MUST NOT have a way to get the long term authentication credentials for any othe ADVPN peers. The ADVPN peer giving out some kind of temporary authentication credentials, or providing information to other ADVPN peers how to authenticate some other ADVPN peer can still give out false information and cause possibility for ADVPN peer to impersonate some other ADVPN peer. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
