From bf99d3aad8bfc4d10bd817fa72eee61811f41a78 Mon Sep 17 00:00:00 2001 From: Christian Pointner Date: Wed, 1 Apr 2009 16:53:55 +0000 Subject: updated new draft --- .../draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml') diff --git a/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml b/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml index cb5ebde..6021696 100644 --- a/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml +++ b/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml @@ -288,11 +288,11 @@ HEX
- As mentioned earlier the cryptography of SATP is based on SRTP. For that reason we recommend to read this document as well. However some modifications were made in order to fit the changed conditions of SATP. The following section describes the whole cryptography of SATP. + As mentioned earlier the cryptography of SATP is based on SRTP. For that reason we recommend to read this document as well (especially chapter 7 Rationale). However some modifications were made in order to fit the changed conditions of SATP. The following section describes the whole cryptography of SATP.
- In order to cope with anycast and packet loss it is important to beeing able to process one packet on its own without the need for packets from the past as an additional information source. Therefore SATP as well as SRTP defines a so called cryptographic context. This context consits of all information which is needed to process a single SATP packet and is divided into packet specific parameters and global parameters. The packet specific parameters can be found in the protocol header and global parameters have to be generated by the key exchange mechanism external to SATP (see ). For anycast sender the global parameters have to be synchronized between all hosts which share the same anycast address. The packet specific parameters MUST NOT be synchronized. + In order to cope with anycast and packet loss it is important to be able to process one packet on its own without the need for packets from the past as an additional information source. Therefore SATP as well as SRTP defines a so called cryptographic context. This context consits of all information which is needed to process a single SATP packet and is divided into packet specific parameters and global parameters. The packet specific parameters can be found in the protocol header and global parameters have to be generated by the key exchange mechanism external to SATP (see ). For anycast sender the global parameters have to be synchronized between all hosts which share the same anycast address. The packet specific parameters MUST NOT be synchronized. SATP uses two types of keys: master keys and session keys. A session key is meant to be used for a cryptographic transform (encrytion or message authentication) for one packet. The master keys are used to derive packet-specific session keys in a cryptographical secure way.
@@ -497,7 +497,7 @@ SATP uses two types of keys: master keys and session keys. A session key is mean
- As SATP uses the same encryption techniques as SRTP, it shares the same security issues. This section will only discuss some small changes. Please read SRTP RFC3711 section 9 for details. + As the cryptography of SATP is based on SRTP, it shares the same security issues. This section will only discuss some small changes. Please read SRTP RFC3711 section 9 for details.
-- cgit v1.2.3