Re: [Gen-art] Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14

[Igoe, Kevin M.]

Ben et al:

  Here is the reasoning behind some of the issues you raise.  At least one
of them (SSRC re-use) is security critical.  

=
SSRC Management:

"If I read this section correctly, the draft requires central management
of SSRC values when you have a master key shared among endpoints in a SRTP 
session, and goes so far to require authentication of data a central SSRC 
manager."

Yes indeed, having unique SSRC values is a crucial requirement in aes-gcm, 
since using the same IV (i.e. (ROC,SEQ,SSRC) triple) with the same key 
K more than once results in two undesirable consequences:

1) It compromises secret authentication value H which is used to
 authenticate ALL messages that use the key K.

2) It effectively reveals the contents of any packets using this
 common IV value.

Revealing the authentication key is a risk common to aes-gcm and many
other AEAD algorithms. But revealing the message content is a risk for
any key stream, including AES counter mode.

   RFC 3711 is willing to accept the compromise of some data, using the SRTP
SSRC collision detection process to detect such a compromise after it has
occurred.  But for my user base, detecting a data compromise after it has
occurred is insufficient.  For any high value data stream, any data compromise 
has potentially disasterous consequences


Though I didn't want to specify a mechanism for achieving the goal of having
unique SSRCs, the solution I had in the back of my mind was
a) Each source has its own key for encrypting its outgoing data streams.
  b) The key it uses to decrypt incoming data depends upon the originator.
c) For a given key K, the burden of preventing SSRC reuse with K depends
 solely upon the single source forming outgoing data streams using that
 key.  
One way or another, using either the current I-D or RFC 3711 with high value
data streams requires a mechanism that prevents the use of the same SSRC with 
two or more data sources that are using the same key on their outgoing data.
This decentralizes the burden on SSRC management, but requires each source have
its own outgoing data key.  If some usage of STTP requires that multiple 
sources 
must use the same outgoing data key, a mechanism needs to be in place to impose 
some discipline on how the members of this subnet assign SSRC values.  This 
holds 
for both RFC 3711 and the current I-D.
 
=
 
"-- References:

The draft has normative down ref to RFC 3610. This was not explicitly mentioned 
in the IETF last call email, and does not appear to be included in the down ref 
registry."

Mea culpa, need to update this.

=

-- 8.1:

If this draft contradicts normative language from RFC 3711, it should 
explicitly update 3711.

Its not so much that tie I-D updates updates as that it deale with a different 
context.   
In AEAD an algorithms integrity, is an intrinsic part of the 
encryption/decryption process, 
not a separate independent process.  RFC 3711 implicitly assumes integrity and 
privacy are 
two separate processes, but that it not true of AES-GCM.  For non-AEAD 
algorithms, RFC 3711 is 
correct in how it handles integrity, but AEAD an algorithm handle integrity in 
a radically different 
way and requires the modifications outlined in section 8.1.

=
-- 8.2

Can you offer guidance on when it might be (or not be) necessary to disguise 
the length of the plaintext?  Especially how that might be known at the SRTP 
layer?

=
-- 14.1:

Does the master salt need to be kept secret? If the answer is "it depends", can 
you offer guidance?

Lurking in section 3.2.1 of RFC 3711 is the following bullet. 

   *  a master salt, to be used in the key derivation of session keys.
  This value, when used, MUST be random, but MAY be public.  Use of
  master salt is strongly RECOMMENDED, see Section 9.2.  A "NULL"
  salt is treated as 00...0.

We took that to say that if the master salt MAY be public, it is also possible
for it to be secret.  I can not think of any instance in which it needs to be 
secret, but apparently the authors of RFC 3711 weren't quite so certain. 

=
Also, can you offer a definition of "properly erased"?

Gladly! I mean overwritten, not just dereferenced.  It's a bad idea to leave 
secret
values floating around in memory, just waiting for an adversary to read them 
out.

=
+--

Re: [Gen-art] [tsvwg] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09

[Robert Sparks]

Thanks Georgios - these are improvements.

RjS

On 9/14/14 3:58 AM, karag...@cs.utwente.nl wrote:

Hi Robert,

Thank you for your comments!

We have worked out your comments in the following way, see in line!

Please let us know if you are satisfied with these changes!
  




