Internet Protocol security architecture: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
No edit summary
mNo edit summary
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{subpages}}
{{PropDel}}<br><br>{{subpages}}
{{TOC-right}}
Both Internet Protocol version 4 and Internet Protocol version 6 can run more securely if features of the Internet Protocol security architecture (IPSec)<ref name=RFC4301>{{citation
{{seealso|communications security}}
Both [[Internet Protocol version 4]] and [[Internet Protocol version 6]] can run more securely if features of the [[Internet Protocol security architecture]] ([[IPSec]])<ref name=RFC4301>{{citation
  | id = RFC4301  
  | id = RFC4301  
  | title = Security Architecture for the Internet Protocol
  | title = Security Architecture for the Internet Protocol
  | author = S. Kent, K. Seo.
  | author = S. Kent, K. Seo
  | date=December 2005
  | date=December 2005
  | url=http://www.ietf.org/rfc/rfc4301.txt}}</ref> are enabled. '''IPv6 security''' can use these features in a way more integrated with regular packet processing than can IPv4, but the basic mechanisms are common.
  | url=http://www.ietf.org/rfc/rfc4301.txt}}</ref> are enabled. '''IPv6 security''' can use these features in a way more integrated with regular packet processing than can IPv4, but the basic mechanisms are common.  


IPv6 has two optional headers, '''authentication header''' and '''encapsulating security payload'''.  The  Authentication Header (AH) offers [[communications security#atomic integrity]] and data origin [[commmunications security#sender authentication]], with optional features, which provide certain aspects of [[communications security#sequential integrity]].<ref name=RFC4302>{{citation
IPv6 has two optional headers, '''authentication header''' and '''encapsulating security payload'''.  The  Authentication Header (AH) offers communications security#atomic integrity|atomic integrity (i.e., an sssurance individual records have not been altered) and data origin communications security#Sender authentication|sender authentication, with optional features, which provide certain aspects of communications security#sequential integrity|sequential integrity.<ref name=RFC4302>{{citation
  | author = Kent, S.  
  | author = Kent, S.  
  | title = IP Authentication Header
  | title = IP Authentication Header
Line 15: Line 13:
  | date = December 2005
  | date = December 2005
  | url = http://www.ietf.org/rfc/rfc4302.txt
  | url = http://www.ietf.org/rfc/rfc4302.txt
}}</ref>
}}</ref> The property of sequential integrity establishes that a sequence of information structures is correct: no record has been deleted, duplication (i.e., "replayed") or deleted. 


The Encapsulating Security Payload (ESP) protocol offers the same set of services, and also offers [[content confidentiality]].<ref name=RFC4303>{{citation
The Encapsulating Security Payload (ESP) protocol offers the same set of services, and also offers communications security#content confidentiality|content confidentiality.<ref name=RFC4303>{{citation
  | author = Kent, S.  
  | author = Kent, S.  
  | title = IP Encapsulating Security Payload (ESP)
  | title = IP Encapsulating Security Payload (ESP)
Line 23: Line 21:
  | date = December 2005
  | date = December 2005
  | url = http://www.ietf.org/rfc/rfc4303.txt
  | url = http://www.ietf.org/rfc/rfc4303.txt
}}</ref> ESP is almost always used in addition to AH, but AH alone can provide some useful functions.  ESP, with its confidentiality features enabled, provides limited traffic flow confidentiality, also called protection against [[traffic analysis]]. Traffic analysis is not always a threat; the relevant [[security policy]] must show a need for it.  
}}</ref> ESP is almost always used in addition to AH, but AH alone can provide some useful functions.  ESP, with its confidentiality features enabled, provides limited traffic flow confidentiality, also called protection against traffic analysis. Traffic analysis is not always a threat; the relevant security policy must show a need for it.  


Both AH and ESP offer mechanism access control, enforced through the  distribution of cryptographic keys and the management of traffic  flows as dictated by the Security Policy Database (SPD). This Database is outside the protocol proper and part of the security infrastructure.
Both AH and ESP offer mechanism access control, enforced through the  distribution of cryptographic keys and the management of traffic  flows as dictated by the Security Policy Database (SPD). This Database is outside the protocol proper and part of the security infrastructure.
Line 46: Line 44:
                         Protected
                         Protected


==Key management==
For security systems that are used rarely, manually configured keys may be adequate. Having manual keys does require the existence of a human-readable copy of the key, which must be strictly protected.


ISAKMP is usually preferred for automated key exchange.
==Establishing the Security Association==
==Establishing the Security Association==
Before any use can be made of AH and ESP, various parameters need to be negotiated, in each direction of transmission, between the source and endpoints. IPSec can establish either point-to-point or point-to-multipoint associations.
Before any use can be made of AH and ESP, various parameters need to be negotiated, in each direction of transmission, between the source and endpoints. The results of these negotiations is a '''security association'''. IPSec can establish either point-to-point or point-to-multipoint associations.
 
