Re: VPN using aggressive mode

From: Ranjeet Shetye (ranjeet.shetye2_at_zultys.com)
Date: 11/21/03

  • Next message: John Sm: "Information Security Presentations."
    To: Kevin Saenz <ksaenz@spinaweb.com.au>
    Date: Fri, 21 Nov 2003 13:58:02 -0800
    
    

    On Fri, 2003-11-21 at 02:29, Kevin Saenz wrote:
    > I have been advised that and VPN using aggressive mode is
    > vulnerable due to the ability of seeing a lot of clear text.
    > Can anyone tell me what if aggressive mode using 3des and shar1
    > for phase1 and 3des and shar1 for phase2 mean anything when it
    > comes to security.
    > At the moment my understanding is that phase1 and phase2 means
    > squat when you are using aggressive mode. Someone could get your
    > passphrase and spoof your address if they really wanted your
    > data.

    1. Phase 1 sets up a secure channel for the IKE gateways to talk to each
    other. Done using one of two modes: Main Mode or Aggressive Mode.

    2. Phase 2 sets up a secure channel for IPSec traffic to for the traffic
    flow between the two endpoints - via the two IKE(IPSec) gateways. Also
    called Quick Mode.

    3. Your pre-shared secret (which is what I think you are referring to by
    passphrase) never goes out so no one will ever see it. If by passphrase,
    you are referring to a passphrase to unlock your private key to use
    X.509 certs for IKE, dont worry either - the passphrase is only used
    locally. There is NO place in the IKE or IPSec protocols for
    transmitting any passphrase/password/preshared-secret as a part of the
    negotiations - hence it CANNOT be transmitted. Authentication in
    pre-shared case happens using Diffie-Hellman (DH) which is used to
    verify local accessability to the pre-shared key. This key, along with
    other inputs and a nonce, undergoes a mathematical transformation using
    DH to come up with a number that both parties exchange to verify that
    the other party has access to the secret.

    4. Now, an IKE ID does NOT have to be an IP address, it can be a
    USER_FQDN id which MUST be RFC822 compliant .e.g
    ranjeet.shetye@zultys.com .

    Main Mode negotiation has 6 messages.
    Client -> Server
    Server -> Client
    Client -> Server
    Server -> Client
    Client -> Server
    Server -> Client

    Aggressive Mode has 3 messages.
    Client -> Server
    Server -> Client
    Client -> Server

    (note: client just means the party that initiated the exchange - could
    be another VPN gateway, not just a laptop).

    In Main mode, the Diffie-Hellman exchange (messages 3 and 4 in Main
    Mode) leads to the creation of encryption keys for the Phase 1 (ONE)
    channel, and these keys are used to protect the Identity-exchange
    (messages 5 and 6 in Main Mode). This protection is absent in Aggressive
    mode and hence the Phase 1 (ONE) IDs being exchanged are visible.

    e.g. In Main mode, you would see messages from my client laptop IP go to
    the IKE server, but you would not be able to see that the ID being used
    for Phase1 is ranjeet.shetye@zultys.com . In Aggressive mode, this ID
    can be viewed cos the seperate stages are "squashed" together and hence
    the IDs cannot be protected by encryption.

    Irrespective of all this, ALL phase 1s are secure, and ALL phase 2s are
    secure. I would not worry about the cleartext transmission of the ID -
    it IS leakage of information and to be "worried" about from the
    standpoint of someone designing a protocol or an architecture, but its
    implications for a lay user are not so great.

    Personally, I prefer using only Main mode. In my opinion, Aggressive
    mode is a necessary hack to the lousy/ugly IKE protocol.

    Coming back to your question:
    1. No, your passphrase CANNOT be transmitted at all by IKE. Dont worry.
    2. Spoofing your IP can happen irrespective of IKE/IPSec etc. Worry in
    general context, not IKE specific context.

    -- 
    Ranjeet Shetye
    Senior Software Engineer
    Zultys Technologies
    Ranjeet dot Shetye2 at Zultys dot com
    http://www.zultys.com/
     
    The views, opinions, and judgements expressed in this message are solely
    those of the author. The message contents have not been reviewed or
    approved by Zultys.
    ---------------------------------------------------------------------------
    ----------------------------------------------------------------------------
    

  • Next message: John Sm: "Information Security Presentations."

    Relevant Pages

    • Re: NAT-T and L2TP
      ... I have already applied the update from q818043 to the w2k client ... IKE security association negotiation failed. ... > W2003 server. ...
      (microsoft.public.win2000.ras_routing)
    • Re: IKE security association negotiation failed
      ... I have the VPN server in my ... Nothing is going back out - net mon on client and server. ... > title is "IKE security association negotiation failed". ... > IKE Peer Addr ...
      (microsoft.public.isa.vpn)
    • Re: Problem with certificates/L2TP VPN
      ... of RRAS server. ... The client IS behind NAT. ... UDP 500 - for IKE ... Certificate based Identity. ...
      (microsoft.public.windows.server.networking)
    • Re: Problem with certificates/L2TP VPN
      ... Looks like your are doing the right things, maybe the next test would be to run with IKE auditing switched on. ... Are you 100% sure authentication, encryption and key change are the same for both systems? ... EKU on client contains: Client Authentication ... EKU on server contains: Server Authentication ...
      (microsoft.public.windows.server.networking)
    • Re: What doesnt lend itself to OO?
      ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
      (comp.object)