-Original Message-
From: tsvwg [mailto:tsvwg-boun...@ietf.org] On Behalf Of Robert Sparks
Sent: donderdag 21 augustus 2014 22:44
To: General Area Review Team; i...@ietf.org; ts...@ietf.org; draft-ietf-
tsvwg-rsvp-pcn@tools.ietf.org
Subject: [tsvwg] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09

I am the assigned Gen-ART reviewer for this draft. For background on Gen-
ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-tsvwg-rsvp-pcn-09
Reviewer: Robert Sparks
Review Date: 21 Aug 2014
IETF LC End Date: 26 Aug 2014
IESG Telechat date: 2 Oct 2014

Summary: Ready (with nits) for publication as Experimental.

David's shepherd writeup points out that implementation and usage
experience is desired before producing a proposed standard. Are there any
points of concern about how this might behave (or misbehave) in a deployed
network that such experience would inform? If so, it would be useful to call
them out in the document.


Georgios: Added the following paragraph at the end of Section 1.1:

This draft is intended to be published as Experimental in order to:

   o) validate industry interest by allowing implementation and

  deployment

   o) gather operational experience, in particular around dynamic
  interactions of RSVP signaling and PCN notification and
  corresponding levels of performance.



It would be nicer if the document argued why there are no new security
considerations introduced by the new behavior defined in this draft, rather
than tacitly asserting that there aren't any.

Georgios:
Added the following text in Section 5:

In particular, the security considerations within the PCN domain come
from the Trust Assumption Section 6.3.1, of [RFC5559] i.e., that all
PCN-nodes are PCN-enabled and are trusted for truthful PCN-metering
and PCN-marking.

In the PCN domain environments addressed by this document, Generic
Aggregate Resource ReSerVation Protocol (RSVP)messages specified in
[RFC4860] are used for support of the PCN Controlled Load (CL) and
Single Marking (SM) edge behaviors over a Diffserv cloud using Pre-
Congestion Notification. Similar, to [RFC4860], [RFC2747] and
[RFC3097] may be used to protect RSVP message integrity hop-
by hop and provide node authentication as well as replay protection,
thereby protecting against corruption and spoofing of RSVP messages
and PCN feedback.

Based on these assumptions, it is considered that this document is
NOT introducing any additional security concerns/issues compared to
[RFC5559] and/or [RFC4860].


The terminology section has lots of 2119 words in it. It's hard to tell when
these have been copied from some other draft (and this is just restating
them) vs when this draft is introducing a new requirement.
Since a new requirement would likely be missed if it appeared only in a
terminology section, would it be feasible to make sure anything new is well
covered in section 3 or 4 and remove 2119 from these definitions altogether?

Georgios:
Removed all RFC 2119 words from the terminology section (Section 1.3)


The rest of these comments are minor editorial nits:

Section 1.2, paragraph 3: "Intserv over Diffserv can operate over a statically
provisioned Diffserv region or RSVP aware." is missing a a word somewhere.

Georgios:
changed From:
Intserv over Diffserv can operate over a statically provisioned Diffserv region 
or a RSVP aware.

INTO
Intserv over Diffserv can operate over a statically provisioned or a RSVP aware 
Diffserv region

Section 1.2 paragraph 4: "By using multiple aggregate reservations for the
same PHB allows enforcement of the different preemption priorities within
the aggregation region." doesn't parse. Should the initial "By"
be deleted?

Georgios:
Changed from:

By using multiple aggregate reservations for the same PHB, allows enforcement 
of the different preemption priorities within the aggregation region.

INTO:
By using multiple aggregate reservations for the same PHB, it allows 
enforcement of the different preemption priorities within the aggregation 
region.


The definition for PCN-domain is very close to circular. Perhaps some words
can be removed?

In Section 1.3, we have replaced PCN-domain with domain in the text, see below:
Channged from:
PCN-domain:  a PCN-capable domain; a contiguous set of
 PCN-enabled nodes that perform Diffserv scheduling
 [RFC2474]; the complete set of PCN-nodes that in
 principle can, through PCN-markin

[Gen-art] ***SPAM*** 5.955 (5) Re: IETF Last Call Review of draft-ietf-hip-rfc5201-bis-14

[Jari Arkko]

I see that there are newer versions. Have those versions changed something with 
regards to Tom T’s review questions? I have not seen a response to this e-mail 
thread, but I’m eager to clear my discuss…

Jari

On 24 Jun 2014, at 13:12, Jari Arkko  wrote:

