Hi Frank again,
See replies
in-line
--
Dr. Haitham S.
Cruickshank
Lecturer
Communications Centre for Communication
Systems Research (CCSR)
School of Electronics, Computing and
Mathematics
University of Surrey, Guildford, Surrey GU2 7XH,
UK
Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483
686011
e-mail: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
-----Original
Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]
On Behalf Of Frank
Sent: 14 July 2005 17:54
To:
ipdvb@erg.abdn.ac.uk
Subject: RE: I-D
ACTION:draft-cruickshank-ipdvb-sec-00.txt, "ULEsec"
>
-----Original Message-----
> * The ipdvb security ID is focused on ULE
message encryption and
> optional authentication.
Yes, of course, the
symmetric encryption and the key management should be as isolated as possible.
Something for future I-D :-)
> idea of having ULE header extensions
for security, ULE MAC address
> hiding using unique security ID (like the
SPI in IPsec) with or
> without temporary MAC address and the general
requirements for ULE
> encryption .
Identity protection also was an
issue in the UMTS security architecture (IMSI vs. TMSI). This could be a
requirement from governmental users. However, take care that the identity (or
equivalent permanent MAC/NPA
addresses) is protected during the whole
communication session, including the connection setup signaling. Encrypting the
MAC after it was revealed during setup does not help very much. Do the SNDU data
formats (Figure 1/2) allow such a procedure?
Your idea in the draft
to link the temporary MAC to the key-exchange protocol sounds reasonable.
Otherwise you would need two independent "re-keying" protocols for moving
"targets", one for the dynamic MAC and one for the symmetric encryption
key.
MAC hiding using the SID sounds reasonable after setup. But how do you
want to prevent the (permanent)MAC disclosure during connection setup?
That is a good point. That is the reason for
having a temporary MAC/NPA which should not be linked to any session. A
temporary MAC/NPA address may change according to some predefined security
policy or procedure.
In general, I guess this draft is a good
start for the IETF in Paris. Have fun!
Thanks
Haitham