/ Forside / Teknologi / Internet / Sikkerhed / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Sikkerhed
#NavnPoint
stl_s 37026
arlet 26827
miritdk 20260
o.v.n. 12167
als 8951
refi 8694
tedd 8272
BjarneD 7338
Klaudi 7257
10  molokyle 6481
IP-sec og aut. og kryptering ???
Fra : CLAUS HANSEN


Dato : 25-12-01 13:39

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...???

Men er der frit valg mellem alle mulige
authentication-metoder
og
krypterings-metoder ???

Eller fatslægger / begrænser IP-sec det til nogle bestemte metoder...???

Eller er det slet ikke noget IP-sec sætter standarder for ...???
eller hvordan er sammenhængen mellem IP-sec og
authentication + kryptering ???

Jeg vil blive glad, hvis I kan hjælpe mig... jeg ligner et stort
spørgsmålstegn lige nu ?

God jul ....

Med venlig hilsen
CLAUS HANSEN








 
 
Christian E. Lysel (25-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 25-12-01 16:18

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".


Søg
Reklame
Statistik
Spørgsmål : 177552
Tips : 31968
Nyheder : 719565
Indlæg : 6408849
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste