Re: [Gen-art] Gen-ART review of draft-ietf-appsawg-authres-ptypes-registry-03

[Jari Arkko]

> Summary:  Ready.

Thanks for your review, Russ.

More generally: The Gen-ART reviews are important for the IETF chair to 
determine what drafts he or she has to pay more attention to. The reviews also 
often highlight issues that get corrected, leading to improvements in the final 
RFCs that come out. In 95% of the cases once the document comes to the IESG 
approval telechat, any issues have already been agreed and a new document 
version issued without any IESG involvement. I would like to thank the Gen-ART 
team for this great service! And the authors and everyone else involved for 
working hard to address comments that they receive during IETF Last Calls. 
Thank you.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-opsec-bgp-security-05

[Christer Holmberg]

Hi Jerome,

>> Q_4_2: The last sentence says "For a more detailed recommendation, see 
>> RFC6192 [18].". Recommendation on what?
>
> Recommendation of router protection (section title) I propose we clarify that 
> in the text:
>
> "For a more detailed recommendation on how to protect the router's control 
> plane, see RFC6192 [18] >

Looks good.

>> Section 5:
>>  
>>  Q_5_1: The name of section 5 uses "BGP sessions", but the 
>> section text does not say anything about BGP sessions. And, in section 5.1 
>> you only 
>>  talk about "TCP sessions used by BGP". Only in section 5.2 do you 
>> mention "BGP session". Perhaps you should add some general text to section 5 
>>  about BGP sessions, how TCP is used to transport BGP messages in BGP 
>> sessions etc, and then in section 5.1 only talk about protection of TCP.
>
> OK, I'll see how to clearly add session key word in first paragraph of 5.

Thanks! This was the main editorial issue I had with the document, so hopefully 
you'll find a way to make it more clear :)

Thanks!

Regards,

Christer

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-appsawg-authres-ptypes-registry-03

[Russ Housley]

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-appsawg-authres-ptypes-registry-03
Reviewer: Russ Housley
Review Date: 2014-09-18
IETF LC End Date: 2014-09-30
IESG Telechat date: unknown

Summary:  Ready.

Major Concerns:  None.
Minor Concerns:  None.
Other Comments:  None.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] review: draft-ietf-oauth-jwt-bearer-10

[Joel M. Halpern]

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-oauth-jwt-bearer-10
  JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and
  Authorization Grants
Reviewer: Joel M. Halpern
Review Date: 18-Sept-2014
IETF LC End Date: 29-Sept-2014
IESG Telechat date: N/A

Summary: This document appears to be ready for publicaiton as a Proposed 
Standard.


This reviewer would suggest that the General AD check with parties who 
can confirm the two notes below.


Note that the reviewer did not review RFC 6749, 
draft-ietf-oauth-assertions, or draft-ietf-oauth-json-web-token, but 
simply takes as given that the work here is consistent with that work.


Similarly, the reviewer assumes that the subtleties of 
internationalization of issuers (and any other fields that must be 
compared).  It is not obvious whether pointing to the RFC 3986 is 
sufficient, but it is not obviously insufficient.


Major issues: N/A

Minor issues:
I presume it is clear from the underlying documents whether the 
periods at the ends of intermediate lines in the examples are supposed 
to be there.


Nits/editorial comments: N/A

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Ben Campbell]

Hi Kevin,

For the record, based on your comments I now consider the SSRC text to be a 
minor issue rather than a major one. 

Comments inline (again, deleting parts that seem closed)

On Sep 18, 2014, at 10:30 AM, Igoe, Kevin M.  wrote:

[...]

