Easiest IPSEC Auth. to implement?

RZetlinRZetlin Inactive Imported Users Posts: 155
More questions I can't figure out.

Contoso Company has not implemented IPSEC because their business does not normally require it. However, two of the employee researchers are doing highly classified research and development on future technology for the company and have a need to transfer files between themselves. If the files are intercepted, they must not be read. IPSEC is the obvious solution, however, the network administrator has no training in IPSEC and prefers to not get involved. What authentication method for IPSEC would involve the least administration burden?
a. Certificate Authority
b. preshared secret key
c. public/private key exchange
d. Windows 2000 Active Directory/Kerberos


Certicates and keys are out because of the work required.

This brings down to two choices: Preshared secret key or Kerberos.

Though with the secret key if the files are intercepted can they be read?

Comments

  • SlowhandSlowhand MCSE: Cloud Platform and Infrastructure, MCSA: Windows Server 2003/2012/2016, CCNA Routing & Switchi Bay Area, CaliforniaMod Posts: 5,163 Mod
    In this case, Kerberos is the best solution to the problem, within the parameters given. It's easy to understand, fairly secure, and requires almost no adminstrative work to put into place. As for the encryption, to ensure that files can't be read, that is taken care of by IPSec, itself, in ESP mode.

    Free Microsoft Training: Microsoft Learn
    Free PowerShell Resources: Top PowerShell Blogs
    Free DevOps/Azure Resources: Visual Studio Dev Essentials

    Let it never be said that I didn't do the very least I could do.
  • DragonNOA1DragonNOA1 Member Posts: 149 ■■■□□□□□□□
    Isn't Kerberos an Authentication type requiring a trusted third party, ie a KDC? In that case I would go with a preshared secret key. No Admin overhead at all. Secret Keys = symmetric = AES which is secure.
    The command line, an elegant weapon for a more civilized age
  • RTmarcRTmarc Member Posts: 1,082 ■■■□□□□□□□
    I seriously doubt it would be pre-shared keys. Microsoft frowns upon pre-shared keys as they are considered "administrative overhead". The problem is you would have to hardcode the key on every machine.

    In this situation and with the details given, I would have to agree with the Kerberos answer. As stated, IPSec will take care of the encryption and integrity.
  • DragonNOA1DragonNOA1 Member Posts: 149 ■■■□□□□□□□
    Ah, gotchya. Reading the last line says what authent. system. After what everyone has said I would go with Kerberos also.
    The command line, an elegant weapon for a more civilized age
  • blargoeblargoe Self-Described Huguenot NC, USAMember Posts: 4,174 ■■■■■■■■■□
    AD/Kerberos
    IT guy since 12/00

    Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
    Working on: RHCE/Ansible
    Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...
  • Danman32Danman32 Member Posts: 1,243
    DragonNOA1 wrote:
    Isn't Kerberos an Authentication type requiring a trusted third party, ie a KDC? In that case I would go with a preshared secret key. No Admin overhead at all. Secret Keys = symmetric = AES which is secure.

    In case you didn't know, AD operates under Kerberos. Each DC is a KDC.

    Secret keys/symmetric by itself is not considered secure, since the keys can be stolen. Also, if dealing with multiple parties, you may need an entire ring of keys.
  • DragonNOA1DragonNOA1 Member Posts: 149 ■■■□□□□□□□
    Danman32 wrote:
    In case you didn't know, AD operates under Kerberos. Each DC is a KDC.

    Secret keys/symmetric by itself is not considered secure, since the keys can be stolen. Also, if dealing with multiple parties, you may need an entire ring of keys.

    Yes yes. I read the question wrong. Sorry guys. icon_eek.gif
    The command line, an elegant weapon for a more civilized age
Sign In or Register to comment.