Subject: Re: I-D ACTION:draft-cruickshank-ipdvb-sec-00.txt, "ULEsec"

From: Frank <[email-masked]>
Date: Mon, 11 Jul 2005 20:51:55 +0200

Thanks Haitham for the security extension draft.
Most issues that we discussed in our SATNEX workshop
are already adressed in the draft.
I hope the "ULE-Sec" extension will become standard soon.
Link-layer security is a valuable part of a "multiple layer security"
solution, especially since upper layer security protocols are not used,
not available or somehow incompatible
(like end-to-end transport-mode IPsec together with TCP-split).
Satellites definately need kind of a "wired equivalent privacy".
And protection against traffic analysis is a very unique feature of
this security layer.

I attached a PDF about how the "ULE-Sec" subsystems could be structured.
We discussed this already in our workshop.
Looking at the DVB-RCS-Sec spec. there is much to improve.
A control plane based on UDP messages would be easier to realize
than closed L2 solutions.
On the other hand, signalling on layer 2 would be closer to the receiver
hardware and thus more secure in authentication (smartcard as in GSM/UMTS).
IPsec, IKE, GSAKMP, MIKEY are a good "study examples", but surely
need to be modified for the satellite L2 approach.
What about re-using code from IKE implementations KAME (racoon) or
Free S/WAN (Pluto)?
At this opportunity, some problems of IPsec could be removed,
like the "aggressive mode" or AH-only.
The big benefit over IPsec is, that no tunnelling is required.
IPsec transport mode would have to be end-to-end and
can't be used just to secure the satellite link.

At the workshop, Pauline Chan had the idea to integrate a billing system.
Strong RSA/EC authentication with smardcards in the Satcom
receivers would be a good base for a billing system.
Fraud protection should be done in the Satcom terminals.
Using UDP for key-exchange signalling in attached computers
might be dangerous as the secret keys could be stolen.
A closed terminal solution with L2 signalling
directly linked to the smardcard reduces the
intrusion risk dramatically.
Some other ideas could be derived from the UMTS
access security architecture.

Anyway, I guess we still need lots of discussion
to come to a high-end security solution for the satellite link.

Regards,
Frank

--
Dipl.-Ing. Frank Hermanns
Institut für Kommunikation und Navigation
DLR - Deutsches Zentrum für Luft- und Raumfahrt
D-82234 Wessling
Tel: +49 8153 28-2899
Fax: +49 8153 28-2844

---

From: "H.Cruickshank" <[email-masked]>
Date: Wed, 13 Jul 2005 11:37:38 +0100

Hi Frank,

Many thanks for your email and idea.  However let me clarify few points:

* The ipdvb security ID is focused on ULE message encryption and
optional authentication.  
* We do not address specific key management protocols  here.  However,
key management  protocols such as GDOI and GSAKMP are good candidates
although other non-IETF protocols can be used as well.
* Please in the future make specific comments on this draft such the
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 .

Many thanks again for your comments.  

--

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: [email-masked] 

http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/

---

From: Frank <[email-masked]>
Date: Thu, 14 Jul 2005 18:54:02 +0200

> -----Original Message-----
Yes, of course, the symmetric encryption and the key management
should be as isolated as possible. Something for future I-D :-)

> temporary MAC address and the general requirements for ULE

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?

In general, I guess this draft is a good start for the IETF in Paris.
Have fun!

Frank

---

From: "H.Cruickshank" <[email-masked]>
Date: Fri, 15 Jul 2005 17:32:56 +0100

Hi Frank again,

See replies in-line

--

Lecturer

Fax: +44 1483 686011

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Frank
Sent: 14 July 2005 17:54
To: [email-masked]
Subject: RE: I-D ACTION:draft-cruickshank-ipdvb-sec-00.txt, "ULEsec"

> * The ipdvb security ID is focused on ULE message encryption and
Yes, of course, the symmetric encryption and the key management should
be as isolated as possible. Something for future I-D :-)

> 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.

These details are part of the key management procedures which are out of
scope for this document.

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.

Thanks

Haitham