>  
> Does the "source" in each source mean the synchronization source?
>  
> These terms get a little slippery, bit what I mean is the gear responsible
> for encrypting outgoing data. Let’s call this the originating box.
>  
> I'm not entirely sure I follow you, but I read this to mean you avoid the 
> need for central management of SSRCs by not sharing keys between more than 
> one originator? (that is Assuming so (and my next comment will make no sense 
> otherwise): Wouldn't it make more sense to discourage shared keys, since such 
> sharing would create a need for central ssrc management, rather than suggest 
> ssrc management in the first place?
>  
> Yes, but sadly key management is out-of-scope for srtp.  Also a stronger verb 
> that
> than “discourage” is needed, more like “prohibit”.

I don't think the fact that key management is out-of-scope for srtp in general 
prevents you from offering guidance security critical parts.


>  
> Or do you expect communities to actually implement central ssrc management?
>  
> If there is a small network of devices sharing the same key, say a video 
> conference with
> a handful of participants. One could envision giving each box entering the 
> conference
> a unique SSRC prefix it uses for any SSRCs it needs to create, once again 
> localizing the
> SSRC management (save for the task of handing out SSRC prefixes).
>  
> The bottom line is that there are several ways to mitigate the need for 
> centralized
> SSRC magament.  I agree with you that the key management based approach is 
> far and
> away the cleanest approach.
>  
> My sole concern is not reusing an (SRTP, key) pair.  Any robust mechanism 
> (i.e.
> not probabilistic) that achieves this goal is acceptable.

I guess my problem is that I took the text as written to suggest that 
centralized ssrc management was expected to be the "normal" case. I think it 
would be perfectly reasonable to say something to the effect of "... MUST not 
share keys unless a secure mechanism is used to guarantee that SSRC values 
never collide." I realize that is logically similar to "MUST have [ssrc 
coordination] in order to share keys", but the spin is a bit different.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] A *new* batch of IETF LC reviews - 2014-09-18

[A. Jean Mahoney]

Hi all,

The following reviewers have assignments:

Reviewer  LC end   Draft
-

Francis Dupont2014-09-29   draft-ietf-forces-packet-parallelization-02

Joel Halpern  2014-09-29   draft-ietf-oauth-jwt-bearer-10

Martin Thomson2014-09-29   draft-ietf-l2vpn-evpn-08

Meral Shirazipour 2014-09-29   draft-ietf-oauth-saml2-bearer-21

Peter Yee 2014-09-29   draft-ietf-v6ops-ipv6-roaming-analysis-05

Robert Sparks 2014-09-30   draft-ietf-6man-why64-05

Roni Even 2014-09-30   draft-ietf-multimob-fmipv6-pfmipv6-multicast-08

Russ Housley  2014-09-30   draft-ietf-appsawg-authres-ptypes-registry-03

Scott Brim2014-09-30   draft-ietf-eppext-reg-08

Vijay Gurbani 2014-09-29   draft-ietf-oauth-assertions-17 *

* 2nd LC


I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html


The standard template is included below.

Thanks,

Jean

---

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-opsec-bgp-security-05

[Jerome Durand (jerduran)]

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

Hi Christer, thanks for sharing the FAQ, I’m not expert in IETF process :-)

> Summary:   The document is well written, and almost ready 
> for publication. However, there are some minor editorial nits that I suggest 
> the authors to address.

:-)

> QG_1:   Please be consistent on whether you write both the RFC- and the 
> reference number, or only the reference number. For example, in section 4 you 
> write “see RFC6192 [18].” and in section 5 “documented in [26].”.

OK

> Section 1:
>  
> Q1_1:Please expand the BGP abbreviation on first occurrence (outside the 
> Abstract).

OK

> Q1_2:The second sentence starts with “This protocol does not directly…”. 
> It is a little unclear what “This” refers to. Assuming you refer to BGP, I 
> suggest you say “BGP does not directly…”.

OK

> Section 4:
>  
> Q_4_1: In the first paragraph, why is “should” be with small letters?

No reason I think. We’ll change that.

> Q_4_2: The last sentence says “For a more detailed recommendation, see 
> RFC6192 [18].”. Recommendation on what?

Recommendation of router protection (section title)
I propose we clarify that in the text:

"For a more detailed recommendation on how to protect the router’s control 
plane, see RFC6192 [18] »

> Section 5:
>  
> Q_5_1: The name of section 5 uses “BGP sessions”, but the 
> section text does not say anything about BGP sessions. And, in section 5.1 
> you only talk about “TCP sessions used by BGP”. Only in section 5.2 do you 
> mention “BGP session”. Perhaps you should add some general text to section 5 
> about BGP sessions, how TCP is used to transport BGP messages in BGP sessions 
> etc, and then in section 5.1 only talk about protection of TCP.

OK, I’ll see how to clearly add session key word in first paragraph of 5.

> Section 15:
>  
> Q_15_1:   s/”about about”/”about”

adopt :-) OK got it :-)

>  
> Q_15_2:   s/”It will not”/”It does not”

OK. I’ll change doesn’t for does not as well in same pargraph then.

Thank you Christer for the review, this is appreciated!

Jerome


>  
>  
>  
> Regards,
>  
> Christer

--
Jerome Durand
Consulting Systems Engineer - Routing & Switching
jerdu...@cisco.com  -  +33 6 35 11 60 50
blogs: http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr
twitter: @JeromeDurand
linkedin: http://fr.linkedin.com/in/jeromedurand

CISCO France
11, rue Camille Desmoulins
92782 Issy les Moulineaux
CEDEX 9
FRANCE







