[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Fwd: Comments on draft-cruickshank-ipdvb-sec-req-04.txt]
Hi Michael,
Please find inline the response to your suggestions/ comments. Would like to point out that this response is with draft version 04 in mind. All changes to be made and agreed will be done in the new rev and circulated on this list.
Cheers
Sunny
________________________________
From: owner-ipdvb@erg.abdn.ac.uk on behalf of Michael Noisternig
Sent: Thu 23/11/2006 14:33
To: ipdvb@erg.abdn.ac.uk
Subject: [Fwd: Comments on draft-cruickshank-ipdvb-sec-req-04.txt]
Not having got any response to my mail with comments on above mentioned
draft from the very authors, I hope to eventually get some feedback by
posting the mail on this list.
// Sunny
Sorry Michael for the delay to reply to your comments.
Thank you,
Michael
-------- Original Message --------
Subject: Comments on draft-cruickshank-ipdvb-sec-req-04.txt
Date: Mon, 20 Nov 2006 15:44:12 +0100
From: Michael Noisternig <mnoist@cosy.sbg.ac.at>
To: P.Pillai@Bradford.ac.uk, h.cruickshank@surrey.ac.uk,
S.Iyengar@surrey.ac.uk, Laurence.Duquerroy@space.alcatel.fr
Dear security requirements draft authors,
sorry for the delay in writing to you in response to the IETF67 meeting.
I had originally raised several issues for the 03 revision of the
security requirements on the ipdvb mailing list in mid-August.
Unfortunately, I couldn't find any of them taken into account for the
latest security requirements document, something I brought up in the
Jabber forum of the IETF67 meeting where Prashant then suggested to
re-send my comments directly to you, the authors of this draft.
Below I am citing the relevant parts of my original mail and the one in
response to Prashant's comments. Some further comments are placed
in-between.
> -------- Original Message --------
> Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt
> Date: Mon, 14 Aug 2006 17:24:21 +0200
> From: Michael Noisternig <mnoist@cosy.sbg.ac.at>
> Reply-To: ipdvb@erg.abdn.ac.uk
> To: ipdvb@erg.abdn.ac.uk
> References: <1155561927.44e079c777a2c@webmail6.brad.ac.uk>
>
> Hi Prashant,
>
> thanks for your quick reply. See comments inline.
>
> P.Pillai@Bradford.ac.uk wrote:
>> Hi Michael,
>
> <snip>
>
>>> §3.2, last paragraph:
>>> - data integrity alone does not provide authentication
>>> - the defence statement is oversimplifying and belongs to the
>>> requirements section
>>
//Sunny
//Agree with you on that and it ahs been removed from the the current draft (ver 4).
>> Yes, Data integrity is different from data authentication, but the same MAC can
>> be used to provide both data integrity and data authentication.
>
> Integrity of messages is automatically assured by their correct
> authentication, so yes, MACs provide both authentication and integrity.
> But you are not speaking about MACs in that paragraph or section. A CRC
> or any unkeyed hash provides integrity protection but is certainly not
> effective against active adverseries.
Data integrity is often used to refer to the protection of data by
accidental changes only, such as by CRCs or unkeyed hashes (message
digests) in general. As such I'm not too happy with the use of the term
data integrity in this document, and would generally prefer the term
(message) authentication to explicitly mean protection against both
accidental and incidental changes.
// Agree that data integrity can be achieved with hashes and CRCs but strong cryptographic techinques are needed to avert active threats.
Anyway, to section §3.2: I think you should completely omit the last
sentence for the following reasons:
- the defense statement is oversimplifying in the following sense:
+ data integrity/authentication can detect unauthorized modification
of messages, but can only partially help to prevent masquerading attacks
+ sequence numbers are just one (effective) example to counter replay
attacks
+ there is no solution given how to prevent DoS attacks
+ the sentence reads like these are all the solutions to counter
active attacks
- §3 is about analyzing threats, and not requirements, which are handled
later in section §4, and the sentence should be omitted/moved/merged there
//Sunny
I agree with you that tyhis might be one solution but not THE solution so will omit it from the next version.
>>> §3.3, threat cases 2 and 3:
>>> one can distinguish between two other cases:
>>> (a) insider attacks, i.e. active attacks from adverseries in the know of
>>> certain keys
>>> -> protection against this attack requires source authentication
>>> (e.g. digitial signatures)
>>
>> This is more part of key management techniques. An adversary (even if it knows
>> the keys) has to still over-ride the original transmission stream and deliver a
>> modified stream - this is Case 2 as described in the draft.
>>> (b) outsider attacks, i.e. active attacks from outside of a VPN
>>> -> in this case simple MACs are sufficient (i.e. group authentication)
>>
>> Note that the Secure ULE aims to secure only between the ULE encapsulation
>> gateways and the ULE receivers.
>
> Well, I speak about the case where a ULE receiver can act as a sender,
> i.e. ULE encapsulator. A valid receiver (i.e. one knowing the shared
> authentication key for MACs) acting as a sender can successfully forge
> messages, but not when digital signatures are used (case a). However, a
> sender who does not know the MAC key (e.g. because he is not part of the
> VPN within the same ULE network) will not be able to forge messages
> (case b).
>
> Note that even when there is only one ULE encapsulator an active
> adversary may invalidate the one-sender assumption, and so you again
> cannot detect forged messages for case a when MACs are used.
Source authentication means corroborating the fact that a message comes
from *one specific* sender. A simple MAC can only provide source
authentication as long as it is guaranteed that there is only one
sender! A one-sender assumption may easily be invalidated by a receiver
acting as an active adversary (i.e. an ULE encapsulator). Another
scenario is that of meshed networks... how do you know that a message
really comes from device x and not y? You can't with simple MACs.
An "insider attack" is a valid threat scenario. (Think of a disgruntled
employee.) I am fully aware that insider attacks are more unlikely than
attacks from outside a VPN (or virtual LAN) within the ULE network, and
that most will be fine with group authentication (i.e. MACs). (And there
are good other reasons why one would want to stick with MACs.) I was
just mentioning another threat model that has to be considered, and in
which MACs do not provide source authentication. (And I guess, you, the
authors of this draft, have also considered that threat once because of
mentioning TESLA later in section §4.)
Furthermore, I strongly believe that a security requirements document
providing a threat analysis must consider *all* possible threats (within
the (MPEG-2) network).
//Sunny
Thanks for the discussions between Michael and George Gross. I think the subcases should be included in the new rev to take care of all sub scenarios.
>>> §4: all the references to section 2 should be 3
>> Thanx, will modify these.
//Sunny
// Done in version 4 of the draft
>>> §4, security requirements list:
>>> - instead of "ULE source authentication is required..." should more
>>> generally say "integrity protection and authentication is required..."
>> Yes, will change this
// Sunny
Will change to "Integrity protection and authentication of the ULE source is required "
>>
>>> - missing L2 ULE sender and receiver authentication (entitiy authentication)
>> This is part of the initial key exchange and authorisation phase - it is present
>> in the requirements lists in section 4
>
> Well, it was just my impression, if you mention authorization separately
> from key management, you should also mention entity authentication.
>
/Sunny
It does mention L2 Receiver authorisation . WIll change it to L2 entity authentication (user authentication) and replace authorisation with authentication.
>>
>> $4, other general requirements list:
>> - might mention requirement for policy management
>> - integrity of control messages (SI tables): as said before, what we
>> want is authentication
>
//Sunny
Agree with Policy management.
Chenge to Authentication (not data intergrity but message authentication ) of the control messages.
>>> §4, security requirements case 2:
>>> - MACs do NOT provide source authentication for cases 2 and 3 (subcase (a))
>> The MAC is used to make sure that the data has been sent by the correct source -
>> hence provides source authentication. I am not sure why you say that it does not
>> provide any source authentication.
>
> Multiple senders. This is why you want TESLA.
> (In multiple sender scenarios MACs can only provide group authentication.)
As explained above, in scenarios where there are multiple senders (or
potential other senders) MACs cannot provide source authentication. This
is why I suggest to just say authentication. In comparison, digital
signatures and TESLA _do_ provide source authentication!
Maybe you could rewrite the offending phrase like this:
"...new measures need to be implemented such as authentication using
Message Authentication Codes, digital signatures, or TESLA [RFC4082]..."
//Sunny
Agree with you on rewriting the new phrase as mentioned :)
>
>>> - if mentioning TESLA should first speak of digital signatures
>>> (btw, TESLA introduces further latencies at the receiver side and still
>>> requires digital signatures (for signing the head of the hash chains))
>> TESLA is only mentioned as an option that may be possible.
>
>> §5, first paragraph, last sentence:
>> ...impact on bandwidth?
// Done in rev 4
>>
>> §5, last list item:
>> I don't see how the issue of address preservation is of relevance
>> to the ULE scenario. AFAIK address preservation is important for correct
>> routing within multicast trees, but since in ULE networks data is simply
>> sent from one L2 point to the next I don't understand the problem.
//Sunny
// just trying to highlight the workaround in IPSec which is not needed for ULE and hence trying to bring out the need (or strengthen the case) for ULE.
>>
>> §6.1, disadvantages:
>> third item should probably mean "Encryption of the MAC/NPA address is
>> not permitted in MPE systems."
>>
//Sunny
Agreed
>> §6.2:
>> - references to section 2 should be 3
//Sunny
Doner in rev 4
>> - information in first paragraph is redundant, i.e. already in the
>> requirements section (section 4)
>>
//Sunny
Remove the last sentence since its repeated.
>> §7, second paragraph:
>> It should better read "There is an optional requirement for L2
>> authentication and integrity assurance as well as protection against
>> insertion of other data into the ULE stream (i.e. replay attacks)."
//Sunny
Agreed
I'd be glad if you could shortly reply to each of my comments. Thank you
very much in advance!
Best regards,
Michael
Thanks for your useful comments.
Cheers
Sunny
Hi Michael,
Please find inline the response to your suggestions/ comments. Would like to point out that this response is with draft version 04 in mind. All changes to be made and agreed will be done in the new rev and circulated on this list.
Cheers
Sunny
________________________________
From: owner-ipdvb@erg.abdn.ac.uk on behalf of Michael Noisternig
Sent: Thu 23/11/2006 14:33
To: ipdvb@erg.abdn.ac.uk
Subject: [Fwd: Comments on draft-cruickshank-ipdvb-sec-req-04.txt]
Not having got any response to my mail with comments on above mentioned
draft from the very authors, I hope to eventually get some feedback by
posting the mail on this list.
// Sunny
Sorry Michael for the delay to reply to your comments.
Thank you,
Michael
-------- Original Message --------
Subject: Comments on draft-cruickshank-ipdvb-sec-req-04.txt
Date: Mon, 20 Nov 2006 15:44:12 +0100
From: Michael Noisternig <mnoist@cosy.sbg.ac.at>
To: P.Pillai@Bradford.ac.uk, h.cruickshank@surrey.ac.uk,
S.Iyengar@surrey.ac.uk, Laurence.Duquerroy@space.alcatel.fr
Dear security requirements draft authors,
sorry for the delay in writing to you in response to the IETF67 meeting.
I had originally raised several issues for the 03 revision of the
security requirements on the ipdvb mailing list in mid-August.
Unfortunately, I couldn't find any of them taken into account for the
latest security requirements document, something I brought up in the
Jabber forum of the IETF67 meeting where Prashant then suggested to
re-send my comments directly to you, the authors of this draft.
Below I am citing the relevant parts of my original mail and the one in
response to Prashant's comments. Some further comments are placed
in-between.
> -------- Original Message --------
> Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt
> Date: Mon, 14 Aug 2006 17:24:21 +0200
> From: Michael Noisternig <mnoist@cosy.sbg.ac.at>
> Reply-To: ipdvb@erg.abdn.ac.uk
> To: ipdvb@erg.abdn.ac.uk
> References: <1155561927.44e079c777a2c@webmail6.brad.ac.uk>
>
> Hi Prashant,
>
> thanks for your quick reply. See comments inline.
>
> P.Pillai@Bradford.ac.uk wrote:
>> Hi Michael,
>
> <snip>
>
>>> §3.2, last paragraph:
>>> - data integrity alone does not provide authentication
>>> - the defence statement is oversimplifying and belongs to the
>>> requirements section
>>
//Sunny
//Agree with you on that and it ahs been removed from the the current draft (ver 4).
>> Yes, Data integrity is different from data authentication, but the same MAC can
>> be used to provide both data integrity and data authentication.
>
> Integrity of messages is automatically assured by their correct
> authentication, so yes, MACs provide both authentication and integrity.
> But you are not speaking about MACs in that paragraph or section. A CRC
> or any unkeyed hash provides integrity protection but is certainly not
> effective against active adverseries.
Data integrity is often used to refer to the protection of data by
accidental changes only, such as by CRCs or unkeyed hashes (message
digests) in general. As such I'm not too happy with the use of the term
data integrity in this document, and would generally prefer the term
(message) authentication to explicitly mean protection against both
accidental and incidental changes.
// Agree that data integrity can be achieved with hashes and CRCs but strong cryptographic techinques are needed to avert active threats.
Anyway, to section §3.2: I think you should completely omit the last
sentence for the following reasons:
- the defense statement is oversimplifying in the following sense:
+ data integrity/authentication can detect unauthorized modification
of messages, but can only partially help to prevent masquerading attacks
+ sequence numbers are just one (effective) example to counter replay
attacks
+ there is no solution given how to prevent DoS attacks
+ the sentence reads like these are all the solutions to counter
active attacks
- §3 is about analyzing threats, and not requirements, which are handled
later in section §4, and the sentence should be omitted/moved/merged there
//Sunny
I agree with you that tyhis might be one solution but not THE solution so will omit it from the next version.
>>> §3.3, threat cases 2 and 3:
>>> one can distinguish between two other cases:
>>> (a) insider attacks, i.e. active attacks from adverseries in the know of
>>> certain keys
>>> -> protection against this attack requires source authentication
>>> (e.g. digitial signatures)
>>
>> This is more part of key management techniques. An adversary (even if it knows
>> the keys) has to still over-ride the original transmission stream and deliver a
>> modified stream - this is Case 2 as described in the draft.
>>> (b) outsider attacks, i.e. active attacks from outside of a VPN
>>> -> in this case simple MACs are sufficient (i.e. group authentication)
>>
>> Note that the Secure ULE aims to secure only between the ULE encapsulation
>> gateways and the ULE receivers.
>
> Well, I speak about the case where a ULE receiver can act as a sender,
> i.e. ULE encapsulator. A valid receiver (i.e. one knowing the shared
> authentication key for MACs) acting as a sender can successfully forge
> messages, but not when digital signatures are used (case a). However, a
> sender who does not know the MAC key (e.g. because he is not part of the
> VPN within the same ULE network) will not be able to forge messages
> (case b).
>
> Note that even when there is only one ULE encapsulator an active
> adversary may invalidate the one-sender assumption, and so you again
> cannot detect forged messages for case a when MACs are used.
Source authentication means corroborating the fact that a message comes
from *one specific* sender. A simple MAC can only provide source
authentication as long as it is guaranteed that there is only one
sender! A one-sender assumption may easily be invalidated by a receiver
acting as an active adversary (i.e. an ULE encapsulator). Another
scenario is that of meshed networks... how do you know that a message
really comes from device x and not y? You can't with simple MACs.
An "insider attack" is a valid threat scenario. (Think of a disgruntled
employee.) I am fully aware that insider attacks are more unlikely than
attacks from outside a VPN (or virtual LAN) within the ULE network, and
that most will be fine with group authentication (i.e. MACs). (And there
are good other reasons why one would want to stick with MACs.) I was
just mentioning another threat model that has to be considered, and in
which MACs do not provide source authentication. (And I guess, you, the
authors of this draft, have also considered that threat once because of
mentioning TESLA later in section §4.)
Furthermore, I strongly believe that a security requirements document
providing a threat analysis must consider *all* possible threats (within
the (MPEG-2) network).
//Sunny
Thanks for the discussions between Michael and George Gross. I think the subcases should be included in the new rev to take care of all sub scenarios.
>>> §4: all the references to section 2 should be 3
>> Thanx, will modify these.
//Sunny
// Done in version 4 of the draft
>>> §4, security requirements list:
>>> - instead of "ULE source authentication is required..." should more
>>> generally say "integrity protection and authentication is required..."
>> Yes, will change this
// Sunny
Will change to "Integrity protection and authentication of the ULE source is required "
>>
>>> - missing L2 ULE sender and receiver authentication (entitiy authentication)
>> This is part of the initial key exchange and authorisation phase - it is present
>> in the requirements lists in section 4
>
> Well, it was just my impression, if you mention authorization separately
> from key management, you should also mention entity authentication.
>
/Sunny
It does mention L2 Receiver authorisation . WIll change it to L2 entity authentication (user authentication) and replace authorisation with authentication.
>>
>> $4, other general requirements list:
>> - might mention requirement for policy management
>> - integrity of control messages (SI tables): as said before, what we
>> want is authentication
>
//Sunny
Agree with Policy management.
Chenge to Authentication (not data intergrity but message authentication ) of the control messages.
>>> §4, security requirements case 2:
>>> - MACs do NOT provide source authentication for cases 2 and 3 (subcase (a))
>> The MAC is used to make sure that the data has been sent by the correct source -
>> hence provides source authentication. I am not sure why you say that it does not
>> provide any source authentication.
>
> Multiple senders. This is why you want TESLA.
> (In multiple sender scenarios MACs can only provide group authentication.)
As explained above, in scenarios where there are multiple senders (or
potential other senders) MACs cannot provide source authentication. This
is why I suggest to just say authentication. In comparison, digital
signatures and TESLA _do_ provide source authentication!
Maybe you could rewrite the offending phrase like this:
"...new measures need to be implemented such as authentication using
Message Authentication Codes, digital signatures, or TESLA [RFC4082]..."
//Sunny
Agree with you on rewriting the new phrase as mentioned :)
>
>>> - if mentioning TESLA should first speak of digital signatures
>>> (btw, TESLA introduces further latencies at the receiver side and still
>>> requires digital signatures (for signing the head of the hash chains))
>> TESLA is only mentioned as an option that may be possible.
>
>> §5, first paragraph, last sentence:
>> ...impact on bandwidth?
// Done in rev 4
>>
>> §5, last list item:
>> I don't see how the issue of address preservation is of relevance
>> to the ULE scenario. AFAIK address preservation is important for correct
>> routing within multicast trees, but since in ULE networks data is simply
>> sent from one L2 point to the next I don't understand the problem.
//Sunny
// just trying to highlight the workaround in IPSec which is not needed for ULE and hence trying to bring out the need (or strengthen the case) for ULE.
>>
>> §6.1, disadvantages:
>> third item should probably mean "Encryption of the MAC/NPA address is
>> not permitted in MPE systems."
>>
//Sunny
Agreed
>> §6.2:
>> - references to section 2 should be 3
//Sunny
Doner in rev 4
>> - information in first paragraph is redundant, i.e. already in the
>> requirements section (section 4)
>>
//Sunny
Remove the last sentence since its repeated.
>> §7, second paragraph:
>> It should better read "There is an optional requirement for L2
>> authentication and integrity assurance as well as protection against
>> insertion of other data into the ULE stream (i.e. replay attacks)."
//Sunny
Agreed
I'd be glad if you could shortly reply to each of my comments. Thank you
very much in advance!
Best regards,
Michael
Thanks for your useful comments.
Cheers
Sunny