The SA contains a precise specification of the encryption and cryptographic hash methods to be used, the keys to be used during this session, and information that keep multiple hosts from establishing an identical SA identifier (i.e., SPI).<ref name=Smith>{{citation
| title = Internet Cryptography
| first = Richard E. | last = Smith
| publisher = Addison-Wesley | year = 1997}}, p. 128</ref>


==Authentication Header==
==Authentication Header==
In the header below, the Security Parameters Index points to a prenegotiated [[Security Association]], which establishes the context in which the other security-related fields of the AH should be validated. It must be possible to find the SPI in the Security Association Database (SAD); its not being present immediately causes the authentication to fail.
In the header below, the Security Parameters Index points to a prenegotiated Security Association, which establishes the context in which the other security-related fields of the AH should be validated. It must be possible to find the SPI in the Security Association Database (SAD); its not being present immediately causes the authentication to fail.


An authenticator, for IPv4, has the value  51 in its Protocol ID or in its IPv6 Next Header. The AH contains the information below.  
An authenticator, for IPv4, has the value  51 in its Protocol ID or in its IPv6 Next Header. The AH contains the information below.  
Line 71: Line 77:


==References==
==References==
{{reflist|2}}
{{reflist|2}}[[Category:Suggestion Bot Tag]]

Latest revision as of 12:00, 2 September 2024

This article may be deleted soon.
To oppose or discuss a nomination, please go to CZ:Proposed for deletion and follow the instructions.

For the monthly nomination lists, see
Category:Articles for deletion.


Both Internet Protocol version 4 and Internet Protocol version 6 can run more securely if features of the Internet Protocol security architecture (IPSec)[1] are enabled. IPv6 security can use these features in a way more integrated with regular packet processing than can IPv4, but the basic mechanisms are common.

IPv6 has two optional headers, authentication header and encapsulating security payload. The Authentication Header (AH) offers communications security#atomic integrity|atomic integrity (i.e., an sssurance individual records have not been altered) and data origin communications security#Sender authentication|sender authentication, with optional features, which provide certain aspects of communications security#sequential integrity|sequential integrity.[2] The property of sequential integrity establishes that a sequence of information structures is correct: no record has been deleted, duplication (i.e., "replayed") or deleted.

The Encapsulating Security Payload (ESP) protocol offers the same set of services, and also offers communications security#content confidentiality|content confidentiality.[3] ESP is almost always used in addition to AH, but AH alone can provide some useful functions. ESP, with its confidentiality features enabled, provides limited traffic flow confidentiality, also called protection against traffic analysis. Traffic analysis is not always a threat; the relevant security policy must show a need for it.

Both AH and ESP offer mechanism access control, enforced through the distribution of cryptographic keys and the management of traffic flows as dictated by the Security Policy Database (SPD). This Database is outside the protocol proper and part of the security infrastructure.

                       Unprotected
                        ^       ^
          +-------------|-------|-------+
| | Discard|<--| V | B +--------+ |
        ................|y..| AH/ESP |..... IPsec Boundary
p +--------+ | IKE|<----|a ^ | s | | s | | Discard|<--| | | | |
          +-------------|-------|-------+
                        V       V
                        Protected

Key management

For security systems that are used rarely, manually configured keys may be adequate. Having manual keys does require the existence of a human-readable copy of the key, which must be strictly protected.

ISAKMP is usually preferred for automated key exchange.

Establishing the Security Association

Before any use can be made of AH and ESP, various parameters need to be negotiated, in each direction of transmission, between the source and endpoints. The results of these negotiations is a security association. IPSec can establish either point-to-point or point-to-multipoint associations.

The SA contains a precise specification of the encryption and cryptographic hash methods to be used, the keys to be used during this session, and information that keep multiple hosts from establishing an identical SA identifier (i.e., SPI).[4]

Authentication Header

In the header below, the Security Parameters Index points to a prenegotiated Security Association, which establishes the context in which the other security-related fields of the AH should be validated. It must be possible to find the SPI in the Security Association Database (SAD); its not being present immediately causes the authentication to fail.

An authenticator, for IPv4, has the value 51 in its Protocol ID or in its IPv6 Next Header. The AH contains the information below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload Len | RESERVED |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  +                Integrity Check Value-ICV (variable)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


References

  1. S. Kent, K. Seo (December 2005), Security Architecture for the Internet Protocol, RFC4301
  2. Kent, S. (December 2005), IP Authentication Header, RFC4302
  3. Kent, S. (December 2005), IP Encapsulating Security Payload (ESP), RFC4303
  4. Smith, Richard E. (1997), Internet Cryptography, Addison-Wesley, p. 128