CLAUS HANSEN wrote:
Hejsa Claus, hvad skal du bruge alle disse spørgsmål til?
> Jeg har forstået, at en løsning som kører IP-sec,
> kan man altid individuelt bestemme hvilken
> authentication + kryptering man vil vælge...???
Nej. Der er dog et udvalg man kan vælge imellem.
For at se et minimum se nedestående bilag, afsnit 5.
Med individuelt, mener du for hver individuelle VPN forbindelse? Hvis
ja, så er svaret ja.
> Men er der frit valg mellem alle mulige
> authentication-metoder
> og
> krypterings-metoder ???
Se afsnit 3.2.1 og 3.2.2
> Eller fatslægger / begrænser IP-sec det til nogle bestemte metoder...???
Ja.
> Eller er det slet ikke noget IP-sec sætter standarder for ...???
IPSec snakker om compliance løsninger, dvs. mindste krav der skal være
opfyldt for at man kan snakke om at det er en IPSec løsning, dvs. at
forskellige producenter kan snakke sammen.
Endvidere er der en test side, hvor man kan teste om ens IPSec løsning
er compliance,
http://ipsec-wit.antd.nist.gov/ (dog virker linket ikke
lige nu)
> eller hvordan er sammenhængen mellem IP-sec og
> authentication + kryptering ???
Det er valgbart, man kan godt kører med authentication og ingen kryptering.
Hvis du vil læse mere er
http://sunsite.dk/RFC/rfc/rfc2401.html et
udmærket sted at starte, afsnit 3.
Bilag fra RFC 2406:
3.2.1 Encryption Algorithms
The encryption algorithm employed is specified by the SA. ESP is
designed for use with symmetric encryption algorithms. Because IP
packets may arrive out of order, each packet must carry any data
required to allow the receiver to establish cryptographic
synchronization for decryption. This data may be carried explicitly
in the payload field, e.g., as an IV (as described above), or the
data may be derived from the packet header. Since ESP makes
provision for padding of the plaintext, encryption algorithms
employed with ESP may exhibit either block or stream mode
characteristics. Note that since encryption (confidentiality) is
optional, this algorithm may be "NULL".
3.2.2 Authentication Algorithms
The authentication algorithm employed for the ICV computation is
specified by the SA. For point-to-point communication, suitable
authentication algorithms include keyed Message Authentication Codes
(MACs) based on symmetric encryption algorithms (e.g., DES) or on
one-way hash functions (e.g., MD5 or SHA-1). For multicast
communication, one-way hash algorithms combined with asymmetric
signature algorithms are appropriate, though performance and space
considerations currently preclude use of such algorithms. Note that
since authentication is optional, this algorithm may be "NULL".
5. Conformance Requirements
Implementations that claim conformance or compliance with this
specification MUST implement the ESP syntax and processing described
here and MUST comply with all requirements of the Security
Architecture document. If the key used to compute an ICV is manually
distributed, correct provision of the anti-replay service would
require correct maintenance of the counter state at the sender, until
the key is replaced, and there likely would be no automated recovery
provision if counter overflow were imminent. Thus a compliant
implementation SHOULD NOT provide this service in conjunction with
SAs that are manually keyed. A compliant ESP implementation MUST
support the following mandatory-to-implement algorithms:
- DES in CBC mode [MD97]
- HMAC with MD5 [MG97a]
- HMAC with SHA-1 [MG97b]
- NULL Authentication algorithm
- NULL Encryption algorithm
Since ESP encryption and authentication are optional, support for the
2 "NULL" algorithms is required to maintain consistency with the way
these services are negotiated. NOTE that while authentication and
encryption can each be "NULL", they MUST NOT both be "NULL".