120 lines
8.2 KiB
HTML
120 lines
8.2 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="Authentication Header" />
|
||
|
|
<meta name="abstract" content="The Authentication Header (AH) protocol provides data origin authentication, data integrity, and replay protection. However, AH does not provide data confidentiality, which means that all of your data is sent in the clear." />
|
||
|
|
<meta name="description" content="The Authentication Header (AH) protocol provides data origin authentication, data integrity, and replay protection. However, AH does not provide data confidentiality, which means that all of your data is sent in the clear." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajaipsec.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="http://www.rfc-editor.org" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajaesp.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajaesp.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2000, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2000, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzajaahheader" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Authentication Header</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzajaahheader"><a name="rzajaahheader"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Authentication Header</h1>
|
||
|
|
<div><p>The Authentication Header (AH) protocol provides data origin authentication,
|
||
|
|
data integrity, and replay protection. However, AH does not provide data confidentiality,
|
||
|
|
which means that all of your data is sent in the clear.</p>
|
||
|
|
<p>AH ensures data integrity with the checksum that a message authentication
|
||
|
|
code, like MD5, generates. To ensure data origin authentication, AH includes
|
||
|
|
a secret shared key in the algorithm that it uses for authentication. To ensure
|
||
|
|
replay protection, AH uses a sequence number field within the AH header. It
|
||
|
|
is worth noting here, that these three distinct functions are often lumped
|
||
|
|
together and referred to as <span class="uicontrol">authentication</span>. In the
|
||
|
|
simplest terms, AH ensures that your data has not been tampered with enroute
|
||
|
|
to its final destination.</p>
|
||
|
|
<p>Although AH authenticates as much of the IP datagram as possible, the values
|
||
|
|
of certain fields in the IP header cannot be predicted by the receiver. AH
|
||
|
|
does not protect these fields, known as <span class="uicontrol">mutable</span> fields.
|
||
|
|
However, AH always protects the payload of the IP packet.</p>
|
||
|
|
<p>The Internet Engineering Task Force (IETF) formally defines AH in Request
|
||
|
|
for Comment (RFC) 2402, <cite>IP Authentication Header</cite>. You can view
|
||
|
|
this RFC on the Internet at the following Web site: http://www.rfc-editor.org.</p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Ways of using AH</h4><p>You can apply AH in two ways: transport
|
||
|
|
mode or tunnel mode. In transport mode, the IP header of the datagram is the
|
||
|
|
outermost IP header, followed by the AH header and then the payload of the
|
||
|
|
datagram. AH authenticates the entire datagram, except the mutable fields.
|
||
|
|
However, the information contained in the datagram is transported in the clear
|
||
|
|
and is, therefore, subject to eavesdropping. Transport mode requires less
|
||
|
|
processing overhead than tunnel mode, but does not provide as much security.</p>
|
||
|
|
<p>Tunnel
|
||
|
|
mode creates a new IP header and uses it as the outermost IP header of the
|
||
|
|
datagram. The AH header follows the new IP header. The original datagram (both
|
||
|
|
the IP header and the original payload) comes last. AH authenticates the entire
|
||
|
|
datagram, which means that the responding system can detect whether the datagram
|
||
|
|
changed while in transit.</p>
|
||
|
|
<p>When either end of a security association
|
||
|
|
is a gateway, use tunnel mode. In tunnel mode the source and destination addresses
|
||
|
|
in the outermost IP header do not need to be the same as those in the original
|
||
|
|
IP header. For example, two security gateways may operate an AH tunnel to
|
||
|
|
authenticate all traffic between the networks they connect together. In fact,
|
||
|
|
this is a very typical configuration.</p>
|
||
|
|
<p>The main advantage to using tunnel
|
||
|
|
mode, is that tunnel mode totally protects the encapsulated IP datagram. In
|
||
|
|
addition, tunnel mode makes it possible to use private addresses.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Why AH?</h4><p>In many cases, your data only requires authentication.
|
||
|
|
While the Encapsulating Security Payload (ESP) protocol can perform authentication,
|
||
|
|
AH does not affect your system performance as does ESP. Another advantage
|
||
|
|
of using AH, is that AH authenticates the entire datagram. ESP, however, does
|
||
|
|
not authenticate the leading IP header or any other information that comes
|
||
|
|
before the ESP header.</p>
|
||
|
|
<p>In addition, ESP requires strong cryptographic
|
||
|
|
algorithms in order to be put into effect. Strong cryptography is restricted
|
||
|
|
in some regions, while AH is not regulated and can be used freely
|
||
|
|
around the world.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><img src="./delta.gif" alt="Start of change" /><h4 class="sectiontitle">Using ESN with AH</h4><p>If you use the AH protocol
|
||
|
|
then you might want to enable Extended Sequence Number (ESN). ESN allows you
|
||
|
|
to transmit large volumes of data at a high speed with out re-keying. The
|
||
|
|
VPN connection uses a 64-bit sequence numbers instead of 32-bit numbers over
|
||
|
|
IPSec. Using 64-bit sequence numbers allows more time before re-keying, which
|
||
|
|
prevents sequence number exhaustion and minimizes the use of system resources.</p>
|
||
|
|
<img src="./deltaend.gif" alt="End of change" /></div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">What algorithms does AH use to protect my information?</h4><p>AH
|
||
|
|
uses algorithms known as <span class="uicontrol">hashed message authentication codes (HMAC).</span> Specifically,
|
||
|
|
VPN uses either HMAC-MD5 or HMAC-SHA. Both MD5 and SHA take variable-length
|
||
|
|
input data and a secret key to produce fixed-length output data (called a
|
||
|
|
hash value). If the hashes of two messages match, then it is very likely that
|
||
|
|
the messages are the same. Both MD5 and SHA encode the message length in their
|
||
|
|
output, but SHA is regarded as more secure because it produces larger hashes.</p>
|
||
|
|
<p>The
|
||
|
|
Internet Engineering Task Force (IETF) formally defines HMAC-MD5 in Request
|
||
|
|
for Comments (RFC) 2085, <cite>HMAC-MD5 IP Authentication with Replay Prevention</cite>.
|
||
|
|
The Internet Engineering Task Force (IETF) formally defines HMAC-SHA in Request
|
||
|
|
for Comments (RFC) 2404, <cite>The Use of HMAC-SHA-1-96 within ESP and AH</cite>.
|
||
|
|
You can view these RFCs on the Internet at the following Web site: http://www.rfc-editor.org.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzajaipsec.htm" title="IPSec provides a stable, long lasting base for providing network layer security.">IP Security (IPSec) protocols</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="rzajaesp.htm" title="The Encapsulating Security Payload (ESP) protocol provides data confidentiality, and also optionally provides data origin authentication, data integrity checking, and replay protection.">Encapsulating Security Payload</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
||
|
|
<div><a href="http://www.rfc-editor.org" target="_blank">http://www.rfc-editor.org</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|