___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-art LC review of draft-ietf-dmm-best-practices-gap-analysis-07

[Elwyn Davies]

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-dmm-best-practices-gap-analysis-07.txt
Reviewer: Elwyn Davies
Review Date: 2014-09-18
IETF LC End Date: 2014-09-25
IESG Telechat date: (if known) -

Summary: Almost ready.  A couple of minor issues (one almost editorial 
and one may be due to my lack of knowledge of the current state of 
Mobile IPv6 security) and mostly a lot of minor language nits.  I think 
there might be some point in numbering the identified gaps to facilitate 
future discussion.


Major issues:
None

Minor issues:
Applicability to Mobile IPv4?  It appears from the early sections that 
this draft is pretty much concentrated on Mobile IPv6 (see the first 
para of s3 which mentions v6 RFCs exclusively and IPv4 seems to be 
mentioned in only a very limited way later) although this is not 
stated.  To avoid wasting people's time, it would be useful to put a few 
words about the relevance or otherwise of this draft to Mobile IPv4 work 
in the introduction (and maybe the title?) before we get to s5.3 where 
there is more clarity.


s6:  I don't know if there is any extra security risk in adding extra 
MAs etc that might allow a malicious party to offer spurious MA and so 
to redirect traffic inappropriately.  I don't know enough about this 
problem space to know how well this is mitigated already.  Might be 
worth a mention? (maybe would affect s5.8 if so).


Nits/editorial comments:
s1: For the uninitiated, a explanation of what a mobility anchor is 
would be helpful.  Quoting some (or even all) of the first para of RFC 
7333 would do the trick nicely.


s1, para 1: s/pose several problems/poses several problems/

s2, last para: s/without the reliance on centrally deployed/without 
reliance on centrally deployed/


s3, para 1:

Although these two are centralized approaches,
Two? Three items are mentioned in the previous sentence, but maybe the 
Host approach and Proxy extension is supposed to be considered as a 
single scheme.  Maybe something like:

  "Although these approaches are centralized,.."
would avoid the confusion.

s3, two instances paras after bullet #3:
OLD

   the
   forwarding management (FM)function is both ends of tunneling at the
   HA and the MN. [MAG in second case]
NEW:
   the forwarding management (FM) function involves both ends of the tunnel
   between the HA and the MN.  [MAG in second case]

s3, last para: s/MAP also has FM function/MAP also provides the FM function/

s4.2, para after Figure 1: Probably best to s/In the figure/In Figure 1/ just
to be totally clear.

s4.2, 2nd para after Figure 1:

IP mobility protocols can be used to provide inter-access mobility
support to users

I don't know if 'inter-access mobility' is acceptable jargon but I would suggest
adding 'mode', 'method' or 'technology' -- thus

IP mobility protocols can be used to provide inter-access mode mobility
support to users


s4.2.1, para 2:

Note
that some of these mechanisms [SDO-3GPP.23.402  
]
 have been defined in
other standards organizations.

It is not clear what 'some' refers to here:  It could refer to the mechanisms
that are noted as not specified [implied, by the IETF?] or someting earlier in 
the
paragraph or stuff in Figure 2 (BT/RO modes?).  Please clarify.

Figure 2:  I like the '' :-) I guess this is supposed to signify a tunnel 
but it
would be appropriate to have a key for '(o)' and ''!  I take it CN1/CN2 are
'Correspondent Nodes' (per section 2) but it might be useful to reinforce this 
in
the key also.

s4.2.1, para after bullets: Please expand acronym CoA on first use.

s4.2.1, para before Fig 3: s/It allows reducing the amount/It allows the 
reduction of the amount/

