Electrical computers and digital processing systems: support – Multiple computer communication using cryptography – Packet header designating cryptographically protected data
Reexamination Certificate
1999-10-21
2004-09-21
Peeso, Thomas R. (Department: 2766)
Electrical computers and digital processing systems: support
Multiple computer communication using cryptography
Packet header designating cryptographically protected data
C713S152000
Reexamination Certificate
active
06795917
ABSTRACT:
This invention concerns the authentication of data packets in a digital data transfer network. Specifically the invention concerns the authentication in a network where transformations are performed on packets while they are in transit, which renders the use of prior art authentication methods difficult or impossible.
Internet security has received major scientific and commercial attention in recent years due to the vast growth of the Internet and the rapidly increasing number of organizations joining the network. The network has become a critical part of the operation of many commercial organizations. Commercial exploitation of the Internet is being severely limited by security problems in existing Internet protocols, and improving Internet security is thus imperative.
The IP security protocol (IPSEC) is being standardized by the IETF (Internet Engineering Task Force) for adding security to the IP protocol. It provides cryptographic authentication and confidentiality of traffic between two communicating network nodes. It can be used in both end-to-end mode, directly between the communicating nodes or hosts, or in tunnel mode between firewalls or VPN (Virtual Private Network) devices. Asymmetric connections, where one end is a host and the other end is a firewall or VPN are also possible.
IPSEC performs authentication and encryption on packet level by adding new protocol headers to each packet. IPSEC authentication is performed by computing an authentication code over all data and most of the header of the data packet. The authentication code further depends on a secret key, known only to the communicating parties. The authentication code is then stored in the packet, appropriately wrapped in a well-defined header or trailer.
The secret key for authentication can be configured manually for each pair of communicating hosts. However, in practice, special key management protocols are used to dynamically generate and exchange the secret keys. In IPSEC, the standard protocol for doing this is called the ISAKMP/Oakley protocol, where ISAKMP means Internet Security Association Key Management Protocol.
IPSEC authentication protection includes the source and destination addresses of the packet, which means that they can not be changed en route if the authentication code is to remain valid. However, many organizations currently use private IP addresses within their own organization, and translate the private addresses to globally unique addresses at an external gateway (e.g. router or firewall). This process is called network address translation (NAT). Such translation typically involves changing both IP addresses and TCP or UDP port numbers.
A NAT device
100
in
FIG. 1
takes in packets
101
transmitted by a transmitting node
102
in an internal private network
103
. It converts the IP addresses and port numbers in these packets from those belonging to an internal, private address space to globally unique external Internet addresses in outgoing packets
104
before sending the packets through the external network
105
to a receiving node
106
. The address conversion takes place on the other way round for packets that go across the NAT device
100
in the other direction. Typically, a NAT
100
will map IP address and port combinations to different IP address and port combinations. The mapping will remain constant for the duration of a network connection, but may change (slowly) with time. In practice, NAT functionality is often integrated into a firewall or router.
Furthermore, there are other types of devices on the Internet that may legally modify packets as they are transmitted. A typical example is a protocol converter, whose main job is to convert the packet to a different protocol without disturbing normal operation. Using them leads to problems very similar to the NAT case. A protocol converter converts packets from one protocol to a different protocol. A fairly simple but important example is converting between IPv4 and Ipv6, which are different versions of the Internet Protocol. Such converters will be extremely important and commonplace in the near future. A packet may undergo several conversions of this type during its travel, and it is possible that the endpoints of the communication actually use a different protocol. Like NAT, protocol conversion is often performed in routers and firewalls. The layout of an IPv4 packet header is illustrated in
FIG. 2
, and the layout of an IPv6 packet header in FIG.
3
. Column numbers in
FIGS. 2 and 3
correspond to bits.
In
FIG. 2
, the fields of the known IPv4 header are as follows: Version Number
201
, IHL
202
, Type of Service
203
, Total Length
204
, Identification
205
, Flags
206
, Fragment Offset
207
, Time to Live
208
, Protocol
209
, Header Checksum
210
, Source Address
211
, Destination Address
212
, Options
213
and Padding
214
. In
FIG. 3
, the fields of the known proposed IPv6 header are as follows: Version Number
301
, Traffic Class
302
, Flow Label
303
, Payload Length
304
, Next Header
305
, Hop Limit
306
, Source Address
307
and Destination Address
308
. The use of the fields in the headers is known to the person skilled in the art. An IP packet consists of a header like that of
FIG. 2
or
3
accompanied by a data portion. In IPv6, there may be a number of so-called Extension headers between the main header shown in FIG.
3
and the data portion.
The security features desired of a network security protocol include authenticity (the packet was actually sent by the node it claims to have been sent by), integrity (the packet was not modified in transit), non-repudiation (the sending node cannot deny having sent the packet) and privacy (no third party can read the contents of the packet). In the IPSEC protocol, authenticity, integrity, and non-repudiation are achieved by having a shared secret key that is used to authenticate each packet. The authentication is performed by computing a message authentication code (MAC) using the contents of the packet and the shared secret, and sending the computed MAC as a part of the packet in an AH (Authentication Header) or ESP (Encapsulating Security Payload) header. Privacy is typically implemented using encryption, and the ESP header is used. The AH header is illustrated in
FIG. 4
, where column numbers correspond to bits. The fields of the known AH header are as follows: Next Header
401
, Length
402
, Reserved
403
, Security Parameters
404
and Authentication Data
405
. The length of the last field
405
is a variable number of 32-bit words.
The Encapsulating Security Payload (ESP) may appear anywhere in an IP packet after the IP header and before the final transport-layer protocol. The Internet Assigned Numbers Authority has assigned Protocol Number
50
to ESP. The header immediately preceding an ESP header will always contain the value 50 in its Next Header (IPv6) or Protocol (IPv4) field. ESP consists of an unencrypted header followed by encrypted data. The encrypted data includes both the protected ESP header fields and the protected user data, which is either an entire IP datagram or an upper-layer protocol frame (e.g., TCP or UDP). A high-level diagram of a secure IP datagram is illustrated in
FIG. 5
a
, where the fields are IP Header
501
, optional other IP headers
502
, ESP header
503
and ecrypted data
504
.
FIG. 5
b
illustrates the two parts of an ESP header, which are the 32-bit Security Association Identifier (SPI)
505
and the Opaque Transform Data field
506
, whose length is variable.
There are several ways of computing a MAC, well known in the literature. One commonly used method is computing a keyed cryptographic hash function (e.g. HMAC-SHA1) over the data to be authenticated, using the shared secret as the key.
We will call authenticity, integrity, and non-repudiation of packets jointly as packet authentication. In IPSEC, this function is achieved by computing a message authentication code (MAC) for the packet at the sending node, including the computed message authentication code with the packet in an AH or ESP hea
Fish Ronald C.
Peeso Thomas R.
Ronald Craig Fish A Law Corp.
SSH Communications Security LTD
LandOfFree
Method for packet authentication in the presence of network... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for packet authentication in the presence of network..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for packet authentication in the presence of network... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3256565