[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

No Subject



	It will see either an Authentication Header:

+--------+--------+---------+---------+
|Nxt Plod| Length |  Reserved         | 
+--------+--------+---------+---------+
|	Security Association ID	      |	(32 bits)
+--------+--------+---------+---------+
| Auth data (variable length)         |	
|                                     | 
|                                     | (variable size, random binary data)
+--------+--------+---------+---------+  


	or a Security Header:

+--------+--------+---------+---------+
|	Security Association ID	      |	(32 bits)
+--------+--------+---------+---------+
| Secure data (variable length)       |	
|                                     | 
|                                     | (variable size, random binary data)
+--------+--------+---------+---------+  


I make the following observations:

1) The Auth data length is limited to the range 0 - 255

2) The Security payload *MUST* be the last and *ONLY* Security Payload in 
   the packet since there is no cleartext Next Payload field.

3) If the "Authentication" Header were to have its length field extended to 
   16 or 24 bits this would allow a larger amount of variable binary data 
   which could be used for Authentication, Security or both.  
   Further, more than one Secure Payload could be carried in a packet if 
   required and it need not be last payload.

   The interpretation of the variable length binary data is be controlled 
   by the SAID.  The receiver uses the SAID as an index or key into an 
   array of records which contain information which enable the received data
   to be interpreted.  The records would indicate:

	The security mechanisms to be used (DES, MD5 etc)
	The data required by those mechanisms (keys etc)
	How the mechanisms are to be applied to the data (order of mechanism 
          application, range of data to be processed, location of 
	  Algorithm-dependent init stuff etc)
	How the security processed data is to be interpreted after processing
	  (Authentication, protected data packet e.g.:

Security Processed Data:

+--------+--------+---------+---------+
|Next Hdr| Length |  Reserved         | (8/8/16 bits; per usual IPv6 practice)
+--------+--------+---------+---------+
| TCP/UDP payload or header indicated |
+                                     | (variable size)
| by Next Hdr value above             |
+--------+--------+---------+---------+
| Algorithm-dependent trailing stuff  | (variable size, would put padding
+--------+--------+---------+---------+  for block-mode algorithms here, etc)

 
Thus the SAID can be used by the receiver to differentiate between
Authentication and other uses of the data.  In some cases several uses may
be optimised such as the case when pairwise unique secret keys are used for
encryption.  This may give both Authentication and Confidentiality in one
go. 

The records at the receiver (and sender) corresponding to the SAIDs must be 
complete for the security functionality to work.  The information may be 
placed in a number of different ways:

	o Pre-defined in a RFC standard and compiled in,
	o Loaded locally (floppy disk, smart card? etc)
	o Set up in some on-line management exchange (ICMP-like or DNS lookup).  
	  The DNS will most likely contain certificates with Public keys in,
	  so the format could also contain the associated SAID for initial
	  contact. 
   
Some allocation of the SAID space for local/global allocation as propossed 
in IEEE 802.10  seems to be sensible to allow for multicast.


Antony Martin
Defence Research Agency
Malvern
UK