> Thanks for the detailed review, Tom T! From what I can see, your questions 
> are valid. Tom H, any update regarding changes and/or other responses?
> 
> Jari
> 
> On 16 Jun 2014, at 03:02, Tom Taylor  wrote:
> 
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> 
>> .
>> 
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>> 
>> Document: draft-ietf-hip-rfc5201-bis-14
>> Reviewer: Tom Taylor
>> Review Date: 2014-06-12
>> IETF LC End Date: 2014-06-11
>> IESG Telechat date: 2014-06-26
>> 
>> Summary: The draft is mostly ready, some minor issues and a number of 
>> editorial improvements identified to this point. This is the final and 
>> complete version of the review. Lines have been drawn below to indicate 
>> where the first version left off.
>> 
>> Major issues:
>> 
>> 
>> Minor issues:
>> 
>> 
>> Section 4.3 (Error Processing) final case: if the receiving host does not 
>> send some sort of response (e.g., ICMP) to the sender, the sender may have 
>> no way of knowing that the HIP session has failed. The state transitions 
>> from ESTABLISHED in Table 6 time out on no packet "sent/received" for a 
>> given period of time. If the sending application doesn't expect a response, 
>> it could be sending packets that are ignored at the other end for an 
>> indefinitely long time. At the least, this point should be brought out in 
>> the text of that error case, and possibly the ICMP response should be 
>> RECOMMENDED.
>> 
>> Section 5.2.7: when the host supports more than one D-H Group, is each group 
>> specified in a separate instance of the Diffie-Hellman parameter? The text 
>> does not say.
>> 
>> Section 5.2.18: given the strict ordering of HIP parameters, the initial 
>> plaintext for the Encrypted content (type and length of initial parameter) 
>> may be fairly easily guessed. This opens up the minor possibility of a known 
>> plaintext attack. [Comment to be reviewed after further examination.] [Upon 
>> review: I1 packets have fixed type but variable length due to varying 
>> lengths of DH-GROUP-LISTS. The set of such lengths is limited, however, so 
>> it is worth considering whether known plain-text attacks offer any real 
>> threat.]
>> 
>> Section 5.3, last paragraph: forbids fragmentation of the HIP packet. 
>> Doesn't this contradict Section 5.1.3?
>> 
>>  Issues below here added in second version
>> 
>> 
>> Nits/editorial comments:
>> ===
>> 
>> Idnits generated 13 warnings. Most are spurious, but there are a few 
>> outdated references. I didn't check out the IPv6 addresses.
>> 
>> Inconsistent capitalization: "Base Exchange" (in the opening sections) vs. 
>> "base exchange" (most of the document)
>> 
>> Sometimes the phrase is "HIP session", sometimes "HIP association". The RFC 
>> Editor will probably want you to choose which one to use consistently. Noted 
>> that "HIP association" is defined in Section 2.3.
>> 
>> Section 1, second paragraph is a little brief on the additional 
>> specification beyond the base exchange provided in this document. The 
>> sentence beginning "It also defines ..." should include " and terminating 
>> the association".
>> 
>> Section 1, last paragraph: missing period.
>> "... later discovered to be vulnerable This update"
>>^
>> 
>> It would be nice to have a definition of the term "HIP packet" in Section 
>> 2.3. If I understand correctly, after the base exchange, most of the packets 
>> flowing in a HIP association are ordinary user data packets and not HIP 
>> packets, and this point should be made. In some places the term "HIP control 
>> packets" is used. Choose one or the other term for consistency.
>> 
>> Section 3.1, third line from end: s/a hosts/a host/
>> 
>> Section 4.1.4: perhaps the last and second-last paragraphs should be 
>> interchanged. I got lost for a moment on the association of multiple R1s 
>> with the Initiator rather than the Responder when reading the second-last 
>> paragraph. The last paragraph makes the situation clear.
>> 
>> Section 4.1.5, first paragraph, second sentence: assumes that the host is 
>> willing to carry out a base exchange with the original Initiator, albeit on 
>> its own terms. Should something like "and policy allows the establishment of 
>> a HIP association with the original Initiator" be added in front of the 
>> comma in that second sentence? That leads nicely to discussion of that case 
>> in the next paragraph.
>> 
>> State diagram, Figure 2, in Section 4.4.4: unlabelled line from CLOSING to 
>> I1-SENT.
>> 
>