IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-11-03. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
Telechat:
2.2 Individual submissions
2.2.1 New items
Telechat:
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
Telechat:
1054 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
1107 EDT Adjourned
(at 2016-11-03 06:02:56 PDT)
draft-ietf-netmod-routing-cfg
Should the reference to 6536. Be normative?
If there exists a draft for a yang module that augments this in a way that includes cryptographic values (e.g. maybe for an IPsec VPN or something) then I think that'd be a nice addition to section 11 as an informative reference.
* Have you considered including support for the Route Information Option (RFC4191)? Seems like it would be useful. * default-lifetime is defined with a range of 0..9000 in this document but the upper limit will be raised to 65535 if and when draft-ietf-6man-maxra is approved. Is there a mechanism by which you can easily support this increased upper limit?
draft-ietf-l2tpext-keyed-ipv6-tunnel
I have just a few minor comments: - 1, 2nd paragraph: The first sentence is convoluterd; can it be simplified? -- "upon receipt on each tunnel": on receipt of packets? -6: Please expand OAM, MEP, and MIP on first mention. -11.2: RFCs 1981, 4623, 4720, 5085. 5883, and 5885 are all cited in the context of 2119 language. They should probably be normative references. (In my opinion, even citations for optional features need normative references if they are needed to fully understand the features.)
Two questions: 1) I assume this was in depth discussed in the wg but the given reasoning for the following MUST does still not justify a MUST for me: "All packets MUST carry the 64-bit L2TPv3 cookie field." I would assume that there are possible deployment scenarios e.g. within a single domain where other existing protection mechanisms might be sufficient already that you don't really need the cookie...? 2) Further this is not normative language and i wonder if it should be: "However, for compatibility with existing RFC3931 implementations, the packets need to be sent with Session ID." Again I assume that this could be a SHOULD because if you know that you don't have devices that (only) implement RFC3931, you could probably even neglect the session id...?
* Section 5 I am having a hard time seeing how fragmentation is expected to work It is NOT RECOMMENDED for routers implementing this specification to enable IPv6 fragmentation (as defined in section 4.5 of RFC2460) for keyed IP tunnels. IP fragmentation issues for L2TPv3 are discussed in section 4.1.4 of RFC3931. And that specific section of RFC3931 recommends using RFC2473 to tunnel the packets which again ends up using the RFC2460 fragment header that this draft is trying to forbid. So, can you please clarify exactly what happens when the size of the packet to be tunneled exceeds the MTU?
Modifications are needed to resolve the comments raised in Paul's Gen-ART review.
draft-ietf-stox-7248bis
Minor comment: The shepherd write-up says it's for version -05 (now -13).
Review based on diff vs 7248 [1] Thanks for adding 9.2. I agree with Alissa's comment. [1] https://tools.ietf.org/rfcdiff?url1=rfc7248&url2=draft-ietf-stox-7248bis-13.txt
I was also a Yes on the draft that became RFC 7248, and this revision is a significant improvement (even beyond the corrected architecture). I especially appreciate the working group adding an actual introduction to the Introduction ...
Below is a small suggested edit for text in Section 9.2. I think the normative "MUST honor data about ..." construction is vague. OLD Therefore, a gateway MUST honor data about the intended recipient of a presence notification (as represented by the 'to' address for XMPP and by the Request-URI for SIP) and it MUST NOT route or deliver a presence notification to any other entities, because it does not possess information about authorization to receive presence notifications for such entities - that information resides at the user's home service, not at the receiving gateway). NEW Therefore, a gateway MUST NOT route or deliver a presence notification to any entity other than the intended recipient (as represented by the 'to' address for XMPP and by the Request-URI for SIP), because it does not possess information about authorization to receive presence notifications for such entities - that information resides at the user's home service, not at the receiving gateway).
draft-ietf-p2psip-share
I have a one set of substantive comments/questions, and some editorial comments: Substantive: - I'm confused about the validation procedure. In step one, is this the user name of the user attempting to write the resource? In step 5, I do not understand how this terminates. Which ACL item is the "previously selected" one. If that refers to the one selected in the last iteration of steps 3 and 4, how do you know there are not more ACL items to iterate through? Editorial: -1, first paragraph, first sentence: s/that/, which -- recurring singular plural mismatch "resources with a variable name". -1, 2nd paragraphs: "It transfers the authorization..." What is the antecedent for "it"? -3. First paragraph after numbered list, "user called Authorized Peer": missing article. -3.1, 3rd paragraph: Is the SHALL appropriate? Is an authorized user actually required to access the array in the first place? - 6.5, first paragraph: Does the MAY grant permission, or is it a statement of fact? -6.6, paragraphs 3 and 4: Are the MUSTs appropriate? Are there not other (perhaps application specific) reasons one might choose not to write the value? -- 2nd paragraph from end: The MUST seems more like a statement of fact. (E.g. "The resulting ... integer is used...") - 4.1, last paragraph: s/implementations/implementors - 4.2, definition of res_name_ext: The sentence starting with "This name serves..." is hard to parse. -5.1, 4th paragraph (paragraph after example) : s/witch/which
Quick questions on sec 6.3. (Validating Write Access through an ACL): Do I really need to validate the authorization chain in the ACL every time I give access to a resource? Wouldn't I rather validate the ACL when it's modified and then simply assume that it is sufficient that I have an entry in the ACL to provide access?
- General: this feels more like an experimental spec. If the authors didn't object I think that'd be more appropriate. - General: can these ACLs be resources to which access is controlled via another of these ACLs? If so, then it seems like there may be some nasty corner-cases where things get lost (so nobody can change 'em in future) and I don't see how one might recover from that. (Apologies if I'm just mixed up here, I read this fairly quickly and didn't reload RELOAD into my little head first;-) - 3.1: 24 bits of collision resistance isn't many. I'm not clear why that's ok - 3.1, last para: SHA-1 isn't a good example really, SHA-256 would be better today. - 5.3: Is the mapping to USER and DOMAIN from certificates well-defined? It may be in RELOAD, I forget, sorry;-) It doesn't seem to be well-defined here anyway.
Below is Rick Casarez's OPS DIR review: Section 6.5: "Since stored values could have been modified or invalidated prior to their expiration, an accessing peer SHOULD use a Stat request to check for updates prior to using the data cache" When considering security, and how this works, I would recommend changing this to MUST or advising that the lifetime be set very low. A stale ACL could allow access were none should occur.
Thank you for addressing the SecDir review findings. https://www.ietf.org/mail-archive/web/secdir/current/msg06890.html
draft-ietf-netconf-yang-patch
This document may have the clearest terminology section I've ever seen in a draft. Thank you all for that! I have the same question as Ben did in his Discuss, about just how atomic a patch operation is. I'll watch the discussion in that thread.
Hopefully this is easy to resolve, and is probably just confusion on my part. But I am confused by whether or not the edits in a single patch are expected to be atomic. I assumed no, since the results can speak to multiple edits, but section 5 mentions atomicity as a RESTCONF requirement. Is atomicity not required by yang-patch in general, but required when using RESTCONF? Section 5 goes on to talk about disruption due to partial processing, which further confuses me if RESTCONF requires atomicity.
-2, 2nd paragraph, last sentence: is the message body mentioned in the last sentence the same as the one described by the media type in the previous sentence? That is, are we talking about one body part, or two? If one, the ordering of the 2nd and 3rd sentence is a bit confusing to me. -2.2, tree diagram: If edit-id is optional, how are errors identified if it is not present? -2.6, first paragraph: "...RESTCONF server SHOULD return a "yang-patch-status" message." What if it doesn't? (I.e. Why not MUST?) -2.7, 2nd paragraph: "... SHOULD return a "yang-patch-status" message." What if it doesn't? Editorial: -2, first bullet: s/at within/within -2, Accept-Patch example: The example seems misplaced, as it seems to apply to the text two paragraphs back, not the immediately proceeding paragraph.
Thank you for a well written document. A couple of small nits in your media type registration: 4.2.1. Media Type application/yang-patch+xml Subtype name: yang-patch Should be "yang-patch+xml" Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to the XML Encoding Rules and Canonical Format for the specific YANG data node type defined in [RFC7950]. In addition, the "yang-patch" YANG Patch template found in [RFCXXXX] defines the structure of a YANG Patch request. If you are allowing any of UTF-16 encodings, then the above is not correct and should say "Binary". Fragment identifier considerations: Fragment identifiers for this type are not defined. I suggest you just say "The same as for application/xml". It would be good if you register a new file extension for this media type.
This should be easy to resolve through discussion or some text tweaks. In the security considerations section, I see some text that hints at my questions below, but isn't clear enough, so I'd like to discuss it to see if these things are covered, or why they are not, and to see if we can tweak the text a bit. The following text is helpful, is PATCH described in [I-D.ietf-netconf-restconf]? This document defines edit processing instructions for a variant of the PATCH method, as used within the RESTCONF protocol. I see section 2.7 discusses error handling and validating the YANG module, but is there a way that the hash (or some other mechanism) of the patch could be validated to ensure the patch was not altered. Is that already described for PATCH? I also see this text in the security considerations section: It is important for RESTCONF server implementations to carefully validate all the edit request parameters in some manner. Is the source of the patch authenticated? Can the client receiving the patch be authenticated? Is this handled through RESTCONF? Since YANG modules could add in write capabilities, unauthenticated patches could result in opening backdoors or revealing information that was not intended. You are covering it with that statement, but it's not clear if both ends can be authenticated and there are attacks if they are not authenticated.
Nit: In section 2.2 YANG Patch does not provide any access to specific datastores. It is am implementation detail s/am/an/
draft-ietf-stir-certificates
Sorry but I have a load of discuss points on this one. I don't think any of 'em are that hard though, except maybe one. (I'll let us all guess which one:-) (1) TN auth list services - IIUC, these are not free today. Is that correct? It's not clear to me that alternatives such as listing all good numbers inside a cert are practical. Did the WG have an explicit consensus that building in a requirement to have verifiers pay to be an effective RP is ok? If so, can you send a pointer to the list archive or minutes where that was agreed. If not, don't the WG need to explicitly ok that? (2) setion 8: you need to say more clearly exactly what the IA5String values in the extension map to in the JWT. I assume it's the field names but you don't say. You need to say if this extension can or needs to be critical. (3) section 9: you need to say whether this extension needs to be or can be critical and where in the cert path it's allowed to be and how to interpret things if >1 cert in the path has this extension (if that's allowed, and if it is, then complexity awaits us;-). (4) section 10: you need to pick one MTI method I think. Why is that wrong? You nearly, but not quite, do. Why not just do it? (5) section 10: don't you need to somehow define "short-lived"? That could be defined as an RP-configurable value, but even if so, I think you need to say that. Even if you do that, I'm not sure that an RP-configured value is right as short-lived certs, vs. not, puts a different burden on the signer and if the signer and RP have different ideas of what short-lived means, then interop failures seem likely. Bottom line for this point: what's a short lived cert? (6) section 10: as with short-lived, don't you need to define HVE? (7) section 10.2.1: Can OCSP be made use HTTPs here? If not, then you have the RP sending out the caller's TN in clear. That seems bad (cf. BCP188). Did the WG consider that? If this spec needs OCSP/HTTPs then I think you need to have a new MUST for that (it's uncommon or maybe never done?) and address the potential bootstrap issues. (But I didn't think those through - did the WG?)
General - So a passport structure or SIP message can have a URI for the cert. And the cert can have URLs for OCSP and AIA and for a TN download service. That's potentially an awful lot of comms out of the RP to do STIR. Has someone put all that together into a usable assembly? If so, where's that documented? (To be open about it, I was more of a fan of the DKIM starting point for this work, but that's really just opinion, so this is definitely a non-blocking comment. I'd still be intersted in an answer though.) - section 5: "Assignees of E.164 numbering resources participating in this enrollment model should take appropriate steps to establish trust anchors." That's ambiguous. Do you mean they should establish a list of other folk's public keys they trust or that they should generate their key pair and get their public key on other folk's list of trust anchors? - section 7: What's the REQUIRED for EST about? That just seems wrong. - section 10: SCVP? Really? Does anyone do that? I'd say get rid of that text, it'll only cause grief. - section 10: "CRLs are an obviously attractive solution" hmm - s/obviously/initially/ would seem more accurate. - 10.2: last two paras are speculative - do they belong in a spec like this? If so, maybe re-word 'em so that they're not going to confuse an implementer?
I have one small issue that I would like to discuss before recommending approval of this document: Reading Section 8 I was unable to figure out what are "claim", "permitted" and "excluded" and what exact syntaxes they use. I think this is underspecified. You are probably missing some references, examples or both.
URI (RFC 3986), HTTP (RFC 7230) and HTTPS (RFC 2818) need to be Normative References.
Introduction: nit, Robocallers use impersonation as a means of obscuring identity; while robocallers can, in the ordinary PSTN, block (that is, withhold) their caller identity, callees are less likely to pick up calls from blocked identities, and therefore appearing to calling from some number, any number, is preferable. s/appearing to calling/appearing to call/ Section 10.2.1: I'm wondering why SHA-1 is described as follows instaed of discouraged/not allowed ... o There is no requirement to support SHA-1, RSA with SHA-1, or DSA with SHA-1. I don't see any references to RFCs that update RFC5280, like RFC6818. It would be good to include these since 5280 is used for revocation methods mentioned. 6818 is for CRLs.
draft-ietf-stir-passport
Deterministic ECDSA (RFC6979) gets rid of a significant weakness with ECDSA. IIRC when JOSE was done there was a feeling that adding a MUST or SHOULD for that was tricky due to lack of support in libraries. When we recently re-checked for COSE, the answer was that today, it's ok to have that as a MUST or SHOULD. (If some kind of FIPS-140 stuff precludes a MUST, then a "SHOULD unless you're sad enough to be stuck having to pay lip lipservice to FIPS-140" clause might be right. So the DISCUSS point here is: given the real-world demonstrated weakness inherent in the need for an RNG in ECDSA why didn't the WG choose to at least RECOMMEND deterministic ECDSA? (Or better, make it a MUST.) If the answer is: "we thought about it [ref] and decided to not require deterministic" then I'll clear. But even if the WG did consider it a couple of years ago, the situation may have changed so a quick re-think might be worthwhile.
"The claim value for the "tn" claim is the telephone number and MUST be canonicalized according to the procedures specified in [I-D.ietf-stir-rfc4474bis] Section 8.3." This indicated that's section 8.3 of ietf-stir-rfc4474bis belongs in this doc. Is there are reason why it is in ietf-stir-rfc4474bis instead?
Editorial feedback from Bert Wijnen, our OPS-DIR reviewer: While I was at it, I found someNits and/or typos: The abstract states: The PASSporT token is cryptographically signed to protect the integrity of the identity the originator and to verify the assertion of the identity information at the destination. s/the identity the originator/the identity of the originator/ Or so I think. section 5.1.1 states: As defined the "iat" should be set to the date and time of issuance of the JWT and MUST the origination of the personal communications. The time value should be of the format defined in [RFC7519] Section 2 NumericDate. Is that a correct sentence? or is the a verb missing around "the JWT and MUST the origination" ??? Section 5.2.2 5.2.2. "mky" - Media Key claim Why such a cryptic "mky". Why not "mkey" ?? I can live with it. I just wonder why we make it more cryptic than needed. Section 10.2 2nd bullet In many applications, the end user represented by the asserted identity represents and signer may not be one in the same I do/did not know the term "one in the same". I do know "one and the same". I guess other people may have the same knowledge as I do (as non native English speaker) Bert
Thanks for a very well written example of how to use some of the JOSE work. In section 9.1 there's another nit that was not identified (that I can see) by other reviewers. This section demonstrate the deterministic JSON s/demonstrate/demonstrates/
Nit: In Sec 5.1.1: "As defined the "iat" should be set to the date and time of issuance of the JWT and MUST the origination of the personal communications." I assume that should be "MUST be" ?
This is generally a well written and detailed document. Thank you. I have some minor comments: 5.1.1. "iat" - Issued At claim The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined claim Issued At. As defined the "iat" should be set to the date and time of issuance of the JWT and MUST the origination I think a verb is missing between "MUST" and "the origination" of the personal communications. 5.2.2. "mky" - Media Key claim 2. Sort the lines based on the UTF8 encoding UTF-8 needs a normative reference (RFC 3629). of the concatenation of the "alg" and "dig" claim value strings. 7.1. Example Compact form PASSporT Token eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 I decoded this and it looks reasonable: {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/passport.cer"} . eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI 6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0 OpenSSL produced the following: {"dest":{"uri":["sip:alice@example.com"]},"iat": this looks like a truncated value. Is something wrong with the value or is this an OpenSSL bug?
draft-ietf-stir-rfc4474bis
This should be an easy one to fix (or else I'm missing stuff, which is quite possible) but if a fix is needed then it'd impact on interop... In 8.3, I think the ABNF conflicts with the E164Number definition in the certs draft which disallows "#" and "*" (if I understand the "FROM" clause in the ASN.1 module correctly).
This is a well written document (despite giving too many deployment choices in some areas). I have a short list of small issues/nits: In Section 4: ABNF for the signed-identity-digest allows empty string? Is this intentional? If not, maybe use "1*" in front? In Section 5.1: are you missing an empty line between the header and the SDP payload? In Section 6.2.2: is it customary in SIP to use the human readable portion of error responses? In Section 7.4: HTTP URIs need a reference. In Section 8.4: URI-ID from RFC 6125 can be used for the subdomain case as well?
Thanks for this work. I'm balloting yes, but have a few minor comments and questions: Substantive: - 6.2, step 4: This says that if the full form of passport is included, and the Date header and iat do not match, use iat if it is fresh. I'm curious why not just use iat in the first place? What should one do if Date is fresh, but iat is not? -6.2.2: This section recommends specific result code reason phrases for a couple of circumstances. I assume the idea is that one should use a "helpful" reason phrase, and these are examples of phrases helpful for the circumstances. But it reads as if you mean to standardize those specific reason phrases. If the intent is really to offer examples, please clarify. I'd hate to see us back in the days of commonly seeing SIP code break due to unexpected reason phrases. - 7.2: The first sentence says verifiers must have a way to acquire and _retain_ certificates. Why must they have a way to retain them? The last paragraph in the section says they might wish to have a way to retain certs, but doesn't seem to require it. -- Is there any concern that the requirement to be able to dereference effectively arbitrary URLs in "info" parameters could become a DOS attack vector? E.g. info parameters that point to HTTP URIs that never respond, respond very slowly, or return huge and/or corrupt certs? -13.1 and 13.2: Is there a reason not to retarget the references in the IANA entries for the Identity header field and for the error codes from 4474 to [RFCThis]? Editorial: - 4.1.1, example: I assume the backslashes indicate line folding for documentation purposes only. It might be worth mentioning that. - 6.1, step 4, last paragraph: Is the reference to section 9 mean that section of _this_ document, or that section of stir-passport? - 7.1, 2nd paragraph: It seems odd to use 2119 MUSTs in examples of policies that authenticator services might have. -8.1, third paragraph: s/exampple/example
Thanks for a well written document. Just one comment, I would have liked to have seen section 10 much sooner in the document, maybe in the introduction as changes are usually up front.
One minor comment: Not sure how the solution with "ppt" field came up for extensibility. Wouldn't it make sense to have a version field instead that always has to be presented (or if not present is assumed to be 0); just to reduce implementation complexity. Or am I missing something? Just wondering... btw. what does 'ppt' stand for? (Added later) Now I have read draft-ietf-stir-passport. So it clear why this method is used. Didn't realize that the following sentence means 'please check PASSporT for further questions...': "this specification specifies an optional "ppt" parameter of the Identity header field, which mirrors the "ppt" header in PASSporT." Maybe just give a more specific reference including the section refernce.
draft-ietf-radext-ip-port-radius-ext
Thanks for addressing most of my comments, especially the one about privacy sensitive information in IP-Port-Local-Id TLV. However, I note that the summary for the IP-Port-Local-Id TLV in section 3.1.3 still mentions the potential for it to carry a MAC address. [Edit: The suggested changes in Alissa's current comment would help mitigate that.]
Thanks for removing the ICMP identifier thing. OLD COMMENTS below. I'm happy to chat about 'em if we need to. - write-up: Yeah, major yuks to leaving design decisions to IANA. While the folks there are quite capable, they are not able to make IETF consensus decisions. If the WG aren't sure, ask IANA personnel (or someone) and then verify that that outcome garners rough consensus back in the WG or using other IETF processes. So Alissa's discuss point#4 is entirely, completely and fully correct and a showstopper really. - I also agree with the issue called out in Joel's comment about mission creep and how this overlaps with PCP. Did the WG consider whether or not it is a good idea for the IETF to define multiple ways in which some of these features can be added? If so, what is the justification for there being more than one? (Is that somewhere in the WG list archive? If not, it ought be.) It may well be that having a RADIUS mechanism for this is also a good plan, but I think that ought be justified. - 4.1.4: using port 80 as an example is very 1990's. Would it not be better to be more up to date? That's not just a facetious point - web cameras being left open to the Internet are a major swamp for botnet gestation. Better to use a more desirable example really. - The secdir review [1] also noted a bunch of issues that as far as I can see received no response so far, but that do deserve a response. (Apologies if I missed a response.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06736.html
Thanks for addressing my discuss! Here is some further feedback from the IE-Doctors: The description of the requested Information Element is still a bit vague, but acceptable; one must read the document in order to understand that binding the value to and end-user is really binding to one or more (source) addresses. The reference to section 3.2.2 (which is, IMO, not any more explanatory than the description of the IE itself) is not necessary.
* Does the IP-Port-Limit include the count of ports already allocated through the IP-Port-Forwarding-Map or not? * I agree with Alissa's DISCUSS points about the lack of error handling and the privacy issues and Mirja's DISCUSS point about restricting transport protocols to TCP and UDP.
I agree with Alissa's questions.
The document really improved. Thanks. - Section 2. Terminology. Typically, you want to have that note at the beginning: Note that the definitions of "internal IP address", "internal port", "internal realm", "external IP address", "external port", "external realm", and "mapping" are the same as defined in Port Control Protocol (PCP) [RFC6887], and the Common Requirements for Carrier- Grade NATs (CGNs) [RFC6888]. If I know of RFC6887 and RFC6888, I don't read the definitions. You mentioned that you would fixed this. It seems that this paragraph disappeared. Is this intentional? - Normative references to IANA registries, I'm not sure. I guess the RFC-editor would correct that, if it needs to be.
Maybe it is just me, but I found that the idea that most subattributes are the same size, but right aligned to be wasteful. Is this a common design pattern for Radius? I am agreeing with Alissa on privacy concerns. On page 12: IP-Port-Int-IPv6-Addr TLV This TLV contains an IPv4 address that is associated with the Typo: should be IPv6? internal IP port number contained in the IP-Port-Int-Port TLV. For IPv6 network, either this TLV or IP-Port-Local-Id TLV must be included as part of the IP-Port-Forwarding-Map Attribute. Refer to Section 3.2.5.
Thanks for responding to my DISCUSS and COMMENT. I understand that this document is not the appropriate place to specify error handling related to these attributes. I do still think adding a note about the potential consequences of communicating erroneous port range and port mapping information would be a good precaution here. In 3.2.11 the new text helps but I think there are a couple more changes necessary to make the constraints explicit: OLD localID string. The data type of this field is string (refer to [I-D.ietf-radext-datatypes]). This field contains the data that is a local session identifier at the customer premise, such as MAC address, interface ID, VLAN ID, PPP sessions ID, VRF ID, IP address/prefix, etc. IP-Port-Local-Id TLV MAY be included in the following Attributes: NEW localID string. The data type of this field is string (refer to [I-D.ietf-radext-datatypes]). This field contains the data that is a local session identifier at the customer premise, such as MAC address, interface ID, VLAN ID, PPP sessions ID, VRF ID, IP address/prefix, or another local session identifier. IP-Port-Local-Id TLV MAY be included in the following Attributes if it is necessary to identify the subscriber:
Tim Chown Tim.Chown@jisc.ac.uk provided the opdir review. At this time, this position is not a discuss, but I would like to see a discussion or pointer to a dicussion on the role of this method vs pcp. thanks joel Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines three new RADIUS attributes to be used when communicating with a RADIUS server to facilitate the configuration or reporting of IP and port ranges used with a network appliance, typically a CGN, where there is a need to constrain the ports available per customer where IP address sharing is in use. The three RADIUS attributes are: IP-Port-Limit-Info - defines the maximum number of ports available IP-Port-Range - the specific range of port numbers available IP-Port-Forwarding-Map - to configure port forwarding on a NAT/CGN device I would consider the document to be "Ready with Issues". I have some general comments, followed by some specific comments. Note that while I am familiar with RADIUS (from an eduroam context) the draft is not one I was familiar with or followed prior to this review. Thus these comments may have already been addressed. General comments: There are at least two areas in which this document has "creep". One is that it is providing an alternative method to PCP to define port forwarding mappings on a device. So there is an open question as to whether PCP should be the method of choice for this function, or whether we wish to create a new way to establish such mappings. Secondly, two of the new attributes support inclusion of a new TLV, IP-Port-Local-Id, which allows user/device-specific information to be transmitted via RADIUS, such as MAC address or VLAN ID. While this is intended to allow differentiation of users for accounting/identification r, in doing so it adds an additional potential privacy concern into a new RADIUS attribute, depending on specific use cases of the TLV. This is not discussed in the Security Considerations section, but probably should be. I note the new attributes use a number of IPFIX information elements; has the draft considered its relationship to draft-ietf-behave-ipfix-nat-logging-09, which says the "lack of a consistent way to log the data makes it difficult to write the collector applications that would receive this data and process it to present useful information"? This draft is introducing a new method to log such elements; is this a concern at all? The examples of use cases of the new attributes include both NAT44 devices and CGNs. The document could state more clearly the address sharing scenarios, perhaps with a simplified network element diagram for each example, showing the user/host, CPE/NAT44, and NAT444/CGN? Some additional clarity here would be useful (see also comments below). Also, the term "the user" is used in many places in the document where in practice "the customer's CPE" would be more appropriate. Specific comments: NAT64 is mentioned as a use case at the start, but no example is given later in the document. This might add useful value. In Sections 3.2.6, 3.2.7, 3.2.9 and 3.2.10, the IPFIX information elements in the TLV are 16 bit values, but 32 bits are reserved for the element. Similarly the NatEvent element is 8-bit, but has 32 bits reserved. It would be useful if the document stated why these elements are being padded out to 32 bits. In Section 4.1.1, I don't think NAT64 is specifically designed to multiplex users over a smaller number of shared IPv4 addresses, rather its primary design goal is to facilitate access to legacy IPv4 content from IPv6-only networks. The text should be clarified. Also in 4.1.1, do users really have service agreements that state port limits? If they do, I doubt users are aware of them (or care...), and the issue is beyond the scope of this document. In 4.1.2, I think you mean "block", not "bulk"? And the comment on "randomization" might fit better in the Security Considerations section if you discuss privacy there (which is presumably what you mean?) Also in 4.1.2 you discuss the scenario as if it's CGN, but the flow diagram shows only the NAT44 (presumably in the CPE) and not an ISP CGN. The same happens in 4.1.3; discussion of CGN and NAT44 interchangeably, without the diagram showing there may (presumably) be mappings to establish at both the user's CPE and the ISP's CGN. And in 4.1.4 the example talks of NAT44 for Joe's CPE, but then also about a CGN allocating more ports; is that at the NAT44, or at the CGN? (These specific NAT44/CGN comments are examples of the general comment I made earlier.) In Section 5, I found the format of the table with 0 and 0+ a little unintuitive. -- Tim _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
draft-murchison-nntp-compress
"In the case of a conflict between these two documents, [RFC3977] takes precedence." Really? I'd hope there is no conflict... And nit? In sec 7: "it MUST use the STARTTLS, AUTHINFO, and COMPRESS commands in that order." and "That is why this specification only prohibits the use of AUTHINFO after COMPRESS." Should this be 'before' instead of 'after'...?
Thank you for addressing the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg06916.html And also for letting us know about an upcoming draft that: 'discourages the use of TLS-level compression, thus dealing with authentication layered with a TLS-level compression method.' https://www.ietf.org/mail-archive/web/secdir/current/msg06923.html
Thanks for taking up the baton that TLS had to drop due to CRIME! 1.3: I hope the RFC editor can try new format things to meet these requests. One question for the authors might be whether you'd prefer an RFC now or to wait a bit (should a wait be needed) if tooling needs changes to handle properly representing folks' names? 2.2.1: the "algorithm" parameter description doesn't seem to match the example in 2.1 which specifies two algorithms. The ABNF seems to agree with 2.2.1.
draft-ietf-httpauth-mutual
Thanks for writing a very detailed document. A few minor comments. 1) Please review the introduction, there are several grammatical errors in there. Meaning still came through just fine, but they were a little distracting. 2) The state machine diagram of the client is quite complex. A candidate for the new RFC format? 3) I agree with Alvaro's comment on the IPR. Thank you for making it royalty free, however not sure you need to add the text in the RFC. 4) This to me seems as it is essentially a shared secret construct, one sentence from RFC 2361 (security considerations) seems applicable here. "All the security in this system is provided by the secrecy of the private keying material." If this the case, please provide ample warning that (as one would expect) loss of the password from either the client or the server results in a complete compromise.
Thanks for this well written spec! One important question: Doesn't this spec need to register a new HTTP Authentication Schemes ("Mutual") with IANA? Further minor comments/questions: 1) Somehow I don't understand this: "For responses, the parameters "reason", any "ks#" (where # stands for any decimal integer), and "vks" are mutually exclusive; any challenge MUST NOT contain two or more parameters among them. They MUST NOT contain any "kc#" or "vkc" parameters." Who is 'they' in the last sentence? 2) "Typically, clients can ensure the above property by using a monotonically-increasing integer counter that counts from zero up to the value of nc-max." Wouldn't it be better to use a randomized number? 3) Nit: s/Even if the request-URI does not have a port part, v will include the default port number./Even if the request-URI does not have a port part, vh will include the default port number./
This is generally a well written document. I have a couple of important comments that I would like to see addressed and several less significant comments. 1) As Mirja pointed out, this spec needs need to register "Mutual" HTTP Authentication Schemes with IANA 2) In Section 7: If HTTP is used on a non-encrypted channel (TCP and SCTP, for example), the validation type MUST be "host". If HTTP/TLS [RFC2818] (HTTPS) is used with a server certificate, the validation type MUST be "tls-server-end-point". If HTTP/TLS is used with an anonymous Diffie-Hellman key exchange, the validation type MUST be "tls-unique" (see the note below). Implementations supporting Mutual authentication over HTTPS SHOULD support the "tls-server-end-point" validation. Support for "tls-unique" validation is OPTIONAL for both servers and clients. I think the two paragraphs are in conflict. For example, the first one says that if TLS with server certificate is used, then "tls-server-end-point" MUST be supported. But the second says that it is SHOULD be supported. If the intent of the first paragraph is to say what should appear syntactically, while the second paragraph explains what kind of validation is actually required, I think this still can be made clearer. I suggest you either delete the second of these 2 paragraphs, or you need to reword text in the first (and possibly the second) to specify a non conflicting set of requirements.
I agree that the Introduction section might need an editing pass. In Section 1, next to the last paragraph: The Mutual authentication protocol proposed in this document is a strong cryptographic solution for password authentications. It mainly provides the two key features: Exactly the same paragraph appears earlier in the same section. Did you forget to delete this instance? 3.2. Values The parameter values contained in challenge/credentials MUST be parsed strictly conforming to the HTTP semantics (especially un- quoting of the string parameter values). In this protocol, those values are further categorized into the following value types: tokens (bare-token and extensive-token), string, integer, hex-fixed-number, and base64-fixed-number. For clarity, implementations are RECOMMENDED to use the canonical representations specified in the following subsections for sending values. Recipients SHOULD accept both quoted and unquoted representations interchangeably as specified in HTTP. I think the last SHOULD must be a MUST, because clients that generate these values might be using libraries that automatically quote values. So this is really not under sender's control. 3.2.2. Strings All character strings MUST be encoded to octet strings using the UTF-8 encoding [RFC3629] for the ISO 10646-1 character set [ISO.10646-1.1993]. This is the same as Unicode 1.1. Unicode now released version 9.0! I suggest you use a Unicode reference. In 3.2.3: I think you are overusing SHOULDs instead of MUSTs in many places in the document (not just just in this section). For example: When these values are generated from any cryptographic values, they SHOULD have their "natural length"; if these are generated from a hash function, these lengths SHOULD correspond to the hash size; Why not a MUST here? if these are representing elements of a mathematical set (or group), its lengths SHOULD be the shortest for representing all the elements in Again, why not a MUST? Having a unique encoding will improve interoperability. the set. The numbers represented as base64-fixed-number SHALL be generated as follows: first, the number is converted to a big-endian radix-256 binary representation as an octet string. The length of the representation is determined in the same way as mentioned above. Then, the string is encoded using the Base 64 encoding [RFC4648] I assume you meant Section 4 alphabet and not Section 5 alphabet from this RFC. Please add section reference to the above. without any spaces and newlines. Implementations decoding base64- fixed-number SHOULD reject any input data with invalid characters, excess/insufficient padding, or non-canonical pad bits (See Sections 3.1 to 3.5 of [RFC4648]). 7.1. Applicability notes When the client is a Web browser with any scripting capabilities, the Can you explain why scripting capabilities are important here? underlying TLS channel used with HTTP/TLS MUST provide server identity verification. This means (1) anonymous Diffie-Hellman key exchange cipher suites MUST NOT be used, and (2) verification of the server certificate provided by the server MUST be performed. In Section 9: In both cases, it is the sender's duty to correctly prepare the character strings. If any non-normalized character string is received from the other peer of the communication, recipients MAY either use it as a bare UTF-8 string without any preparation, perform any appropriate preparations (which may cause authentication failure), or reject any ill-prepared inputs from the sender and respond as a communication error. I think you are giving too many choices which might cause interoperability issues. Even reducing the choices from 3 to 2 would help here. In Section 11: * Otherwise, send a 200-VFY-S response. If the session was in the "key exchanging" state, the session SHOULD be changed to an "authenticated" state. The maximum nc and nc flags of the state SHOULD be updated appropriate. Can you explain why these 2 SHOULDs are not MUSTs? I.e., what are possible reasons for a server implementation to violate these SHOULDs? In Section 15: It would be good to be able to bind extension data to shared secret constructed by both parties.
Most of my comments have already been covered by others. I agree with others that the introduction really needs more editing. I share the question about the IPR section. In general, IETF stream documents are not expected to contain licensing language beyond that in the TLP. OTOH, that's about copyright, and this is clearly not--but I wonder why the existing IPR disclosure is not sufficient. If the section is to remain, I suggest making sure this has been reviewed by someone from the IETF trust prior to publication. - Section 16: I don't think 2119 MUSTs are appropriate for IANA instructions. -- I think the registration policy you are looking for is "Specification Required".
Comments from Meral's Gen-ART review should be looked at.
Forget about my last COMMENT, which was for a different draft
I agree with Alvaro on concerns about the IPR section. Didn't we have large issues just saying that there was another draft with the creative commons copyright?
I don't object to the publication of this document. But I found it interesting that Section 18. (Notice on Intellectual Properties) is even there -- I don't think it is needed.
= Section 1 = I agree with Terry that the introduction would benefit from an edit pass. = Section 2.3 = "The server MAY have thrown out the corresponding session from the session table." This seems like an inappropriate use of normative MAY, as it is describing behavior in the past. Either "MAY throw out" or "may have thrown out" would be appropriate. "Under the appropriate settings and implementations, most of the requests to resources are expected to meet both criteria, and thus only one round-trip of request/response will be required." This statement seems to presume much wider deployment than I would anticipate for this experiment. If I understand correctly, you would need mutual auth implemented by a sufficient proportion of servers to justify providing a knob in a browser that allows the user to indicate that he wants to send a key exchange in the first request to sites that have required mutual auth in the past. Is that what is meant by "settings"? If so, I think this either requires more explanation about the circumstances under which "most" requests can be reduced to 1 RT, or this statement needs to be qualified at a level below "most." = Section 4.1 = "user-unknown: this is a special case of auth- failed, suggesting that the provided user name is invalid. The use of this parameter is NOT RECOMMENDED due to security implications, except for special-purpose applications where it makes sense." The exception case here seems underspecified. It's not clear what kind of "special-purpose" application would warrant this in light of the information it potentially leaks and the fact that such applications, if they do not have scripting capabilities, do not require transport security when using this protocol according to Section 7. I have the same question about invalid-credential.
draft-ietf-httpauth-mutual-algo
In relation to Alvaro's comment on draft-ietf-httpauth-mutual, the first part of the Intellectual Properties Notice does not seem to apply here and the note is probably not needed at all.
I agree with Mirja that the IPR section in this draft seems misplaced, and applies more to the mutual-auth mechanism draft. If it needs to stay in this draft, please see my comment about the similar section in the mutual-auth draft.
Some editorial comments from our OPS-DIR reviewer, Qin Wu. This document defines four HTTP Mutual authentication algorithms which use with Mutual authentication protocol for HTTP, two for Discrete Logarithm settings, two for elliptic curve settings. In addition, the security of this algorithm is well analyzed. There is no major issue. I believe this document is ready for publication. Here are a few editorial comments I like to ask authors to consider: Minor issues: 1. Section 1.1 said: “ When a natural number output is required, the notation INT(H(s)) is used. ” I will see INT(H(s)) as a formula to convert H(s) into natural number 2. Section 2, 1st paragraph: What is DL-based notations? Can you expand DL? Is it Description Logic or something else? You can consider to add acronym and abbreviation section. 3.Section 2, 2nd paragraph and the figure that describe protocol exchange for four value Where you define the first two messages in this draft? Are you referred to the first messages that contain ID, K_c1 and K_s1 respectively in the figure? I don’t see you specify message format or give a message name? I don’t see you related text with the message shown in the figure? In addition, where the last two message defined in [I-D.ietf-httpauth-mutual]? Can you provide section number? By reading [[I-D.ietf-httpauth-mutual], I see K_c1, K_s1, VK_c,VK_s has already been defined in [[I-D.ietf-httpauth-mutual], I feel confused and am wondering if this draft really defines the first two messages? Or four message shown in the figure are all defined in the [[I-D.ietf-httpauth-mutual]. 4.Section 3.1, 3rd paragraph said: “ The functions named octet(), OCTETS(), and INT() are those defined in the core specification [I-D.ietf-httpauth-mutual]. “ Is the core specification [I-D.ietf-httpauth-mutual]the core document mentioned in section 3? If yes, please make them consistent. 5.Section 3.3, symbol “G” g: for "the generator" associated with the group. How the symobol “G” is different from symbol “g”in the section 3.2? Does G stand for the generator associated with the defined group? What do you mean “the defined point”? Would be great to clarify the difference between G and g. 6.Section 5.2 said: “ In the EC setting, r has to be prime. Defining a variation of this algorithm using a different domain parameter SHOULD be attentive to these conditions. “ What is EC setting? Please expand EC? Elliptic Curve? Please make this clear or add this abbreviation into abbreviation section. Nites: 1.Section 1,1st paragraph s/ use withMutual authentication protocol/ use with Mutual authentication protocol 2.Section 5.2 s/ mixing values from from two/ mixing values from two -Qin
draft-harkins-salted-eap-pwd
Maybe put the folling warning also more clearly at the beginning of the doc or even in the abstract: "Plain salting techniques are included for support of existing databases. scrypt and PBKDF2 techniques are RECOMMENDED for new password database deployments."
The abbreviated title on the top of pages after the first is "Abbreviated Title " :-)
Thanks for the secdir discussion - it was thorough and lead to good changes being made. (It took me longer to read that thread than the document:-) I do think that some of the text doesn't flow as well as a result of all those edits though, maybe a pass to improve that would be good. (Though it is clear enough now for implementers I think.) Figure 1 means that implementing this requires changes to the innards of your EAP-PWD implementation. It might be nice to a random implementer (if there are some) to provide that hint by saying this updates 7664. I like Mirja's suggestion - that RECOMMENDED is a bit buried right now. (Even if the main concern here is not new DB records.) I'd also note that it's possible to switch to a new alg on a per-record and not per-DB basis, if one's implementation allows, so you could also encourage that. (Well, unless EAP-PWD prevents it somehow but I'd be surprised if it did.)
conflict-review-sarikaya-6man-sadr-overview
It is also related to the ongoing discussion in rtgwg about src-dest routing.