next up previous
Next: Confidentiality Up: Formalizing Security Services Previous: Integrity

Authentication

Authentication of data is shown by proving that there is integrity over both the data and the source. This can be done directly, as in the AH header where the source IP address is included in the hash-data or indirectly as in the ESP and Mobile-IP headers. Again, if A and B share a secret key, K , for use with a cryptographic hash function H , then if A creates a message xyz where $H_K(x)=z$, on receipt of xyz , B can verify the integrity of x and z by computing $H_K(x)=z$. The important issue is the determination of the correct key K for use with a message. In the case of ESP and the Mobile-IP headers, the key is found by using the source IP address and SPI to find the corresponding entry in the list of security associations. Therefore, even though the source IP address and the SPI are not included in the hash-data, modification to these fields will result in, at best, a bad key and an incorrectly computed hash-value. Directly integrity is provided over the hash-data and indirectly integrity is provided over the source IP address and SPI, therefore, the hash-data is authenticated.

  aPrincipal RECEIVED datagram
  datagram HASH_OK security_association_table
  message_field INDEXED_BY (hash-list datagram)
  sender INDEXED_BY (hash-list datagram)
 ---------------------------------------------
  AUTHEN sender message_field security_association_table aPrincipal 

  aPrincipal RECEIVED (encrypted mobile_reg_datagram)
  (encrypted mobile_reg_datagram) HASH_OK security_association_table
  message_field INDEXED_BY (encrypt-list datagram)
 ---------------------------------------------
  AUTHEN sender message_field security_association_table aPrincipal

Encryption is sometimes incorrectly assumed to provide authentication. It is convenient to assume that if two parties, A and B, use a secret key (symmetric) cipher system, and secret key, K, then messages sent between A and B are also authenticated. We will assume that only A and B have the ability to encrypt/decrypt messages using K. In this case, A may be convinced that if she receives an encrypted message that decrypts correctly using K, and if she did not author the message, then B must have. Indirectly, the fact that only A and B own K supplies authentication. There are several flaws to this reasoning when this scenario is placed in the environment of the Internet. The most obvious flaw is that even though B may have encrypted the message, he did not necessarily send this copy of the message to A at this particular point in time. This type of replay attack is well studied. A second, subtler problem is that it is assumed in the above case that A can identify a correctly decrypted message. If the entity A is a set of algorithms used to provide a service at the IP layer, then this assumption is incorrect. The originally proposed ESP header did not verify the integrity of the cipher text or that decrypted data was meaningful. The ``message'' could in fact consist of random bits. Consequently there was no guarantee at the IP level that the decrypted data was the same data encrypted by the sender. One can argue that higher layers in the protocol stack will detect incorrectly decrypted header information and therefore there is a form of authentication that occurs. This is a poor form of authentication at best, since checks performed at higher levels typically have no cryptographic properties. Further, there is no guarantee that any checks are performed at higher layers. For example, if the decrypted data is passed to a UDP layer, a checksum may not even be used (this is OS kernel configuration, not application dependent).


next up previous
Next: Confidentiality Up: Formalizing Security Services Previous: Integrity