Figure 4: Oh, dear! Boring old 'xxx' for tunnels. :-(  But I guess it should 
have a key again.

s4.2.2, para after Fig 4: s/Similar to/In a similar way to/

s4.2.2, 2nd para after Fig 4: s/the LMA runtime assignment [RFC6463]/the support
the LMA runtime assignment described in [RFC6463  
]/; s/is mainly aimed for/is mainly aimed 
at/

s4.3, para 1: Is there a suitable overview reference for the EPS architecture?  
Might be useful here.

s4.3, para before Fig 6:

... or at the macro, ...

I have no idea what this means.



Figures 6 and 7:  Something has gone wrong with the layout here.  (Non-ASCII 
characters?)

s4.3, Figure 7 and para before it (and earlier): I think PGW and P-GW, also SGW 
and S-GW, are
supposed to be acronyms for the same thing. Please make this consistent. (PGW 
is used elsewhere
as well).

s4.3, para after Fig 7: I think eNB needs expansion [Thank you 3GPP for the 
heavy duty acronym soup!]

Figure 8: Is "H(e)N

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

[Igoe, Kevin M.]

Ben:

   Comment inline.  As I mention below, the fact that SRTP places
key management out of scope is an annoyance when dealing with
SSRC management.


+--
Kevin M. Igoe   | "We can't solve problems by using the same kind
kmi...@nsa.gov  | of thinking we used when we created them."
|  - Albert Einstein -
+--

-Original Message-
From: Ben Campbell [mailto:b...@nostrum.com]
Sent: Wednesday, September 17, 2014 5:18 PM
To: Igoe, Kevin M.
Cc: draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org; gen-art@ietf.org Team 
(gen-art@ietf.org); IETF Discussion
Subject: Re: Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14

Hi, thanks for the response. Further comments inline. I will remove sections 
that do not appear to need further comment:

On Sep 15, 2014, at 3:02 PM, Igoe, Kevin M. 
mailto:kmi...@nsa.gov>> wrote:

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

Do I undertand correctly that you would need a repeat of all 3 inputs to invoke 
the problem, not just SSRC, right?

Correct.  But the SEQ and POC are counters that start at zero, so their
presence is not helpful.  The IV for the first packet will be (SSRC,0,0),
so only the SSRC guards against repeated IVs.

> 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

Can you elaborate on your user base? Is this draft intended for general use?

As you can see from my e-mail address, my mission is to provide information
assurance for producers/consumers of US Gov't classified data.  My goal is to
help bring commercial gear up to a point where it could be used with classified
traffic. The classified community isn't alone in needing iron clad security; 
banks,
financial institutions, and many other organizations have an equally serious 
need
for iron clad security (this is my co-author's focus).

This I-D started life as an informational RFC, but early on it was requested 
that
this I-D be moved to standards track because of its wide applicability, 
resulting
in the current document.


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

Does the "source" in each source mean the synchronization source?

These terms get a little slippery, bit what I mean is the gear responsible
for encrypting outgoing data. Let's call this the originating box.

I'm not entirely sure I follow you, but I read this to mean you avoid the need 
for central management of SSRCs by not sharing keys between more than one 
originator? (that is Assumi

Re: [Gen-art] Gen-ART review of draft-dukhovni-opportunistic-security-01

[Jari Arkko]

martin,

Thank you for this and other reviews.

This is also an acknowledgement that we’ve seen the review (I always look at 
these reviews before recommending a position for the IESG review, which is 
happening today for this document). I have not filed issues specifically 
relating to your comments, but there is a more general discussion about the 
document. Stay tuned.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-grow-ix-bgp-route-server-operations

[Romascanu, Dan (Dan)]

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: 
http://www.ietf.org/id/draft-ietf-grow-ix-bgp-route-server-operations-03.txt

Reviewer: Dan Romascanu

Review Date: 9/18/14

IETF LC End Date: 9/22/14

IESG Telechat date: none



Summary:



A useful and very well written document, with a few minor issues that need 
clarification and fixes before publication



Major issues:



None



Minor issues:



1.   The reference [RS-ARCH] mentioned in 4.2.1.1 and 4.2.1.2 is not 
reachable (Error 404). As the understanding of the issues described in the two 
sections depend on this reference, a valid reference is required.

2.   Section 4.2.1.3 uses the term 'flat layer 2 network' which has at 
least two meanings depending on the context or layer - either one VLAN space at 
the link layer (as to differentiate from Customer VLAN and Provider VLAN) or a 
bridged network with no routers between the bridged segments. Clarification is 
needed.

3.   The usage of keywords is inconsistent in a few place. In 4.6.1 the 
'should' in the second paragraph needs to be capitalized. In 4.6.3 we have a 
capitalized SHOULD, but then a non-capitalized 'may' for statements that both 
seem to describe requirements of the same level.

4.   I am doubt that Section 4.7 is that useful. On one hand reliability of 
layer 2 forwarding is not in my opinion such a big issue, and measures can be 
taken a the link layer to improve it (use lags or redundant paths). Second the 
recommended mitigation (RFC 5881 BFD) is described as non-optimal, with no 
other alternative. I would just drop this section completely.



Nits/editorial comments:



1.   The English syntax of the second paragraph in the Abstract is broken.

2.   In the introduction there is a mention of 'using shared Layer-2 
networking media such as Ethernet'. Actually Ethernet is seldom used nowadays 
as a shared media, I would just recommend saying 'using data link layers 
protocols such as Ethernet'

3.   In section 4.2 s/optimization technique is implemented/optimization 
technique that is implemented/





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art