RE: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08
Paul Hoffman wrote: - One of the changes is listed in Section 1.7 twice. I'd suggest combining In section 1.3.2, changed The KEi payload SHOULD be included to be The KEi payload MUST be included. This also led to changes in section 2.18. and Section 2.18 requires doing a Diffie-Hellman exchange when rekeying the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- Hellman exchange was optional, but this was not useful (or appropriate) when rekeying the IKE_SA. as follows: This document requires doing a Diffie-Hellman exchange when rekeying the IKE_SA (and thus requires including the KEi/KEr payloads). In theory, RFC 4306 allowed a policy where the Diffie-Hellman exchange was optional (and KEi/KEr payloads could be omitted), this was not useful (or appropriate) when rekeying the IKE_SA. Disagree. Where possible, I tried to list the actual sections where changes were made, and your proposed rewording loses the two places. The current text is more explicit than the proposed change. Well, this depends on whether you think Section 1.7 should list textual changes in the document, or clarification/changes to the protocol. IMHO, it should be the latter, but I see that currently it's really listing the textual changes (even when they clearly don't have any impact on the protocol); so perhaps listing these separately is consistent with that... Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETFLC comments for draft-ietf-ipsecme-ikev2bis-08
I've gone through changes from 06 to 07/08, and my earlier comments, and found one minor bug and couple of small editorial suggestions/nits. The bug first: - Section 3.3.6 says If one of the proposals offered is for the Diffie-Hellman group of NONE, the responder MUST ignore the initiator's KE payload and omit the KE payload from the response. This seems wrong: it seems to say that if the initiator proposes DH group NONE, the responder must select it. However, negotiation of DH groups and KE payload is already well described in Sections 1.2 and 1.3 (paragraphs mentioning INVALID_KE_PAYLOAD), and it seems the last paragraph of 3.3.6 is completely redundant. Thus, I'd propose just deleting the whole paragraph. Editorial suggestions/nits: - Section 2.7, last paragraph, is in wrong place; rest of 2.7 has nothing to do with this topic, which is in 2.6. Suggested place: 2.6, end of paragraph starting with In the first message. Also, the responder's SPI will be zero should be the responder's SPI will be zero also in the response message (since the responder's SPI is always zero in the IKE_SA_INIT request, but that's not what this paragraph is about). - One of the changes is listed in Section 1.7 twice. I'd suggest combining In section 1.3.2, changed The KEi payload SHOULD be included to be The KEi payload MUST be included. This also led to changes in section 2.18. and Section 2.18 requires doing a Diffie-Hellman exchange when rekeying the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- Hellman exchange was optional, but this was not useful (or appropriate) when rekeying the IKE_SA. as follows: This document requires doing a Diffie-Hellman exchange when rekeying the IKE_SA (and thus requires including the KEi/KEr payloads). In theory, RFC 4306 allowed a policy where the Diffie-Hellman exchange was optional (and KEi/KEr payloads could be omitted), this was not useful (or appropriate) when rekeying the IKE_SA. - Section 2.8.2, last paragraph: it's not quite obvious why this should be negotiated (the reason is that this notification was not included in RFC 4306, but this section never says that). Suggested rephrasing The TEMPORARY_FAILURE notification was not included in RFC 4306, and support of the TEMPORARY_FAILURE notification is not negotiated. Thus, older peers (implementing RFC 4306) may receive [... rest of the paragraph unchanged...] - Section 2.23, paragraph starting: An initiator can use IKEv2 packets are always over UDP, so IMHO the text would benefit from some more precision when talking about UDP encapsulation. Suggested edits: OLD: An initiator can use port 4500 for both IKE and ESP, regardless of whether or not there is a NAT, even at the beginning of IKE. When either side is using port 4500, sending with UDP encapsulation is not required, but understanding received IKE and ESP packets with UDP encapsulation is required. UDP encapsulation MUST NOT be done on port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. Either side can decide whether or not to use UDP encapsulation irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST send UDP encapsulated packets. NEW: An initiator can use port 4500 for both IKE and ESP, regardless of whether or not there is a NAT, even at the beginning of IKE. When either side is using port 4500, sending ESP with UDP encapsulation is not required, but understanding received UDP encapsulated ESP packets is required. If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated ESP and non-UDP encapsulated ESP packets at any time. Either side can decide whether or not to use UDP encapsulation for ESP irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST use UDP encapsulation for ESP. - Section 3.5: ID_IPV6_ADDR instead of ID_IPV6_ADDR should be ...instead of ID_IPV4_ADDR? - Reference [PKIX] should be updated from RFC 3280 to 5280. - Section 2.23.1, hve - have Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-tcpm-tcp-ao-crypto ...
a...@tr-sys.de wrote: Hello, draft-ietf-tcpm-tcp-ao-crypto-02 intends to make mandatory-to-implement for TCP-AO two MAC algorithms, HMAC-SHA-1-96 and AES-128-CMAC-96, as well as two related KDFs. IIRC, other WG(s) have been advised last year by important stakeholders (in particular NIST) to not standardize new use cases (e.g. in IPsec) of the CMAC / CCM Modes of Operation for a block cipher primitive, in favor of the GMAC / GCM Modes of Operation, because of the significant performance benefits of the latter modes. Could you provide some pointers to this advise? As the responsible Area Director for IPSECME WG (and a contributor to several IPsec documents), I do not recall seeing any advice that would match your description. (But it wouldn't be unheard of that I've missed some emails..) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
Hi Jari, You're right that implementing a weak shared secret EAP method (both the EAP peer and EAP server roles) on both IPsec nodes, combined with the EAP mutual authentication work item (also in the new charter) could be used in this situation, and would result in roughly the same functionality (perhaps with slightly more roundtrips/other overhead -- but that's probably not a critical factor here). The WG discussed this at length (both in Hiroshima and on the list afterwards), and the general feeling was that having a simple IKEv2-only solution would still be desirable, and could be more likely to get implemented/deployed in situations that currently don't use EAP. Perhaps the currently proposed text is slightly misleading about this; it could be read to say that EAP would not work. As we discussed on the IESG telechat earlier today, that paragraph would benefit from slightly more clearer explanation, e.g: OLD: However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. These features make using EAP (with its strict client-server separation) undesirable. NEW: However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. While it would be possible to use EAP in such situations (by having both peers implement both the EAP peer and the EAP server roles of an EAP method intended for weak shared secrets) with the mutual EAP-based authentication work item (above), a simpler solution may be desirable in many situations. Comments? Best regards, Pasi -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Jari Arkko Sent: 16 February, 2010 14:08 To: IETF Discussion Subject: Re: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme) This new charter looks great otherwise, but I did have a reaction on this: - IKEv2 supports mutual authentication with a shared secret, but this mechanism is intended for strong shared secrets. User-chosen passwords are typically of low entropy and subject to off-line dictionary attacks when used with this mechanism. Thus, RFC 4306 recommends using EAP with public-key based authentication of the responder instead. This approach would be typically used in enterprise remote access VPN scenarios where the VPN gateway does not usually even have the actual passwords for all users, but instead typically communicates with a back-end RADIUS server. However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. These features make using EAP (with its strict client-server separation) undesirable. The WG will develop a standards-track extension to IKEv2 to allow mutual authentication based on weak (low-entropy) shared secrets. The goal is to avoid off-line dictionary attacks without requiring the use of certificates or EAP. There are many already-developed algorithms that can be used, and the WG would need to pick one that both is believed to be secure and is believed to have acceptable intellectual property features. The WG would also need to develop the protocol to use the chosen algorithm in IKEv2 in a secure fashion. It is noted up front that this work item poses a higher chance of failing to be completed than other WG work items; this is balanced by the very high expected value of the extension if it is standardized and deployed. Frankly, I'm not too convinced about the arguments above. First of all, EAP does not require separate back-end servers. And with IKEv2 itself already having to decide which side initiates, I do not see a problem running a password-based EAP method in the same direction. Also, it is true that a new native scheme is slightly easier to implement on top of IKEv2 than EAP + an EAP method. However, if you look at the issue from a system level, does that mean that you are forced to implement this new scheme *and* EAP, because you already need EAP for many other situations? For someone working with a full-blown, all features supported implementation of IKEv2 this means *more* code, not less. Perhaps there are some better arguments why you must choose a non-EAP solution. Or maybe the charter should require specific functionality to
RE: Metadiscussion on changes in draft-ietf-tls-renegotiation
Martin Rex wrote: I have never seen an IETF AD fight so passionately for the addition of rfc-2119-violating and unreasonable imperatives into a document such as Pasi is doing it now. Now? Addition? I would like to remind you that version -01 of the document also very clearly prohibited sending the SCSV in secure renegotiation ClientHello, and also used upper-case RFC 2119 keywords in that text. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Confirming consensus about one draft-ietf-tls-renegotiation detail
Concerns have been raised that the IESG may have judged community consensus about one specific detail of draft-ietf-tls-renegotiation prematurely. In particular, the discussion that happened just after the IETF Last Call ended might have caused some people to change their opinion, and also the holiday season may have delayed replies. To eliminate doubt about the situation, and allow the RFC to come out as soon as possible, we have decided to confirm the community consensus about this detail. The detail in question is whether the Signalling Cipher Suite Value (SCSV) can be included when performing secure renegotiation (in addition to the renegotiation_info extension). Currently, the SCSV is not included. In the version that went to IETF Last Call (version -01), the relevant text was: This cipher suite has exactly the same semantics as an empty renegotiation_info extension. [..] Because this cipher suite is equivalent to an empty renegotiation_info extension, only renegotiation_info may be used rehandshakes. (in Section 4) Version -03 (the latest version) has rephrased the text as follows: The SCSV MUST NOT be included. (in Section 3.5, Client Behavior: Secure Renegotiation) When ClientHello is received, the server MUST verify that it does not contain the TLS_RENEGO_PROTECTION_REQUEST SCSV. If the SCSV is present, the server MUST abort the handshake. (in Section 3.7, Server Behavior: Secure Renegotiation) It has been suggested that recent discussions may have changed the consensus, and some people have proposed changing this so that including the SCSV in secure renegotiation ClientHellos is allowed (but not required), and rephrasing the text that says SCSV, when received, is treated the same as an empty renegotiation_info extension (which means not renegotiation). Note that this text applies to secure renegotiation ClientHellos. Other possible changes to the details concerning the SCSV (such as requiring it in all ClientHellos) were suggested during the IETF Last Call, but are explicitly outside the scope of this email. According to our notes, at least the following individuals seem to have expressed support for publishing version 01/02/03 (without making further changes to the details concerning the SCSV): Adrian Farrel Alexey Melnikov Ben Laurie Bodo Moeller Chris Newman Cullen Jennings Dan Romascanu David P. Kemp Eric Rescorla Geoffrey Keating Glen Zorn Jari Arkko Lars Eggert Lisa Dusseault Magnus Westerlund Nicolas Williams Pasi Eronen Peter Robinson Ralph Droms Rob P. Williams Robert Relya Robert Sparks Ron Bonica Stephen Farrell Steve Checkoaway Steve Dispensa Tim Polk Uri Blumenthal The following individuals seems to have expressed a preference for *not* publishing this document until the details concerning the SCSV are changed as described above: Marsh Ray Martin Rex Michael D'Errico Nasko Oskov Robert Dugal Stephen Henson Yoav Nir A number of other people also sent comments during the IETF Last Call (possibly proposing other changes to the details concerning the SCSV), but did not clearly fall into either list above. If the recent discussions have caused you to change your mind (or we have interpreted your preference incorrectly, or you were not on either list), please send an email to the TLS WG mailing list by Tuesday February 2nd. In your reply, please include one of the following: (1) I prefer publishing the specification as-is. (2) I prefer *NOT* publishing the specification as-is, and instead prefer changing the text so that including the SCSV in secure renegotiation ClientHellos is allowed (but not required). Unless a significant amount of additional people believe that making this change if preferable over publishing the spec now, the IESG expects to have the RFC out soon after February 2nd. So we hope this consensus confirmation does not delay the RFC, or deployment of its implementations. Note that this is not a general call to revisit other details of draft-ietf-tls-renegotiation, or propose additional changes. If you absolutely wish to have other discussions related to the draft, we respectfully ask you to change the subject line. Best regards, Pasi IETF Security Area Director ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-ietf-tls-renegotation: next steps
(wearing IETF Security Area Director hat) First of all, I want to say that it's clear that this was an unusual IETF Last Call -- and this was expected, too. Usually a WG document does not go to IETF Last Call until everyone in the WG is happy with it, so most of the time, very little happens during the last call. However, this document addresses an urgent security vulnerability, so as discussed in the Hiroshima TLS WG meeting, it was decided to solicit comments from the TLS WG members and the wider community partly overlapping. This means we've gotten quite a few emails. However, although the volume of emails was large, I was a positively surprised how little disagreement there was. There was basically no disagreement about the functionality (what the spec should do); only about how exactly the functionality should be implemented. And even there, most people agreed on most of the big issues, and the disagreement was mostly about details that, frankly speaking, are not all that important (especially to the users of TLS). Some have even dismissed many of the comments as aesthetic. I disagree with that -- the discussions were not that different from ordinary discussions in any IETF WG. However, I think it's fair to say that most comments were more about it could/should be better than it won't work. Also, despite the occasionally heated email exchanges, I believe most people agree that getting this security vulnerability fixed quickly is more important than the specific details (as long as the details are not totally unreasonable). Summarizing some open issues: - We seem to have rough consensus that both clients and servers need to be able, if they choose to do so, fully operate with legacy (unpatched) systems, at least for a limited period of time (despite the security implications). This implies the need for some form of signaling in both directions, where a patched system can determine if the other end supports the fixed renegotiation or not. (The current draft supports this.) - We seem to have rough consensus that the specification should include some form of C-S signaling that can be used with extension-intolerant servers and/or SSLv2 compatible client hellos. (The current draft has the magic cipher suite value for this purpose.) - For S-C signaling, we seem to have rough consensus for a TLS extension in ServerHello. - Whether verify_data should be sent over-the-wire or not: current text (send it over-the-wire) seems to have more support (at least 2/3 vs. 1/3). While the rough consensus is perhaps a bit rougher than we'd normally hope to see, I believe most participants (of either opinion) would prefer making a decision over continuing the discussion until some indeterminate time. So we pick the one with more support. - Whether to prohibit sending the extension (in initial ClientHello), or require the magic cipher suite even if the extension is sent (in initial ClientHello): The consensus is again a bit rougher than we'd normally hope to see, but the current text (either is allowed) has more support (about 2/3 vs. 1/3), so we keep it. And again, I believe most participants prefer make some decision over continuing the discussion. - There was some discussion on whether to add the magic cipher suite to patched renegotiation ClientHellos (in addition to the extension), too. I believe rough consensus is not to do this. - The current draft doesn't clearly say what should be included in legacy (insecure) renegotiation ClientHellos. I am not sure if we have enough clear opinions to call consensus, but keeping it aligned with the initial ClientHello (either MSCV or extension) seems to be one simple approach (but I hope to see the actual text). - Yngve Pettersen proposed explicitly saying that servers that implement this draft must be extension-tolerant (not break if the client sends extensions) and version-tolerant (not break if the client proposes a higher version number than the server supports). It seems these are not new requirements, so this would be an editorial clarification (but being very clear doesn't hurt). - Yngve also proposed adding requirements/recommendations about fall-back/reconnection procedures (to extension-less handshake, or earlier versions). I think the rough consensus is that the document should not mandate or even recommend anything about such fall-back/reconnection procedures (which are mostly not related to renegotiation anyway). - There was discussion about adding another C-S signaling method using the proposed version: if proposed version = 1.3, and the negotiated version is = 1.2, it means the client supports this draft (what happens if negotiated version is = 1.3 would be specified in the TLS 1.3 spec). This would allow TLS =1.3 clients to remove other signaling (magic cipher suite/extension) from initial ClientHellos (but requires extra code in the server). As Tom Petch (and others) noted, if we want to do this, it has to be done now (and can't be done when
RE: request for feedback: change to the ID boilerplate
Lars Eggert wrote: We could link to the list (http://datatracker.ietf.org/drafts/all/) but the page takes a long time to load... http://datatracker.ietf.org/drafts/current/ is both more correct (it is a list of current drafts) and loads faster. Made the change in my local copy. I would actually prefer Eric Gray's suggestion is available via http://datatracker.ietf.org/drafts/;. That part of IETF datatracker is undergoing a rewrite, and while there will be redirects from old URLs, the overall organization will change. And IMHO the search page (with a link to the full list) is probably more useful to most users than the list (especially since that list doesn't contain even the document titles, so it's quite cryptic). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: request for feedback: change to the ID boilerplate
Looks good to me! Best regards, Pasi -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eggert Lars (Nokia-NRC/Espoo) Sent: 27 October, 2009 11:29 To: IETF discussion list Subject: request for feedback: change to the ID boilerplate Hi, I'm proposing a change to the ID boilerplate in order to save some lines on the first page. The current text says: Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on date. The first URL was broken since the IETF web site redesign, but nobody has noticed. That - to me - is a pretty strong indication that nobody has been using it. (It is now fixed.) The second URL points to a list of FTP mirrors, fully half of which are defunct in some way (don't respond, DNS name doesn't resolve, contains stale content, etc.) Again, nobody has been noticing this. Consequently, the proposal is to shorten the boilerplate text above to the following, saving five lines: Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. This Internet-Draft will expire on date. Thoughts? Thanks, Lars ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard
Simon Josefsson wrote: I am aware that the IETF-wide last call has ended, but Daniel Black provided a suggestion (posted on the gnutls-devel list) for the Security Considerations that I agree with and believe can be important. Quoting him, slightly reworded: also maybe 11.1. could say, in response to the last paragraph of section 3, + Server applications SHOULD validate server_name against any application layer equivalent field. The last paragraph of section 3 reads: If an application negotiates a server name using an application protocol and then upgrades to TLS, and if a server_name extension is sent, then the extension SHOULD contain the same name that was negotiated in the application protocol. If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer. It appears security relevant for the server to actual verify that the client do not use another server name at the application layer to circumvent authorization decisions. I cannot find any MUST/SHOULD requirement in the document for servers to test this right now. One attack could works like this: 1) Client establish an client-authenticated HTTPS session with a TLS SNI for blog.example.org and sends a HTTP GET with a Host: header for internal-website.example.org. The specification is agnostic about the upper layer protocol, so it doesn't have any HTTPS-specific details. So strictly speaking, something like this is allowed by the spec, and could even make sense with some upper layer protocols (although perhaps not HTTPS). 2) The server TLS code authenticate and authorize the client (using the certificate) for use with the blog.example.org domain. The server HTTP code serves the internal-website.example.org web page to the client. This system would be insecure but still compliant with RFC 4366bis as far as I can tell, which seems suboptimal. Adding a requirement for servers to check for this attack would solve the problem. This assumes that all TLS connections are forwarded to the same server instance regardless of the SNI value. But it's also possible that blog.example.org and internal-website.example.org would be, e.g., two server processes totally unaware of each other. And they could even be using different upper-layer protocols (e.g. XMPP and HTTP). But I agree that this is a detail that an implementor could conceivably get wrong, and perhaps the spec should warn about it (although MUST would probably be too strong -- it really depends on the upper layer protocol). Can you propose some text? Best regards, Pasi (not wearing any hats) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-sasl-scram
John C Klensin wrote: Looking http://en.wikipedia.org/wiki/Keyboard_layout, it seems the Finnish/Swedish layout is not special in any way, and many other European keyboards would also have some small number of characters where NFC!=NFKC. That is important data. It seems to me that it implies: * if entropy in passwords and/or properly reflecting keyboards is more important than password interoperability (whatever that means), then we should be moving away from NFKC and, hence, from the current version of SASLprep. I don't know about the East Asian width variants, but for the ones in the Finnish/Swedish layout, there is basically no entropy loss. For some of the characters, there's only one way to enter the NFKC form (so no entropy is lost); and the number of characters affected is small, and they're rarely used anyway (so the effect on entropy is extremely small). So IMHO entropy is not a good reason to move away from NFKC. There might be other reasons, but the complaint about SASLprep I've heard most often (implementation complexity -- unless the platform already has a normalize() call always available, many programmers will just use UTF-8) applies equally to NFC, too. So I'm not sure if moving to NFC would really solve anything here... But just use UTF-8 probably won't lead to good interoperability when the passwords are hashed (as opposed to sent and compared, like usernames). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-sasl-scram
Simon Josefsson wrote: I'd be happy to help work on a document that analyzed the consequences of replacing SASLprep with just-use-RFC5198 in SASL. But I don't think SCRAM should wait for something like it to materialize. I agree that such work would take time, and we don't want to delay SCRAM. But as the discussion so far has shown, normalization is a very tricky topic, and we can't really expect implementors to understand why just use UTF-8 is problematic. Perhaps we should add a note to the SCRAM draft; something like Informative Note: Implementors are encouraged to create test cases that use both username passwords with non-ASCII characters. In particular, it's useful to test characters whose normalization form C and normalization form KC are different. Some examples of such characters include Vulgar Fraction One Half (U+00BD) and Acute Accent (U+00B4). Do you think this would increase the likelihood of interoperability with non-ASCII passwords? Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-sasl-scram
Simon Josefsson wrote: Informative Note: Implementors are encouraged to create test cases that use both username passwords with non-ASCII characters. In particular, it's useful to test characters whose normalization form C and normalization form KC are different. Some examples of such characters include Vulgar Fraction One Half (U+00BD) and Acute Accent (U+00B4). +1. Do you think this would increase the likelihood of interoperability with non-ASCII passwords? For implementers that decides to use SASLprep but just happens to get things wrong, yes. For those, I think test vectors would be even more useful. I was also hoping the tests would convince implementors to actually do SASLprep :-) Otherwise, they might test their implementation with a couple of non-ASCII passwords, and conclude that just use UTF-8 interoperates just fine (with someone else's code). (If you just pick some non-ASCII password for your test case, it's quite likely that its NFC and NFKC are equivalent, and the input to your code is already NFC...) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [rohc] Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec
Emre Ertekin wrote: Well, the current drafts don't specify any such behavior, so the feature as it's currently written does not work. (Also, using the ESP/AH sequence number this way would be very unusual -- there might be some complications...) If we include text that states this behavior, does this address your concern? Depends on the text (certainly more than 1-2 sentences are needed here)... but it's possible it could address my concern. FWIW, I could also think of deployment scenarios where packet reordering is minimal (e.g., ROHCOIPsec is instantiated over a single [bandwidth constrained] link). Such scenarios may not even require the use of the ESP/AH sequence number to reconstruct ROHC segments. Perhaps; but in general, IPsec runs over IP, and doesn't know about the properties of the underlying links (even if it's only one hop, not all links preserve order always). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-sasl-scram
John C Klensin wrote: The difference between (1) and (2) is less significant in practice because, while there are many important exceptions (with those East Asian width variants probably heading the list), the vast majority of compatibility characters are very hard to type in most environments. And that was really the point I was trying to make. Adding one data point here: While I have no idea how to type East Asian width variants on my keyboard (normal Finnish/Swedish layout), my keyboard does have three characters where NFC!=NFKC (so using any of them in my password would be impossible if some SCRAM implementations use NFKC and some NFC): Vulgar Fraction One Half (U+00BD) Acute Accent (U+00B4) Diaeresis (U+00A8) Looking http://en.wikipedia.org/wiki/Keyboard_layout, it seems the Finnish/Swedish layout is not special in any way, and many other European keyboards would also have some small number of characters where NFC!=NFKC. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec
Emre Ertekin wrote:[mailto:emreertekin.i...@gmail.com] 1) None of the drafts really describe the reason why the ROHC ICV is included. It was not present in the early drafts, and was added after long and complex discussions. I would strongly encourage summarizing those discussions in one of the drafts -- otherwise, the reader cannot really figure out why the ROHC ICV is included (since the packets are already protected by the AH/ESP ICV), and what risks omitting the ROHC ICV might have. Sure, we can add some description on this. How much detail are you looking for? Perhaps we can add the following text in a separate section under Section 6.1 of the framework draft, entitled Motivation for the ROHC ICV: Although ROHC was designed to tolerate packet loss and reordering, the algorithm does not guarantee that packets reconstructed at the decompressor are identical to those constructed at the compressor. As stated in Section 5.2 of [RFC 4224], the consequences of packet reordering between ROHC peers may include undetected decompression failures, where erroneous packets are constructed and forwarded to upper layers. When using IPsec integrity protection, a packet received at the egress of an IPsec tunnel is identical to the packet that was processed at the ingress (given that the key is not compromised, etc.). When ROHC is integrated into the IPsec processing framework, the ROHC processed packet is protected by the AH/ESP ICV. However, bits in the original IP header are not protected by this ICV. Therefore, under certain circumstances, erroneous packets may be constructed and forwarded into the protected domain. To ensure the integrity of the original IP header within the ROHCoIPsec-processing model, an additional integrity check may be applied before the packet is compressed. This integrity check will ensure that erroneous packets are not forwarded into the protected domain. The specifics of this integrity check are documented in Section 3.2 of [IPSEC-ROHC]. Looks very good! 2) ipsec-extensions, Section 3.3, doesn't really correctly describe the MTU-related processing in RFC 4301. The three cases refer to IPsec implementations that both process unprotected ICMP messages and actually receive them (they're often filtered in the network), and thus have a Path MTU estimate value. But an IPsec implementation that doesn't process (or receive) unprotected ICMP messages does not even have a Path MTU estimate value... This is a good point. I would assume that if the IPsec implementation does not have a Path MTU estimate value, then it SHOULD NOT attempt to segment packet headers, as it does not have full insight into the MTU in the unprotected domain. Is this in line with your thoughts? Yes. 3) According to RFC 4224, ROHC segmentation does not work over reordering channels. Thus, it seems suggesting that ROHC segmentation could be used instead of pre-encryption fragmentation (e.g. ipsec-extensions, Section 3.3) -- and in general, allowing segmentation at all -- seems misguided (it's unnecessary complexity that would be IMHO best left out). Although I agree that ROHC segmentation is not a good idea, it is an optional functionality in the spec. The implementer can decide whether or not they want to code it. If a vendor chooses not to implement the functionality, they can hardwire the MRRU channel parameter to zero. OK, let me phrase my question in another way: why does the spec contain a feature that does not really work? (Even as optional feature?) 4) None of the drafts have any RFC 2119 keywords (MUST/SHOULD/etc). They SHOULD use those to make it less ambiguous what is the required behavior (and what is optional) to claim compliance with these drafts. OK, we will take a run through the IKEv2 and IPsec extensions drafts to account for these keywords. Not the framework draft though, since the draft is intended to be informational. Being Informational (vs. Proposed Standard) RFC has nothing to do with the question -- many Informational RFCs do use RFC 2119 keywords, and there's nothing special about that. To me, it looks like the framework draft has normative statements (things implementations are required or recommended to do in order to get interoperability), too, so 2119 keywords would be appropriate (and actually, it could be Standards Track, too). 5) In ikev2-extensions, Section 2.1.2 it is not very clear which of the attributes are just one-way notifications (the sender of the attribute tells the other end what it can handle), and which are negotiated (the initiator tells the other end what it supports; the responder then selects one, and tells what it selected). I would suggest adding text like Note that different
RE: Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec
Carsten Bormann wrote: OK, let me phrase my question in another way: why does the spec contain a feature that does not really work? (Even as optional feature?) Well, it actually does work. RFC 4224, section 5.2.1 tells us that when a channel is reordering and you don't notice, packets will be lost. Now IPsec is a strange animal: It is reordering, but the order can be reconstructed from the sequence number. So a reassembler could (here really: SHOULD) use that to avoid stitching together packets in the wrong order and then discarding them. Well, the current drafts don't specify any such behavior, so the feature as it's currently written does not work. (Also, using the ESP/AH sequence number this way would be very unusual -- there might be some complications...) Is ROHC segmentation better than IP fragmentation? It certainly has fewer of the problems of IP fragmentation. It does require throwing some CPU at the data (it uses a CRC). Because header compression creates a variable-MTU channel, being able to segment in a pinch is a boon. Since the ROHC framework has the functionality, and it is not hard to make it work on IPsec, I would favor retaining it. Making it work for IPsec might not be impossible, but it does require additional work beyond what's in the current drafts. Best regards, Psai ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec
I've reviewed the ROHCoIPsec draft set (not wearing any hats), and have couple of comments. Most important first: 1) None of the drafts really describe the reason why the ROHC ICV is included. It was not present in the early drafts, and was added after long and complex discussions. I would strongly encourage summarizing those discussions in one of the drafts -- otherwise, the reader cannot really figure out why the ROHC ICV is included (since the packets are already protected by the AH/ESP ICV), and what risks omitting the ROHC ICV might have. 2) ipsec-extensions, Section 3.3, doesn't really correctly describe the MTU-related processing in RFC 4301. The three cases refer to IPsec implementations that both process unprotected ICMP messages and actually receive them (they're often filtered in the network), and thus have a Path MTU estimate value. But an IPsec implementation that doesn't process (or receive) unprotected ICMP messages does not even have a Path MTU estimate value... 3) According to RFC 4224, ROHC segmentation does not work over reordering channels. Thus, it seems suggesting that ROHC segmentation could be used instead of pre-encryption fragmentation (e.g. ipsec-extensions, Section 3.3) -- and in general, allowing segmentation at all -- seems misguided (it's unnecessary complexity that would be IMHO best left out). 4) None of the drafts have any RFC 2119 keywords (MUST/SHOULD/etc). They SHOULD use those to make it less ambiguous what is the required behavior (and what is optional) to claim compliance with these drafts. 5) In ikev2-extensions, Section 2.1.2 it is not very clear which of the attributes are just one-way notifications (the sender of the attribute tells the other end what it can handle), and which are negotiated (the initiator tells the other end what it supports; the responder then selects one, and tells what it selected). I would suggest adding text like Note that different ATTRIBUTE_NAME value can be used in each direction for those attributes that are just one-way (I think at least MAX_CID, ROHC_PROFILE -- for MRRU and ROHC_ICV_LEN, I don't know which way they're supposed to work). 6) ikev2-extensions, Section 2.1.2, says The key for this Integrity Algorithm is computed using the same method as is used to compute IPsec's Integrity Algorithm key ([IKEV2], Section 2.17). I don't think this is sufficient to get interoperable implementations; more details are needed. In addition, there's couple of places that probably need some clarifications and/or minor fixes: 7) ikev2-extensions, Section 2.1.2, ROHC_ICV_LEN: The text talks about announcing their preference; how is the actual ICV length determined from these preferences? 8) ikev2-extensions, Section 2.1.2, ROHC_INTEG: Should also describe what happens if the responder doesn't accept any of the algorithms proposed by the initiator (not doing ROHC at all would be one obvious alternative; NO_PROPOSAL_CHOSEN another). 9) ikev2-extensions, Section 2.1.1, says The most significant bit in the field is the Attribute Format (AF) bit. No, according to Figure 2 AF is a separate field, not part of the ROHC Attribute Type field. 10) ipsec-extensions, Section 3.2, says The authentication data must not be included in the calculation of the ICV. This is very vague, considering that we have several different authentication data/ICVs here. Is the intent to say The ROHC ICV field is not included in the calculation of the ROHC ICV, or something else? 11) ikev2-extensions, Section 4: 6-65536 Unassigned should be 6-32767 Unassigned. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
John, Your suggestion would largely address my concerns related to the timely appeal path. Best regards, Pasi -Original Message- From: ext John C Klensin [mailto:john-i...@jck.com] Sent: 02 September, 2009 20:20 To: Eronen Pasi (Nokia-NRC/Helsinki); j...@joelhalpern.com; b...@estacado.net Cc: i...@ietf.org; ietf@ietf.org Subject: RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes --On Tuesday, September 01, 2009 09:55 +0200 pasi.ero...@nokia.com wrote: Joel M. Halpern wrote: If the ISE / RSE is unreasonable, the IAB will slap the editor and say stop doing that. There is no equivalent process if we reverse the structure. Yes, there is. If the IESG would request/recommend a particularly bad IESG note, this decision can be appealed just like any other IESG decision. The IAB would then determine if the IESG acted appropriately or not. On the other hand, if the ISE/RSE decides to publish a document without an IESG note even if the IESG requested/recommended it, this decision cannot be effectively appealed (since the RFC already came out, and can't be really recalled). Although I'm not expecting this really to happen very often (if ever), from checks-and-balances viewpoint I would support (b) from Jari's email (in other words: RFC Editor cannot unilaterally ignore a note requested by IESG, but has to take it to the IAB via the usual appeal procedures). Pasi, A comment and then a suggested middle position. I've been watching what we now call the Independent Submission Process for far longer than there has been an IETF. I've seen it as an insider for a large fraction of two decades -- as an AD, an IAB member and then chair, as an editorial board member, and now as an IAB member again. During that period, I've never seen an RFC Editor abuse the process by ignoring legitimate input. Bob Braden may be able to provide an inside view --not in his present role of RFC Editor but as the very-long-time IAB Exec Director -- of what happened before 1992, but my educated guess is that instances of RFC Editor ignores input during that time were also about zero. During the same period, I'd seen behavior I consider abusive from ADs or the IESG many times -- attempting to prevent publication of documents with which they had personal/ emotional disagreements that they were unwilling or unable to explain in public, asking for publication holds on documents for multiples of years, insisting that the RFC Editor not move forward until the IESG responds in some way and then not responding for months and months, demanding changes that would significantly weaken the document or change its meaning, and so on. Many of those problems have been resolved by negotiation, but some have not. RFC 3932, and its limitation on technical review, was a huge improvement over its predecessors in that regard, but we've heard multiple ADs over the years claim that they can redefine any disagreement about a document into either a technical issue or a technical one (whichever is needed) if they care enough and especially if they can define the boundary (which they also have insisted that the IESG has the unilateral right to do). In principle, the IAB could appoint a new ISE to take over in January who would adopt a policy of abusiveness. But I think I can speak for the ACEF membership and the IAB if I say that we don't intend to do that... and that the IAB would expect the RSE to move fairly quickly, with the IAB's backing, to correct the attitudes involved if it occurred anyway. So trying to make IESG notes mandatory on documents originating in another stream for the reasons you cite above is solving a problem we've never had at the risk of making a problem worse that we've had several times. That strikes me as bad engineering at best. And insisting that the RFC Editor invoke a formal appeals procedure in case of disagreement with the IESG about an Independent Submission would, as Olaf points out, largely undo the efforts of the last few years to clearly separate the different streams. It would be as sensible to say that IESG notes should be sufficiently exceptional that the IESG would need to consult the IAB and get permission before sending any such note-request to the ISE. I suspect that such a provision would not make either the IESG or the IAB very happy. However, if your concern is really to make sure that there is a timely appeal path, I have a suggestion that might be acceptable to everyone without causing unfortunate side-effects. We simply require that, if the ISE receives input from the IESG requesting specific changes to a document (specific changes including, but not limited to, so-called IESG Notes) and the ISE and authors decide to not incorporate those proposed changes, the ISE is required to explain to the IESG, in writing, why not and allow a
RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Joel M. Halpern wrote: If the ISE / RSE is unreasonable, the IAB will slap the editor and say stop doing that. There is no equivalent process if we reverse the structure. Yes, there is. If the IESG would request/recommend a particularly bad IESG note, this decision can be appealed just like any other IESG decision. The IAB would then determine if the IESG acted appropriately or not. On the other hand, if the ISE/RSE decides to publish a document without an IESG note even if the IESG requested/recommended it, this decision cannot be effectively appealed (since the RFC already came out, and can't be really recalled). Although I'm not expecting this really to happen very often (if ever), from checks-and-balances viewpoint I would support (b) from Jari's email (in other words: RFC Editor cannot unilaterally ignore a note requested by IESG, but has to take it to the IAB via the usual appeal procedures). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: meta-issues on charter discussions
The tools WG pages used to have diffs between charter versions (see e.g. http://tools.ietf.org/wg/tls/charters/ -- the delta symbol leads to side-by-side diff between the versions), but it looks like this broke when new www.ietf.org was deployed in July Best regards, Pasi -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Tony Hansen Sent: 21 August, 2009 17:57 To: tools-disc...@ietf.org Cc: ietf@ietf.org Subject: Re: meta-issues on charter discussions This was posted to the ietf list. While the charter history pages are nice, they can be made better using a format similar to how tools.ietf.org presents RFCs and I-Ds: a non-printing list of versions at the top with ways to show differences between versions. Sounds like a job for the tools team. :-) Tony Hansen t...@att.com Thomas Narten wrote: Re: old charters and such. While poking around earlier this week, I found: http://www.ietf.org/dyn/wg/charter/history/ (it is hanging of the WG pages, so not that hard to find.) It appears to be a snapshot of charters whenever they change. But, they change often due to events that are probably not the kind of changes we are thinking about, and there is no indication about what has changed, so there are a lot of copies and wading through them to find stuff appears pretty daunting. And the history only goes back 3 years or so... But they might be a basis for some tools to extract stuff. But, if tools are going to do this, it seems like an archival format other than HTML would be desirable. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP
I support changing these to must. We don't of course have any mechanisms to enforce this (especially discussions by other IETF community members on non-IETF mailing lists)... but currently, asking people to treat nominee lists *as if* they were confidential (even though they were not) has had the effect of preventing public discussions about the candidates (on e.g. ietf@ietf.org mailing list). I don't think such discussions would be helpful for the goals of the NomCom process (or the IETF in general), and I think the document should send a clear message that they're not acceptable in the future either (instead of leaving wiggle room that they might be OK in some circumstances). Best regards, Pasi -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Spencer Dawkins Sent: 09 June, 2009 23:33 To: ietf@ietf.org Cc: brian.e.carpen...@gmail.com Subject: Fw: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP Brian Carpenter had a Last Call comment that I needed to follow up on... Hi, (IETF list not copied as I'm on leave and minimising email, but there is nothing confidential about this comment.) Feedback on nominees should always be provided privately to NomCom. Nominees should not solicit support, and other IETF community members should not post statements of support/ non-support for nominees in any public forum. I believe these three occurrences of 'should' need to be 'must'. I don't think there should be any wiggle room on this point. Brian Russ thinks I should check on this with the rest of the community, so I'm asking for feedback now. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: designate an email address for testing at any provider
Fred Baker wrote: When you sent this note, I immediately sent an email to t...@example.com. It took a few days, as my mail handler queues things up and retries them for a while, but I eventually got a bounce. I suspect that any email address @example.com would have sufficed, as there is by definition no A record and no mail receiver for example.com. BTW, example.com does have an A record (and web server listening on port 80). But nothing listening on port 25, it seems. (And it doesn't support IPv6 either :-) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iana-rfc3330bis (Special Use IPv4 Addresses) to Informational RFC
I have one suggestion for draft-iana-rfc3330bis (not wearing any hats): I think it would be useful to have more addresses for use in documentation and examples, in addition to the current 192.0.2.0/24. Although it's naturally possible to split 192.0.2.0/24 to smaller pieces (e.g., two /25s or four /26s) when writing examples, those pieces look very much alike, and that hurts the readability and clarity of the examples. I've encountered this myself when e.g. writing the examples for RFC 4718, and I have seen the same situation in other documents, too. It would be nice if we had, say, two additional blocks that are easily visually distinguishable (that is, start with something else than 192). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: TLS WG Chair Comments on draft-ietf-tls-authz-07
Michael StJohns wrote: I went to review the bidding on the TLS mailing list covering this period and it appears the archives at http://www.ietf.org/mail-archive/web/tls/current/maillist.html only go back to the beginning of the year. Could you point me at a more complete archive covering the period and the discussions about TLS WG interest in this document please? I'm not sure if you already got an answer to this question (following the mailing list hasn't been easy :-), but... The archives at http://www.ietf.org/mail-archive/web/tls/current/maillist.html go back to September 2004 (just keep clicking the Next Page link -- and yes, I agree that the user interface could be better). That should cover this draft's life span (version -00 is from 2006). If you're interested in more ancient history, the following links may (or may not) be useful: http://www.ietf.org/mail-archive/text/tls/ http://lists.w3.org/Archives/Public/ietf-tls/ Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Including the GPL in GPL code (Re: IETF and open source license compatibility)
Simon Josefsson wrote: Generally, however, I think this question is very different from where this thread started. It started, as far as I consider, with Stephan suggesting that free software authors publish free (as in licensed under a free software license) standards in the IETF. That is not possible, and is unrelated to the question we discuss here. BTW, why cannot a free software author license some particular standards text under both RFC 5378 terms, and some other license (a free software license, or even GPL)? Presumably, he/she owns the copyright, and 5378 terms are non-exclusive. Obviously, for collaborative efforts this may require that all copyright holders agree, and that may make this unpractical. But I wonder if there was some other reason? Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard
Simon Josefsson wrote: My reading of RedPhone's IPR disclosure 1026 is that they claim to have a patent application about a larger system that includes tls-authz as one part, and uses it in particular way. If you want to build a system matching the numbered list 1..4 in the disclosure (RedPhone's description of what they claim is covered), then you would have to consider this IPR disclosure. A license is required for each of the cases 1, 2, 3, and 4 individually. Well -- if the patent is granted, a license may be required if you do any of the things listed in the granted patent's claims. The items 1..4 may or may not be an accurate summary of the claims in the application, and what's granted may be different from the application. As far as I read item 3, it seems to cover many kind of realistic use of this protocol. As soon as you have some authorization data, you would typically compare the sender of the authorization to some set of valid issuers. However, I think there are many more good uses for tls-authz that do *not* match items 1..4. That would change things. Can you describe a practical way to use tls-authz that wouldn't be covered by, for example, item 3? I tried to understand one unencumbered use-case of tls-authz earlier: http://thread.gmane.org/gmane.ietf.general/33561. To my reading, the example seems encumbered. If you can explain an unencumbered use-case that would help. I have not read the actual patent application (and I'm not planning to), and as I noted above, I do not know how accurate the four-item summary is. Without reading the application itself, saying here's a use case that is not covered by the claims would be rather unwise. However, draft-ietf-tls-attr-cert-01 (from 1998, predating this application by many years) describes a use case where the client presents an AC containing a role or security clearance to the server, and the server uses this to determine whether the client is allowed to access the requested resource. It's of course possible that the patent applications's claims cover this use case, too -- but personally, I would not be extremely worried about getting sued by RedPhone if this was the use case I'd be doing. (Note that draft-ietf-tls-attr-cert-01 also has lot of other stuff that is not in tls-authz; e.g. about acquiring/issuing ACs, and hints about what ACs the client should consider presenting. But there's some overlap as well.) Just because someone has filed a patent application on some rather obscure combination of B+C+D should not prevent others from using the protocol for things not covered by that application. Thus, I support publishing this as an RFC (either Informational or Standards Track). Obviously part of our disagreement seems to be what is obscure. Would you still support publication if the patent application covers broader ways to use the protocol? I agree that this is a relevant question; if the application would claim to cover most of the interesting use cases (and only some obscure cases would be unencumbered), that could change my opinion. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard
Simon Josefsson wrote: I disagree. The IETF policies around patents mention use as well as implementation. Thus, a license that permit implementation but not permitting use should generate similar scrutiny and discussion. It poses the same problem for actual users. I strongly disagree with a notion that just because someone grants a patent license for implementation that the IETF community has to consider the patent situation around the technology as irrelevant. Use of technology goes beyond implementation. This is acknowledged in the IETF policy documents. Compare, e.g., RFC 3979 and in particular the definition of the term Covers. I also disagree with the claim that the draft is unencumbered. I don't follow how you reach that conclusion from the patent disclaimer. You quoted only one paragraph out of several, and the other paragraphs are the ones that encumber use of the protocol. It may be your interpretation that the draft is unencumbered, but everyone get the same opportunity to make their own interpretation. As implementer of the technology, and having consulted with legal aid, I have made another interpretation. speaking as an individual, not wearing any hats Well, it's good to remember that there are *lots* of patents about larger systems that include IETF protocols (e.g., TLS, HTTP, MPLS, Mobile IP, or RADIUS) as components. What's claimed to be novel (and covered by the patent) is not the IETF protocol as such, but the combination: using the protocol(s) in certain environment in particular way to solve something. And of course there are lots of implementation technique patents where what's claimed to be novel (and covered by the patent) is some particular way of implementing the protocols (e.g. better performance than obvious implementations). Usually these types of patents are *not* disclosed to the IETF, since the protocol as such is not covered by the patent. In fact, my guess would be that we probably don't have *any* IETF protocols where someone has not patented using protocol A in bigger system B in way C to solve D (where B+C+D is something that the RFC did not describe, so it could be non-obvious and novel). If we required that IETF protocols must not have any such field of use restrictions (where using the protocol in certain way could be encumbered), we would not publish any protocols at all. My reading of RedPhone's IPR disclosure 1026 is that they claim to have a patent application about a larger system that includes tls-authz as one part, and uses it in particular way. If you want to build a system matching the numbered list 1..4 in the disclosure (RedPhone's description of what they claim is covered), then you would have to consider this IPR disclosure. However, I think there are many more good uses for tls-authz that do *not* match items 1..4. Just because someone has filed a patent application on some rather obscure combination of B+C+D should not prevent others from using the protocol for things not covered by that application. Thus, I support publishing this as an RFC (either Informational or Standards Track). (BTW, I think it's pretty clear that RedPhone didn't get the process right here. Some have claimed they did this knowingly with malicious intent, others have attributed it more to carelessness and ignorance -- I would say we can't really know without doing a Vulcan mind meld :-) Either way, I think we should consider the draft's technical merits and IPR situation *now*, and not put too much weight on the history.) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Sip] Last Call: draft-ietf-sip-dtls-srtp-framework (Frameworkfor Establishing an SRTP Security Context using DTLS) to ProposedStandard
Hi Thierry, There's ample precedent for using self-signed certificates to carry public keys in situations where a bare public key mode (if TLS/DTLS had it -- IKEv2 does have this, BTW) would have worked, too. Exactly the same approach as in this draft (exchange fingerprints via SDP, and use those to check self-signed certificates used in TLS/DTLS) is already used in RFCs 4572, 4582, and 4975. Several other RFCs (e.g. 3261, 3920, 5380) and drafts (e.g. draft-ietf-syslog-transport-tls, currently in RFC Editor Queue) also use self-signed certificates in some way. (Of course, using self-signed certificates for some particular purpose can't set a precedent that they'd be the best solution to all possible problems. They're a useful tool, but some problems require using other tools.) Best regards, Pasi -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Thierry Moreau Sent: 29 October, 2008 21:46 To: ietf@ietf.org Subject: Re: [Sip] Last Call: draft-ietf-sip-dtls-srtp-framework (Frameworkfor Establishing an SRTP Security Context using DTLS) to ProposedStandard The IESG wrote: The IESG has received a request from the Session Initiation Protocol WG (sip) to consider the following document: - 'Framework for Establishing an SRTP Security Context using DTLS ' draft-ietf-sip-dtls-srtp-framework-04.txt as a Proposed Standard This document approval at the IESG level might signal a shift in the IETF consistent use of PKI security certificates for remote party authentication in (D)TLS protocols. The present comment is submitted to make sure that the IESG decision is an educated one, and not made inedvertantly. If another document previously approved by the IESG is an accepted precedent for the subject matter discussed below, the present comment may be ignored. The present comment is neither for or against advancement of the draft. From the introduction section of the draft: The goal of this work is to provide a key negotiation technique that allows encrypted communication between devices with no prior relationships. The media is transported over a mutually authenticated DTLS session where both sides have certificates. It is very important to note that certificates are being used purely as a carrier for the public keys of the peers. This is required because DTLS does not have a mode for carrying bare keys, but it is purely an issue of formatting. The certificates can be self-signed and completely self-generated. From these indications it is easy to see that the framework would (ideally) require a (D)TLS protocol derivative in which bare peer public keys can be carried without the burden of security certificate. Despite the above wording, the current lack of such a (D)TLS mode might be more than a mere issue of formatting - it might be a consequence of a long-standing policy at the IETF. If this draft is approved by the IESG, it might signal that similar uses of self-signed-at-will (or otherwise meaningless) security certificates is an approved approach for circumventing the lack of a bare public key (D)TLS mode. Note that this is different from the PSK-TLS mode (pre-shared key) which explicitly relies on pre-established symmetric keys as a *replacement* for security certificate assurance. It is my understanding that the self-signed-at-will (or otherwise meaningless) certificate approach is technically feasible but should remain standardized outside of the IETF activities, if at all. Based on this understanding, my draft draft-moreau-pkix-aixcm (that also falls in this broad approach) has been submitted as a non-IETF informational RFC. (A comparative analysis between the SIP draft and mine is a matter of implementation strategy for the overall approach, and is thus out of scope for the present comment.) See http://www.rfc-editor.org/queue2.html#draft-moreau-pkix-aixcm . In any event, this comment is made for the sole purpose of making IESG/IETF directions more explicit. Thanks to Eric Rescorla who brought my attention to the similarities between the SIP draft and an early version of the ideas behind my draft. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Call for review of proposed IESG Statement on Examples
John C Klensin wrote: I continue to believe that the IESG could do something much easier and much more effective by issuing, not a collection of new rules, but a simple statement requiring that people either use suitably-reserved and dedicated identifiers or that they explain, explicitly and subject to community review, why not. I think that's pretty much what we tried to do, but apparently, the text doesn't quite read that way (and I agree that it's quite long). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Call for review of proposed IESG Statement on Examples
John C Klensin wrote: 1) Spam: apparently valid email addresses in an RFC are widely believed to have been harvested and included in Spam lists. The domain may receive spam at mailboxes other than the one used in the example email address, if the domain name is used in common name or brute force attacks. Please note that a careful reading of this paragraph would either ban or discourage the appearance of author email addresses in RFCs. Yet such addresses have been a firm requirement for many years (if I recall, since before there was an IETF). Questions: (i) Does the IESG intend to change the requirement for email addresses? BTW, http://www.rfc-editor.org/rfc-editor/instructions2authors.txt does not absolutely require including an email address (if you give some other contact method, such as postal address or telephone number), and there are RFCs that don't include it (e.g RFC 3718 from 2004; perhaps others exist, too). (ii) Does the IESG believe that the appearance of a domain name in an email address in an example is somehow more harmful or likely to draw the attention of spammers than one in an Author's Address section? If not, could you explain your reasoning? If you're an author, you have presumably given your permission to being listed in the Author's Address section, and can choose what address to put there. IMHO the crux of the proposed text is that since using email addresses (and domains, etc.) belonging to someone else can potentially cause harm (although usually not very serious), it's better if the owner of the address (instead of IESG) decides whether the potential harm is acceptable or not -- and this should be opt-in (instead of assuming that lack of complaints means its OK). (There may be exceptional cases when something else needs to be done, though.) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Capwap] Last call comments for capwap-threat-analysis-01
Scott G. Kelly wrote: Some comments inline below... Pasi.Eronen wrote: Couple of comments/observations about capwap-threat-analysis-01: There seem to be couple of places where this document isn't completely in sync with the protocol/binding documents. In particular, the following two places: Section 4.2, The current CAPWAP binding for IEEE 802.11 only supports the use of IEEE 802.11i [80211I] security on the wireless link. The current version of the binding spec seems to support WEP, too. I think Charles already addressed this. Right; I think we can say that the binding supports using WEP, but doing so has so many other security problems we don't bother discussing WEP in this document (or something more polite along those lines :-). Section 6.1: The text about Local MAC, Remote MAC, and Split MAC doesn't seem to match the other documents. E.g., there's no Remote MAC in the other documents, and description of Local MAC doesn't quite match the description in IEEE 802.11 binding. See RFC4118. Thanks for the pointer; however, since this document is a threat analysis for CAPWAP IEEE 802.11 binding, it should be aligned with the capwap-protocol-binding-ieee802 document, not RFC 4118. The document would benefit from some discussion about authorization. Especially if WTPs/ACs have manufacturer-issued certificates installed in factory, everyone can easily authenticate everyone else. And with DHCP AC option, this could zero configuration for WTPs -- except that this wouldn't be secure: WTP (and AC) needs some configuration to know who is the *right* AC (who are the *right* WTPs). I believe you attended the lunch with Sam where this was discussed. We've explicitly deferred certificate-related authn/authz discussion for now so that we can get these specs published in a meaningful timeframe, although we do discuss validating the EKU bits and MAC address for this. This is the classic camel's nose problem: if you attempt to add text that addresses this more fully, where do you stop? I don't think we want to open this can of worms just now. At Sam's request, we added some cert-related clarifications, but I think we all agreed to stop there. Trying to *solve* these problems would probably open a can of worms, but I wasn't proposing that -- just accurately describing what is solved and what isn't. (That shouldn't be more than couple of paragraphs.) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last call comments for capwap-protocol-binding-ieee80211-07
I read capwap-protocol-binding-ieee80211-07 on my way to Dublin; here are some comments/observations. Substantial topics first: I was under the impression that 802 (or at least 802.11) required (or assumed) strict in-order delivery -- but perhaps I remember this wrong? (Obvious, tunneling over arbitrary IP hops doesn't guarantee in-order delivery, and it seems the data channel doesn't have mechanisms to reorder or drop out-of-order packets.) 802.11 header has 4 different addresses, all of which can be different. When doing split MAC with 802.3 frames, the 802.3 frame contains only two of the addresses; the Radio MAC Address field in CAPWAP header contains the third -- but what about the fourth one? The document should have some more text about how the WTP processes IEEE 802.11 IEs it receives from the AC. Section 6.6 talks about copying them to Beacon/Probe Response messages, but it seems that in some cases, the WTP also does some local processing. (I was sort of expecting a list of all IEs, and description of expected WTP processing (possibly none) for them.) Section 6.15: Is this really the PTK (which also includes KCK and KEK, which aren't needed by the WTP since the AC is handling the EAPOL-Key messages -- so probably shouldn't be sent to PTK), or only the TK used for encrypting traffic? Is the binding specified here sufficient for 802.11r as well, or would something more be needed? (I don't know the answer -- but probably the document should tell what it is) Section 6.14 says that packets exceeding this priority are either dropped or down-tagged -- but it seems which of these is done depends on WTP (and the AC can't even know what the WTP does). Isn't this problematic for interoperability? Question: Section 4 says the Destination WLANs field is used only for multicast/broadcast; how is the destination WLAN determined for unicast? (Is this by mapping destination MAC address to earlier IEEE 802.11 Station messages -- which means a single MAC address can't be in more than one WLAN?) (Perhaps the document should have couple of sentences about this) Question: The WLAN ID is always shown as 8 bits, but it seems some other parts limit the spec to 16 WLANs per WTP Radio. Could a WTP supporting more than 16 WLANs use multiple Radio IDs, or is 16 a hard limit? (Perhaps the document should have couple of sentences about this -- at least saying that WLAN ID is between 0 and 15) Minor clarifications/editorial nits: Section 3: CAPWAP base protocol requires that all Request messages are odd numbers, and Responses even; these aren't. Section 3.1, sent after the CAPWAP Configuration Update Request message (..) has been received by the WTP probably means sent after the CAPWAP Configuration Update Response message has been received by the AC? Section 5.10: Station QoS Profile should be IEEE 802.11 Station QoS Profile Section 6.1 and 6.21: are some of these 802.11 information elements optional, or are all of them always included? Section 6.1 and 6.21: what do you put in Key Status if you're not using encryption at all? Section 6.21: to avoid repetition of text, I'd suggest simply pointing to existing text in Section 6.1 for field descriptions. Section 6.1 and 6.21: 32 byte Session Key -- length depends on Key Length field, right? Section 6.2/10.6: is the Combiner a bit field or enumerated field? (And in the former case, an explicit bit diagram would be very useful to avoid confusion about bit numbering) Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably be shown as 3 bits in the diagram, to make it unambiguous about which bits are not used. Section 6.15: The sentence Note that AKM-Only is MAY be set... would benefit for some clarification -- does 802.11 really drop all unencrypted EAPOL-Key frames if you have an encryption key? (it seems that would cause difficulties when e.g. client reboots -- but I'm not sure what 802.11 does here) Section 6.15: MUST NOT be sent if the WTP had not specifically advertised support for the requested encryption scheme: would be easier to understand if it said how the WTP advertises this (presumably, the Encryption Capabilities field in the WTP Descriptor Message Element?) Sections 6.20 and 6.22: the DSCP Tag field should probably be shown as 6 bits in the diagram, to make it unambiguous how it's sent in IPv4/IPv6 header (and which bits are unused). Section 6.16, maximum value of 65535 -- the fields are 32 bits, so probably should be 4294967295? Section 6.20 and 6.22: if packets are to be DSCP tagged would benefit of clarifying what packets are meant (I guess it means CAPWAP Data packets sent from the WTP to the AC?). Section 6.22/10.9: is the Tag Packets a bit field or enumerated field? (In the former case, an explicit bit diagram would be very useful to avoid confusion about bit numbering.) Section 6.23: Country Code field probably should be called Country String (since it contains other things than the country code, and it's called
Last call comments for capwap-threat-analysis-01
Couple of comments/observations about capwap-threat-analysis-01: There seem to be couple of places where this document isn't completely in sync with the protocol/binding documents. In particular, the following two places: Section 4.2, The current CAPWAP binding for IEEE 802.11 only supports the use of IEEE 802.11i [80211I] security on the wireless link. The current version of the binding spec seems to support WEP, too. Section 6.1: The text about Local MAC, Remote MAC, and Split MAC doesn't seem to match the other documents. E.g., there's no Remote MAC in the other documents, and description of Local MAC doesn't quite match the description in IEEE 802.11 binding. The document would benefit from some discussion about authorization. Especially if WTPs/ACs have manufacturer-issued certificates installed in factory, everyone can easily authenticate everyone else. And with DHCP AC option, this could zero configuration for WTPs -- except that this wouldn't be secure: WTP (and AC) needs some configuration to know who is the *right* AC (who are the *right* WTPs). Editorial nits: Section 9.2: the section title includes Rootkit installation: is this in right place, or should it be in Section 9.3? Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last call comments for capwap-protocol-specification-11
I read capwap-protocol-specification-11 on my way to Dublin; here are some comments/observations. Substantial topics first: Section 3.5: The text about MTU discovery doesn't look right; Section 3.5 seems to assume that after the WTP has discovered the AC it wishes to communicate with, RFC 1191/1981/4821 would provide it with the MTU, and then the WTP would establish the CAPWAP session. But those RFCs don't specify e.g. what packets would be used for probing for the MTU. Section 4.6.29: Using MD5 in a new protocol, and not providing algorithm agility for moving to new algorithms, is probably not such a great idea. The linking of control and data channels, and how DTLS session resumption is used here, seems unnecessarily complicated. Normally session resumption is totally TLS internal optimization, and applications running over TLS don't know (and have no need to know) whether full or abbreviated TLS handshake was used. It seems this document wouldn't really need to say anything about session resumption; if the WTP provides the Session ID in data channel, and AC checks that both DTLS connections were established by the same authenticated client, that seems sufficient. This would seem to remove much implementation complexity; e.g. the requirement in 4.4.3 that The AC DTLS implementation MUST NOT accept a session resumption request for a DTLS session in which the control channel for the session has been torn down doesn't follow the usual TLS/DTLS module boundaries. Section 3.3: Should IPv4 use a well-known multicast address (instead of broadcast), too? Why not? The protocol allows the AC to add and delete static MAC ACL entries, but it seems the AC can't check what the current ACL entries are. This means the WTP and AC could get out-of-sync, right? (The AC can't delete the unneeded static MAC ACL entries if it doesn't know what they are.) Section 3.3: there's a single sentence about DNS-based discovery; probably slightly more details would be useful. Section 2.4.3: handling of cookies that fail to validate is really a DTLS detail, and shouldn't be in this specification. RFC 4347 doesn't say what the DTLS server should do, but I think the right approach is to treat an invalid cookie the same as no cookie (and not discard the whole message, as is suggested here -- I think that could lead to weird failure modes even in the absence of malicious attackers). I'll raise this on the TLS mailing list, so it can be clarified in DTLS 1.2 update. Section 4.3: it seems that allocation of WBIDs (and message element numbers in 4.6) would be better done in the document specifying the binding. Considering that WBID allocations require Standards Action, especially allocating WBIDs for technologies for which not even an Internet-Draft exists yet seems premature. Section 4.5.3: Is CAPWAP control protocol strictly lock-step (once you send a Request, you must wait for Response until you send another Request), or are multiple outstanding requests allowed? Can you give up a Request (stop retransmitting it even though you haven't received a Response), and move to the next Request? What should you do if you receive a Request with a Sequence Number that's too old (less than previous Request you've seend) or too new (greater than previous Request+1)? Replay protection is an optional feature in RFC 4347. Should this document say something about it? (e.g. MUST use?) There's some inconsistency about NAT detection: Sections 4.6.12, 4.6.13, and 4.6.15 say it's done using CAPWAP Local IPv4/6 address message elements; Sections 4.6.44, 4.6.45, and 6.1 say it's using WTP IPv4/6 address message elements. Minor clarifications/editorial nits: Section 2, 1st para: should reference RFC4347 instead of RFC4346 Section 2.3: should have a sentence saying what transitions represented by punctuation characters mean. Section 2.4.1: DTLS will never terminate the handshake due to non-responsiveness; instead, DTLS will continue to increase its back-off timer period While RFC 4347 doesn't specify how long you should continue retransmitting, the intent certainly was not to continue indefinitely. Section 2.4.3 text about DTLS retransmissions is slightly inaccurate; DTLS handshake isn't strictly request/response, and both parties (not just the DTLS client) retransmit based on timers (in some situations). Section 2.4.4.1: should reference RFC4346 instead of RFC4279. Section 2.4.4.2: TLS_DHE_PSK_WITH_AES_256_CBC_SHA is listed twice. Section 4.4.1, The 8 bit Length field looks like 16 bits. Section 4.4.2: is it unambiguous which 802.3 frame fields are included or omitted? (e.g. preamble, SOF delimeter, etc.) Section 4.6, message element 29 is spelled Image Information in the rest of the document, but Image Info here Section 4.6.1, description of R-MAC Field needs some more text (current text would probably be fine if the field was only 1 bit, but it's 8 bits). Section 4.6.6 (AC Timestamp): the timestamp format in RFC 1305 is 64
Discussions about IPsec maintenance/extensions WG
Hi all, We're starting a discussion about the possibility of forming an IPsec maintenance/extensions working group. If you're interested, join the IPsec mailing list. Joining the list: http://www.ietf.org/mailman/listinfo/ipsec List archive: http://www.ietf.org/mail-archive/web/ipsec/current/maillist.html Best regards, Pasi ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call on Walled Garden Standard for the Internet
Yoshihiro Ohba wrote: I think Vidya has a good point. My opinion is that, bootstrapping protocols from long-term credentials used for network access authentication is not such a bad idea, but we just do not know yet the best way to realize it: http://user.informatik.uni-goettingen.de/~mobiarch/2007/slides /mobiarch07-panel-YoshiroOhba.pdf Such bootstrapping or single sign-on protocol could (and IMHO should) still be independent of the link it's run over (i.e., it would work over any IP network). BTW, 3GPP and 3GPP2 already have one such a single sign-on protocol, which uses the same long-term credential you'd usually use for network access authentication to set up short-term security assocations for higher layer protocols (but it runs over any IP network, so it works even if, e.g., your current access network did not require any authentication). It's called Generic Bootstrapping Architecture or GBA. (GBA design also allows adding new types of credentials between the client and the key distribution center (BSF) without impacting other elements of the system. You could, e.g., add support for EAP here in a way that would be independent of the link layer currently being used. So far, 3GPP/3GPP2 have not needed this, but if GBA ends up being used in other systems as well, it could be useful.) Best regards, Pasi ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call on Walled Garden Standard for the Internet
Avi Lior wrote: Here I agree with you fully: this is an extremely bad idea. Architecturally linking application security to the link layer is just bad engineering, and hinders the ability of link layers and applications evolve independently of each other. Lets start with this: Any application? Well, at least applications which are not inherently (*) tied to a specific access network. In other words: if it simply doesn't make any sense to use the application from a different link or access network, then tying it to the link layer authentication might be one feasible option. Otherwise, it's a bad idea. (*) Inherently: by their nature -- and not e.g. just by current business structures (which are likely to change due to mergers, acquisitions, divestiture, etc.) or SDO boundaries (both users, access providers, and service providers are, over the time, likely to be interested in network access technologies from multiple SDOs). The emsk-hierarchy document should not give higher layer applications as an example use case; instead, it should explain why this is a bad idea, and recommend that keys derived from link layer authentication should be used solely for link-layerish things (such as link layer handoffs; Mobile IP is a borderline case here). Mobile IP is an application. So I guess you are okay with some applications right? Someone mentioned DHCP as one application which is inherently tied to a specific access network/link. If you want to use Mobile IP to provide mobility only within a single access network -- and assume that neither you nor your customers will ever be interested in other access technologies in the future (or that mobility to e.g., IETF WLAN is either unimportant, or handled by some other mechanisms), then you could tie Mobile IP and link layer authentication. Otherwise, I'd recommend making it access independent. Best regards, Pasi ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-hokey-erx-09 (-10)
I have just scanned through version -10 of this draft, posted couple of hours ago. This version addresses my comments 5 and 6; and comments 4 and 10 are obsolete since the text I commented has been removed. The remaining comments are still valid. One additional comment for version -10: 16) Section 5.3.2, EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64-bits in length and so the username portion takes up 128 octets. EMSKname is not defined in this document (or any of its references, as far as I can tell); and encoding 64 bits as hexadecimal doesn't take 128 octets anyway. Best regards, Pasi -Original Message- From: Eronen Pasi (Nokia-NRC/Helsinki) Sent: 05 February, 2008 14:30 To: '[EMAIL PROTECTED]'; 'ext Tim Polk'; '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]'; 'ietf@ietf.org'; 'ext Lakshminath Dondeti'; [EMAIL PROTECTED] Subject: Gen-ART review of draft-ietf-hokey-erx-09 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-hokey-erx-09 Reviewer: Pasi Eronen Review Date: 2008-02-05 IETF LC End Date: 2008-02-07 IESG Telechat date: 2008-02-07 Summary: This draft is on the right track but has open issues, described in the review. Comments: Most serious comments first: 1) The document should contain explicit text about the relationship between ERP and the lower layers; for example, what would need to be changed in lower layers that use EAP to add support for ERP. (E.g. with parallel EAP-Request/Identity+EAP-Initiate/Reauth-Start the protocol is no longer lock-step; the authenticator is no longer responsible for all the retransmissions, etc.) 2) The document specifies message fields for so-called channel binding information, but contains basically no text about what to put in the field, or how to process them. Note that just saying RADIUS Calling-Station-Id is not very helpful, since peers don't usually implement RADIUS. The spec either needs to describe what the field should contain, or should tell where that is described. Also, the semantics are highly unclear: the spec says these attributes can be included in EAP-Initiate/Re-Auth and EAP-Finish/Re-Auth messages -- but how do the peers know when to include them? Or what to do with them when received? E.g. if the EAP-Initiate/Re-Auth contains some of these attributes, should the EAP-Finish/Re-Auth also contain them? With same values? (Answers to some of these questions may be obvious to people who participated in the channel binding discussions 3..5 years ago; but they're not in the current specification. And if there's any difficulty in writing text about them, it IMHO suggests they are not that obvious.) 3) The document uses terms EAP Peer-ID and EAP Session-ID which are not part of RFC 3748; they are defined in draft-ietf-eap-keying, which needs to be (normatively) referenced. 4) Section 4.1.1 defines NameDerivationKey = EAP Session-ID, when K used in rRK derivation is the EMSK; however, existing EAP methods are not required to export a Session-Id. This document needs to specify what is done when no Session-ID is exported, or explicitly say that it works only with EAP methods that export a session id. 5) Section 5.1, In this case, the lower layer may already have derived the TSKs based on the MSK received earlier. The lower layer may then choose to ignore the rMSK that was received with the ER bootstrapping exchange. Alternatively, the lower layer may choose to generate a TSK from the rMSK. Who/what coordinates this; that is, ensures that both peer and authenticator use the same key (MSK or rMSK)? The following comments are basically nits that should be easy to fix: 6) Section 4.1.1 specifies rRK derivation seed as S = rRK Label + \0 + NULL + length. It's not clear what NULL means here; IMHO one obvious interpretation would be a single zero octet (same as \0), but then again, perhaps an empty (zero-length) string is intended, since a different notation was used? 7) Section 4.1.1 specifies the rRK label as EAP Re-(newline)(white space)authentication Root [EMAIL PROTECTED]; this is a rather unfortunate place to break a line, as the hyphen could be interpreted in two different ways. 8) Inconsistent IANA considerations: slightly different USRK label string is used in Sections 4.1.1 and 8. 9) Section 4.1.5 says the most significant k octets of the output are used; the term most significant makes sense when talking about integers. When talking about octet strings, I'd find first or last less ambiguous. 10) Sections 5.2 and 5.3.2.2, If rIKname-NAI is present, the authenticator MUST use that NAI to route the message.
RE: I-D submission tool
John C Klensin wrote: For the second, it claims that the file isn't plain text and won't post it or even provide a manual submission path. The file is output or xml2rfc, has proper CRLF line endings, and, if it contains any non-ASCII characters or serious format misbehavior, the online version of idnits can't find it, even in very verbose mode. [rt.amsl.com #1799] I also encountered this problem (rt.amsl.com #1730), and after some debugging, discovered what the problem was: the submission tool uses the file program to check whether the file is plain text or not, and (apparently) the file program on the new servers behaves slightly differently from the old one. In particular, if you have the string (if approved) on your cover page, some versions of file (at least some Linux distributions) will identify your draft as Lisp/Scheme program text instead of just ASCII :-) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-hokey-erx-09
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call
comments you may receive.
Document: draft-ietf-hokey-erx-09
Reviewer: Pasi Eronen
Review Date: 2008-02-05
IETF LC End Date: 2008-02-07
IESG Telechat date: 2008-02-07
Summary: This draft is on the right track but has open issues,
described in the review.
Comments:
Most serious comments first:
1) The document should contain explicit text about the relationship
between ERP and the lower layers; for example, what would need to be
changed in lower layers that use EAP to add support for ERP.
(E.g. with parallel EAP-Request/Identity+EAP-Initiate/Reauth-Start
the protocol is no longer lock-step; the authenticator is no longer
responsible for all the retransmissions, etc.)
2) The document specifies message fields for so-called channel
binding information, but contains basically no text about
what to put in the field, or how to process them.
Note that just saying RADIUS Calling-Station-Id is not very helpful,
since peers don't usually implement RADIUS. The spec either needs to
describe what the field should contain, or should tell where that is
described.
Also, the semantics are highly unclear: the spec says these attributes
can be included in EAP-Initiate/Re-Auth and EAP-Finish/Re-Auth
messages -- but how do the peers know when to include them? Or what to
do with them when received? E.g. if the EAP-Initiate/Re-Auth contains
some of these attributes, should the EAP-Finish/Re-Auth also contain
them? With same values?
(Answers to some of these questions may be obvious to people who
participated in the channel binding discussions 3..5 years ago;
but they're not in the current specification. And if there's any
difficulty in writing text about them, it IMHO suggests they
are not that obvious.)
3) The document uses terms EAP Peer-ID and EAP Session-ID which
are not part of RFC 3748; they are defined in draft-ietf-eap-keying,
which needs to be (normatively) referenced.
4) Section 4.1.1 defines NameDerivationKey = EAP Session-ID, when K
used in rRK derivation is the EMSK; however, existing EAP methods are
not required to export a Session-Id. This document needs to specify
what is done when no Session-ID is exported, or explicitly say that it
works only with EAP methods that export a session id.
5) Section 5.1, In this case, the lower layer may already have
derived the TSKs based on the MSK received earlier. The lower layer
may then choose to ignore the rMSK that was received with the ER
bootstrapping exchange. Alternatively, the lower layer may choose to
generate a TSK from the rMSK.
Who/what coordinates this; that is, ensures that both peer
and authenticator use the same key (MSK or rMSK)?
The following comments are basically nits that should be easy
to fix:
6) Section 4.1.1 specifies rRK derivation seed as S = rRK Label
+ \0 + NULL + length. It's not clear what NULL means here;
IMHO one obvious interpretation would be a single zero octet
(same as \0), but then again, perhaps an empty (zero-length)
string is intended, since a different notation was used?
7) Section 4.1.1 specifies the rRK label as EAP Re-(newline)(white
space)authentication Root [EMAIL PROTECTED]; this is a rather
unfortunate place to break a line, as the hyphen could be
interpreted in two different ways.
8) Inconsistent IANA considerations: slightly different USRK label
string is used in Sections 4.1.1 and 8.
9) Section 4.1.5 says the most significant k octets of the output
are used; the term most significant makes sense when talking
about integers. When talking about octet strings, I'd find first
or last less ambiguous.
10) Sections 5.2 and 5.3.2.2, If rIKname-NAI is present, the
authenticator MUST use that NAI to route the message. If the
rIKname-NAI is not present, the authenticator MUST use the NAI in
the Peer-ID to forward the message via AAA. If neither are
available, the authenticator MUST forward the ERP messages to the
local ER server. If none of these rules apply, the authenticator
MUST drop the packets silently.
Let's see; it seems the logic is as follows:
if (rIKname-NAI is present) {
use rIKname-NAI
} else if (rIKname-NAI not present Peer-ID present) {
use Peer-ID NAI
} else if (rIKname-NAI not present Peer-ID not present) {
use local
} else {
drop silently;
}
I can't quite figure out when the If none of these rules apply
text would be used. Perhaps the intent was to drop the packet
if it can't be parsed at all? If so, this should be described
more clearly.
11) Sections 5.3.1, 5.3.2, and 5.3.3 do describe TVs/TLVs which
can be included in the messages, but don't clearly specify
which of them are always present, and which may be omitted
in some circumstances.
12) Section 5.4, The server expects a sequence number of zero or
RE: Call for Comment: RFC 4693 experiment
While there are a couple of IONs whose content I find valuable (such as ad-sponsoring and discuss-criteria), IMHO the same information could be placed in ordinary web pages without losing much -- and perhaps gaining something in the process. Currently, we have similar information scattered over random web pages on ietf.org, random pages in IESG wiki, and the IONs (with different procedures and tools for updating them). My reading between the lines interpretation of RFC 4693 Section 5 is that perhaps creating IONs was considered easier than e.g. fixing the procedures and tools for maintaining ordinary ietf.org web pages. (This may well have been correct, BTW -- but perhaps the secretariat transition will bring some new efforts to update www.ietf.org as well?) But looking forward, and considering the question what should be done about IONs, the answer is less clear. If IONs encourage people to clearly document things that are useful to others, then they have some value there. Maybe - and this is just an unsupported hypothesis - folks at IETF are more comfortable (or efficient, or motivated) with writing things that are called documents rather than web pages (even when there's no difference in actual content). And moving the same information to ordinary web pages would probably mean creating some sort of structure (e.g. header for distinguishing draft and approved versions with some kind of standard header) and processes (for e.g. approval). However, how to organize web pages is a topic where I think micromanagement (from e.g. me) would not be very productive. If useful information gets communicated in effective fashion, I'm OK with letting the IESG to choose the tools they use for maintaining things on the web, and don't really mind whether they get called IONs, wikis, or just web pages. Best regards, Pasi -Original Message- From: ext The IESG [mailto:[EMAIL PROTECTED] Sent: 16 January, 2008 21:41 To: IETF Announcement list Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: Call for Comment: RFC 4693 experiment RFC 4693, Section 4 says: This experiment is expected to run for a period of 12 months, starting from the date of the first ION published using this mechanism. At the end of the period, the IESG should issue a call for comments from the community, asking for people to state their agreement to one of the following statements (or a suitable reformulation thereof): According to http://www.ietf.org/IESG/content/ions/ the first ION was published 12-Jan-2007. This means the experiment ended last Saturday, and it's time for the IESG to issue the call for comments. Please tell us what you think about the experiment. Have IONs been valuable? Should we continue to make use of this mechanism? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Call for Comment: RFC 4693 experiment
Stephane Bortzmeyer wrote: On Mon, Jan 21, 2008 at 02:24:34PM +0200, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote a message of 66 lines which said: My reading between the lines interpretation of RFC 4693 Section 5 is that perhaps creating IONs was considered easier than e.g. fixing the procedures and tools for maintaining ordinary ietf.org web pages. That's not my reading at all. This section explains clearly the problem with Web pages: Web pages, which can be changed without notice, provide very little ability to track changes, and have no formal standing -- confusion is often seen about who has the right to update them, what the process for updating them is, and so on. It is hard when looking at a Web page to see whether this is a current procedure, a procedure introduced and abandoned, or a draft of a future procedure. ... o Unlike Web pages, there is an explicit mechanism for finding all current versions, and a mechanism for tracking the history of a document. Many web page management systems (such as wiki engines) have reasonably good mechanisms for tracking the history of web pages. And similar processes for updating them (and status line at the beginning of page) could be applied for any pages, so this does not really explain why they had to be kept separate (and called differently) from ordinary web pages. (I've heard rumors that at the time when RFC 4693 was written, updating www.ietf.org web pages meant emailing your text to the secretariat staff, who then edited the actual pages more or less manually. This kind of system would easily explain why www.ietf.org is a mess... and IONs would certainly be an improvement over that.) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: AAAA records to be added for root servers
Brian E Carpenter wrote: As Phill H-B has implied more than once, there's scope for a library on top of the socket API that takes care of this once and for all. Does anyone have such a library? Some TCP/IP stacks include this kind of API: http://msdn2.microsoft.com/en-us/library/ms741554.aspx http://msdn2.microsoft.com/en-us/library/ms741557.aspx Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Daily Dose version 2 launched
Michael Dillon wrote: The second, and more important, reason is that AFAIK most feed readers and aggregators wouldn't be able to render the expanding yellowish boxes (which contain ID abstracts and other details) anyway, because they rely on CSS and JavaScript. Since when has anyone considered CSS and JavaScript to be CONTENT!?!?!? Generally, RSS and ATOM feeds are produced by software. Software can do things like parse web pages and separate the content from the markup and also shorten long content items to the first 300 characters or so. In the real world, this kind of thing is Python 101 in that beginners who have never before used a scripting language somehow manage to set up their own RSS and ATOM feeds. Seeing the first 300 characters is useful for things like blogs, because it usually allows you to figure out whether you really want to read the whole article or not. I did not find it useful to see e.g. the first 300 characters of the Daily Dose page. I also considered other options (such as producing a version without the yellowish detail boxes), but did not find them personally useful either. (In other words: this was done intentionally, not because I can't write Python (well, Perl in this case).) In the real world, web site developers also do something called usability testing which catches all these issues before the site ever goes live. For example, read this: http://www.useit.com/alertbox/2319.html I guess this is talking about real-world web site developers, who develop sites for others for money. I would indeed expect e.g. the secretariat to do this kind of testing for services paid from our meeting fees. But Daily Dose is not one of those services. (BTW, Daily Dose has been live for almost 2 years now.) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Daily Dose version 2 launched
Jari Arkko wrote: Apparently my reader (Thunderbird 1.5) does something funny with the feed; it shows the actual content. I like that, but I have not looked at the details of what is actually provided in the feed and what is fetched from the link. The behavior of Thunderbird depends on whether you select the Show the article summary instead of loading the web page box when you subscribe to the feed. If you select this, you see only the summary (which is empty in the current feeds); if you don't, you get the full page (however, by default Thunderbird seems to ignore JavaScript here, so the expanding boxes don't work.) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Daily Dose version 2 launched
Michael Dillon wrote: If I'm not mistaken, you are the developer, not the set of end users. In which case your personal preferences are not relevant. They are relevant in the sense that *I* decide what I want to spend *my* time on. I'm open to suggestions and good ideas, but what gets implemented isn't decided by the set of end users. If you can provide a choice of two feeds, one using RSS and one using ATOM, then why can't you also offer a summary feed and a full content feed? I might. What would you suggest including in these feeds? In other words, what to include/omit in the summary feed? And what should the full content feed look like? (How should the draft abstracts etc. be shown?) snip P.S. I thought this was part of the site redevelopment using Django but perhaps I was mistaken. It is not (and I'm actually using Perl instead of Django). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Daily Dose version 2 launched
Stephane Bortzmeyer wrote: Actually, the problem I have with both feeds is that they have no content, just the titles (which does not change, except for the issue number), the date and the link. Not very useful. There were two reasons for this: the first is size (one issue can easily be 100 KB, so a feed containing the 20 most recent issues would be quite large). The second, and more important, reason is that AFAIK most feed readers and aggregators wouldn't be able to render the expanding yellowish boxes (which contain ID abstracts and other details) anyway, because they rely on CSS and JavaScript. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Daily Dose version 2 launched
Hi, Some of you may already be familiar with the Daily Dose of IETF tool, which has been running since late 2005 (at address http://people.nokia.net/~pasi/dailydose/) For those who haven't seen this yet: Daily Dose is a tool that shows what's new today in IETF: messages from the IETF Announce mailing list, new RFCs and Internet-Drafts, draft progress through IETF process, new IPR disclosures, and much more (more details can be found at http://tools.ietf.org/dailydose/about.html). The tool has now undergone a major rewrite and facelift. The biggest changes compared to version 1 are: - New address http://tools.ietf.org/ -- this should provide more bandwidth and reliability. Big thanks to Henrik for helping with this! - New graphical layout. - Hand-written articles and classified ads in addition to automatically generated content. If you have any comments or suggestions, join the tools-discuss mailing list (https://www1.ietf.org/mailman/listinfo/tools-discuss), or contact me directly. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [IPsec] Re: Last call comments for draft-lepinski-dh-groups-01
Paul Hoffman wrote: 2) For IKEv1/IKEv2, the document should explicitly specify how ECC points are converted to octet strings (for KE payloads and resulting shared secret value). Currently, there are at least three incompatible options (RFC 4753, RFC 2409, and draft-ietf-ipsec-ike-ecc-groups-10 drafts). I'd suggest just saying the same way as in RFC 4753. This bodes really poorly for interoperability. draft-lepinski-dh-groups needs to be revised to specify one of the methods, and that needs to be discussed on the IPsec mailing list. I would not assume that implementers would prefer RFC 4753 over draft-ietf-ipsec-ike-ecc-groups. I suggested the same way as in RFC 4753 not because I particularly prefer that point-to-octet-string conversion method, but because I would prefer not having three different methods (two is bad enough). (Note that the current ecc-groups-10 draft actually tries to modify the definitions of groups 19/20/21 from RFC 4753: it reuses the same numbers but with different point-to-octet-string conversion method.) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Third Last Call: draft-housley-tls-authz-extns
The IESG is considering approving this draft as an experimental track RFC with knowledge of the IPR disclosure from Redphone Security. The IESG solicits final comments on whether the IETF community has consensus to publish draft-housley-tls-authz-extns as an experimental standard given the IPR claimed. not wearing any hats Basically repeating the comments I made earlier: I think this document is somewhat useful, and whatever you may think about IPRs, basically nobody has claimed that the technical solution is flawed (except one minor detail, easily solved by an RFC editor note -- see below) or undesirable. However, since there doesn't seem to be widespread support for this draft, an Experimental RFC seems like the most appropriate forward (since Experimental does not need to represent IETF community consensus or recommendation). The minor detail that should be fixed (as was pointed out by others) is changing the length fields from 16 bits to 24 bits (the rest of TLS already uses 24-bit length fields for certificates). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Third Last Call: draft-housley-tls-authz-extns
John C Klensin wrote: Assuming that this logic is reasonable (and, personally, I do), the question remains as to why the document deserves the special treatment of IESG sponsorship, rather than turning it over to the tender mercies and independent review of the independent submission process. If nothing else, handling it as an independent submission would remove any suspicion that it was being given special treatment because one of its authors was IETF Chair. I'm not strongly advocating that approach, just asking. The IANA rules in this case require a document approved by the IESG; otherwise, independent submission would indeed be preferable. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last call comments for draft-lepinski-dh-groups-01
Two comments about the IPsec-related parts: 1) Section 1 says: Sixteen additional groups subsequently have been defined and assigned values by IANA for use with IKE (v1 and v2). All of these additional groups are optional in the IKE context. Of the twenty-one groups defined so far, eight are MODP groups (exponentiation groups modulo a prime), ten are EC2N groups (elliptic curve groups over GF[2^N]) and three are ECP groups (elliptic curve groups over GF[P]). This is not totally correct. As of this writing, no EC2N groups have been assigned values for use with IKEv2. Also, eight of the ten EC2N groups for IKEv1 are not documented in any RFC. (And yes, I'm aware of draft-ietf-ipsec-ike-ecc-groups -- but that hasn't been approved yet, and requires changes before approval.) 2) For IKEv1/IKEv2, the document should explicitly specify how ECC points are converted to octet strings (for KE payloads and resulting shared secret value). Currently, there are at least three incompatible options (RFC 4753, RFC 2409, and draft-ietf-ipsec-ike-ecc-groups-10 drafts). I'd suggest just saying the same way as in RFC 4753. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawing sponsorship of draft-housley-tls-authz-extns
Thomas Narten wrote: If the above text were in effect today, would it be sufficient to cover the situation at issue here? (Now would be an excellent time to consider updates/clarifications to the above text.) I don't think so. The text allows IESG to override the allocation procedures when they judge there is strong IETF consensus to do so. In the situation at issue here: IMHO the main question is whether we have rough consensus that this particular draft should be published as non-Standards Track RFC. If the IESG thinks we have this consensus, they would just approve the document, and the override procedure would not be needed. If the IESG thinks there is no consensus (or it's too rough), the override rule wouldn't apply. So while I think the override rule might be valuable in some cases, it doesn't seem to help here. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints (was: Re: Withdrawing sponsorship...)
Paul Hoffman wrote: Why not? As long as the reader of the IANA registry can ascertain which codepoint owner is at a particular level, how would that affect interop? Being able to ascertain what the level is isn't enough; you also need to know (and more importantly, care) about the differences in the levels :-) I'd say there are lot of implementors who don't really care that much for the distinctions between an individual Internet-Draft, a WG draft, an Experimental RFC, or Proposed Standard RFC. But if only the latter two (or three) would have proper numbers in them (instead of TBD-BY-IANA), that would send a clear message that this not ready yet... (but of course, this doesn't always work; if there's strong enough pressure to implement, people will invent some numbers there) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints (was: Re: Withdrawing sponsorship...)
John C Klensin wrote: To me, the fundamental question here is whether, in the last analysis, we consider it more important to have * the best and most extensive Internet interoperability possible or * a maximum of real or imagined IETF control over all protocols in use on the Internet. We claim to believe the former and then often behave as if we believe the latter. There are also cases when the latter can also promote the former. The hurdle of getting IETF consensus and publishing an RFC does weed out many crazy proposals that, in all fairness, would not have made the Internet work better, and would not have promoted interoperability. Or in other words: we do have many proposals for extending IETF protocols whose primary motivation is not solving a real-world need, but rather finding some work for the standardization guys to do (or getting a PhD or something). Those extensions might even get implemented in some sense of the word (anyone can set up a SourceForge project), but are not even meant to be deployed. If by having some control over IANA allocations we weed out of this stuff, I have no problems with it. But I agree that the controls should not be too strict, so that protocols that actually get deployed are able to get the numbers, and are documented as RFCs (but IMHO something stricter that first come first served is usually beneficial). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IANA registration constraints (was: Re: Withdrawing sponsorship...)
Paul Hoffman wrote: At 12:08 PM +0300 6/13/07, [EMAIL PROTECTED] wrote: The hurdle of getting IETF consensus and publishing an RFC does weed out many crazy proposals that, in all fairness, would not have made the Internet work better, and would not have promoted interoperability. It does not need to promote interoperability; being interop-neutral is sufficient. How does giving a codepoint to someone with a crazy (and let's say even dangerous to the Internet) idea hurt interoperability? It seems to be interop-neutral. I think giving out codepoints freely would in many cases encourage having multiple (often half-baked) solutions to the same problem. To give one example we both worked on: I think it's good we didn't allocate codepoints to all the individual MOBIKE protocol proposals (mine, Tero's, Francis's), and instead were forced to work together and converge on a single protocol. Probably the market would have eventually picked one of them as the winner, but meanwhile, the situation would IMHO not have been interop-neutral. (And working together also produced a better protocol than any of the individual drafts were.) I'm not saying that this particular cooperation would not have happened with less strict IANA policies -- but I do believe that if the bar for getting codepoints and publishing an RFC would be significantly lower than today, we would have a much larger number of poorly concieved and overlapping extensions to various IETF protocols. (And IMHO that would not always be interop-neutral.) However: I do agree with John Klensin's statement that there is a difference between registering a parameter for a non-standard specification that is already deployed and in successful use and registering one for a wild idea by one person. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawing sponsorship of draft-housley-tls-authz-extns
Sam, I'm quite disappointed with the way you chose to handle this. I do agree with your assessment that we do not, at this time, have rough consensus to publish this on Standards Track. However, based on the public comments I have seen (obviously, I have not seen comments sent only to the IESG), significantly more people supported publishing this (in some form) than were totally opposed to publishing. I find it totally plausible that someone could interprete this as rough consensus for publishing this as a non-Standards Track RFC. Since the Standards Action has been initiated, and the document has gone through IETF last call, I think the decisions about the Standards Action (whether to publish this or not, at what status, with what changes) should be made by the IESG as a whole, not solely by the sponsoring AD. While it is at each AD's discretion not to sponsor some document (and not initiate Standards Action), I don't think this discretion should extend to having a veto at the IESG table when the document and community input is considered (if you make changes I don't like, I'll withdraw my sponsorship). It looks like our process rules don't really cover the case of withdrawing sponsorship, but the existing IESG decision-making process already allows an AD to object to publishing a document, and I believe using a sponsorship-withdrawal-veto instead is inappropriate. I ask you to consider putting this document back on the IESG table, allowing each AD evaluate the document and community input received during the IETF Last Call (and determine the consensus or lack of it), and ballot accordingly. Whatever the outcome is, I strongly believe this is not a decision you should make alone, and doing so would violate the spirit of RFC 2026 and RFC 3710: in Standards Action, the consensus is judged by all Area Directors, not any single person alone. Best regards, Pasi -Original Message- From: ext Sam Hartman [mailto:[EMAIL PROTECTED] Sent: 12 June, 2007 01:57 To: ietf@ietf.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Withdrawing sponsorship of draft-housley-tls-authz-extns Folks, after the various IPR disclosures were filed on draft-housley-tls-authz-extns, I asked for a second IETF last call to see if we had consensus to publish this document on the standards track given the IPR claims against it. That last call did not show the consensus I was looking for. So, we agreed we were going to send mail to the TLS working group and ask them for their comments on publishing the draft. We hoped that we'd see a consensus there. The chairs did ask for comments; see http://www1.ietf.org/mail-archive/web/tls/current/msg01688.html . Comments were provided, but there was not a consensus in favor of publication on the standards track either there or on the ietf list. I think there is a rough consensus against publication on the standards track. However it is quite clear that there is not a rough consensus in favor of publication on the standards track which would be required to do so. So, I am withdrawing my sponsorship of the draft and as far as the IETF process is concerned this draft is no longer under consideration for publication. One option that several people suggested is publication as an informational spec. I personally do not choose to sponsor this document for informational or experimental. often, it seems that we use informational as a way to publish things we cannot build a strong consensus behind. I think that process is generally problematic and would like to avoid it in this instance. Other ADs may consider sponsoring this document as an informational document; I would ask them to carefully consider whether that is the best use of the time they have to offer the IETF community. My conclusion is that for me personally, it is not. Publishing this document via the rfc editor independent submissions track is basically not an option because the IANA assignments require IETF consensus or standards action. That leaves the authors with several options: * Work with people to build consensus and try again later. Possibly working on discovering prior art or trying to revise the licensing terms. There should be a much higher bar for starting the process a second time, but perhaps that bar can be met. * Work on an alternative that does not have the IPR constraints. * Work on finding another AD to sponsor the document. I will not do so, and I'd advise my fellow ADs to think for a long time before taking on this draft, but I would not block another AD sponsoring the draft. * Rewrite this document as a sketch of what might be done rather than a protocol and go through the independent submissions track. * Drop the proposal. I'm sad that we have come to this point. I think this technology has significant value and wish we'd found a way to publish it. However we follow
RE: Last Call Comments on draft-housley-tls-authz-07
Eric Rescorla wrote: My TLS co-chair suggests that this document should go forward as Experimental. I see two problems with that. First: it assigns code points out of a space which is reserved for Standards Action. A correction: the draft needs code points from two different registries (TLS extension types and TLS supplemental data type); both of these registries have at least part of the numbers reserved for IETF Consensus policy. So Standards Action is not needed. (The draft also creates two new registries, but their allocation policies and/or initial assignments could be easily modified at this stage.) snip Given all this, plus the fact that this is squarely a TLS-relevant document, and the IETF norm that it is best when WGs assess the level of IPR involvement and balance that against the important of the work, I think it would be best if this work were brought to the TLS WG, which could decide whether to make it a WG item, in which case the decisions about IPR could be made in the WG. If it clears that bar, then we can have some level of confidence that the IPR issues were judged. If it can't meet that bar, then it probably should not be published at all. I have to disagree with my co-chair here :-) TLS WG should be involved in major technical work related to TLS, but I don't think getting it involved in IPR discussions would be very fruitful. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last call comments about draft-housley-tls-authz-extns-07
Russ Housley wrote: 2) If this was published in a more academic environment, it would be proper (and required) to cite related work, tracing the source of ideas that were not entirely new. We don't usually have extensive citations in RFCs, but in this context, perhaps it would be appropriate to mention the previous proposal for sending ACs in TLS (draft-ietf-tls-attr-cert from 1998) in the Acknowledgements section. This takes a very different approach. Stephen and I co-authored RFC 3281, which is referenced. I do not think that Stephen's ideas about integrating Attribute Certificates into TLS had any impact on the design in the current document. Well, while draft-ietf-tls-attr-cert certainly contains a lot of stuff that isn't in draft-housley-tls-authz-extns (such as AC acquisition, hints about what ACs the client should consider presenting, etc.), there's some overlap as well. For example, a very basic case where the client presents an AC containing a role or security clearance to the server, and the server uses this to determine what the client is authorized to access, is explicitly mentioned in both documents, and would work almost identically. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last call comments about draft-housley-tls-authz-extns-07
1) Given the situation, I would find Experimental a more appropriate status for the document (and it seems that the required IANA assignments can be obtained without being on standards track, so probably no changed would be needed in the document). 2) If this was published in a more academic environment, it would be proper (and required) to cite related work, tracing the source of ideas that were not entirely new. We don't usually have extensive citations in RFCs, but in this context, perhaps it would be appropriate to mention the previous proposal for sending ACs in TLS (draft-ietf-tls-attr-cert from 1998) in the Acknowledgements section. 3) Recent discussions on the TLS WG mailing list pointed out a possible problem in the draft (which it might not be too late to fix): there are some 2-byte length fields, which limit contents to 65535 bytes. That might be plenty for X.509 ACs (although TLS does use three-byte length field for X.509 PKCs), but perhaps not so plenty for SAML assertions. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: what happened to newtrk?
Brian,
Your description of the process omitted the most
time-consuming part:
for {each normative reference}
if {at lower maturity level AND downref acceptable}
then {write justification why downref is acceptable}
else {repeat process recursively to bring reference to DS}
A while ago Tero Kivinen wrote a script for automatically finding
the required documents; according to the script, to bring IPsec to
DS you'd need to upgrade somewhere between 70 and 400 (if I recall
correctly) documents. (The number is fuzzy because older documents
didn't separate normative and informative references. And some of
those references could be justified as acceptable downrefs or
re-classified as informative.)
Whatever the correct figure is (it's anyway dozens of documents),
it's also quite obvious that nobody will ever do the process.
For RFC 2195 (an extension to IMAP), you'd probably need to bring
IMAP to DS first.
Best regards,
Pasi
-Original Message-
From: ext Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: 06 September, 2006 12:57
To: Frank Ellermann
Cc: ietf@ietf.org
Subject: Re: what happened to newtrk?
Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exactly can I do ?
3464 is already DS according to the RFC Index.
For 2195, write and publish an interoperability report, and
if {all mandatory and optional features shown to interoperate}
then {send a request to reclassify RFC 2195 to the IESG}
else {publish a draft-ellermann-2195bis with
non-interoperable features removed};
{send a request to approve it as DS to the IESG}
It's better if you find a willing AD first, and work with him
or her instead of the IESG as group.
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Meetings in other regions
Andy Bierman wrote: Nobody flies from LAX to San Diego because it ends up taking twice as long as driving for 10 times as much, so don't expect lots of flights from LA. For IETF67, I'm leaving home around 6AM, and arrive at LAX some 19 hours later (and fly from LAX to San Diego). After this kind of trip, driving would be dangerous not just to myself, but everyone else on the road as well... (BTW, how much would a taxi from LAX to San Diego cost? And would you expect taxis willing to do it?) - I didn't find a terminal room, but instead a giant 'break room' for ad-hoc meetings and food breaks. This was wonderful, and about time! 802.11 has thankfully made the terminal room obsolete. I want this format every time. Please consider 2 enhancements: - A/C around the perimeter for laptop power - beverages available (at least pitchers of water) all day Good suggestions, I second these! Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Meetings in other regions
John C Klensin wrote: It also means such things as: * picking places within those countries or regions that have good airports with easy (and multiple) international connections. Even San Diego is a little marginal in that regard. Based on experience in the last year or so, I'd suggest that Cape Town and Marrakech (suggested in another posting) should be utterly disqualified (although J-berg and Casablanca are more plausible on this dimension). Some data about San Diego: Today, the flight information page on San Diego International Airport web site shows a couple of flights to/from Mexico and a couple to/from Canada -- all the others are within US. When meeting in North America, I would strongly prefer cities that have several direct flight connections from both Europe and Asia. Of the recent IETF meeting places, San Diego is the only one that clearly fails this criteria... so why are we going there again? Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last call comments for draft-ietf-pki4ipsec-ikecert-profile-10
Couple of comments about draft-ietf-pki4ipsec-ikecert-profile-10, all fairly minor: 1) Section 3.1: Implementations SHOULD populate ID with identity information that is contained within the end-entity certificate [...] The only case where implementations MAY populate ID with information that is not contained in the end-entity certificate is when ID contains the peer source address (a single address, not a subnet or range). The part the only case where implementations MAY [do X] is when [condition] is not consistent with the RFC 2119 definition of MAY (or at least, it's very confusing). Is the intention to say One case where implementatations MAY [do X] is when [condition], or Implementations MUST NOT [do X] unless [condition], or possibly something else? 2) Section 3.1.2 (and also the same text in 3.1.3): However, implementations SHOULD NOT use the DNS to map the FQDN to IP addresses for input into any policy decisions, unless that mapping is known to be secure, for example if DNSSEC [12] were employed for that FQDN. If the FQDN in question is owned by the attacker, then even DNSSEC does not guarantee that the IP address is something that should be used as an input to policy decisions. 3) The profile contains some recommendations about CERTREQ processing that are not fully in line with what IKEv2 recommends. In particular, Section 3.3.7 says that Implementations that receive CERTREQs from a peer which contain only unrecognized Certification Authorities SHOULD NOT continue the exchange. But RFC 4306 Section 3.7 (last paragraph) seems to recommend that if the contains of CERTREQ are not helpful in selecting which certificate to send, its contents should be just ignored. The latter behavior is especially sensible for IKEv2 where the CERTREQ contains hashes of CA public keys (instead of distinguished names), since the peer does not necessarily have those public keys at all (it doesn't need to verify its own certificate, and might be using other trust anchors/other methods that certificates to authenticate the other peer). 4) Also, Section 3.2.7 says that When in-band exchange of certificate keying materials is desired, implementations MUST inform the peer of this by sending at least one CERTREQ. In other words, an implementation which does not send any CERTREQs during an exchange SHOULD NOT expect to receive any CERT payloads. It should be noted that RFC 4306 Sections 3.6 (first paragraph) and 3.7 (first paragraph) recommend sending certificates if available, and suggest that CERTREQ expresses preferences about certification authorities (and sending one would be optional even if CERT payloads are needed for authentication). 5) Section 7.1: The Contents of CERTREQ are not encrypted in IKE. The initiator's CERTREQ is encrypted in IKEv2 (but since it's naturally sent before the initiator has authenticated the responder, this helps only against passive eavesdroppers). 6) Throughout the document: caseless - case-insensitive 7) References: RFCs 2314 and 2535 have been obsoleted by newer RFCs. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last call comments for draft-nystrom-eap-potp-05
I have two substantive comments, and a couple of more minor comments: 1) I am concerned that the document does not give the reader an accurate picture of the security considerations involved when all EAP-POTP exchanges are done without a server-authenticated tunnel (such as PEAP). The problem is that OTPs are typically quite short, and thus a brute-force attack can be feasible, depending on various parameter values. Due to quite complex interaction of salt, pepper, OTP and PIN it's not easy to figure out exactly how the parameter values influence the difficulty of brute-force attacks, and the security claims in Section 6.1 simply say that: Key strength: Depends on size of OTP value, strength of underlying shared secret, strength and characteristics of OTP algorithm, pepper length, iteration count, and whether the method is used within a tunnel such as PEAP. Let's calculate one data point. Assume an RSA SecurID token with PIN input on the token and 6-digit output (this is what I've used at more than one employer). For the iteration count, let's follow Section 4.10.3: The iteration_count value MUST be chosen to provide a suitable level of protection (e.g. at least 2000). The document does not recommend any particular value for the pepper length, except that When pepper is used, it is RECOMMENDED that the length of the pepper and the iteration count are chosen in such a way that it is computationally infeasible/ unattractive for an attacker to brute-force search for the given OTP within lifetime of that OTP. (That was helpful.) However, increasing the (client-selected) pepper length by 10 bits increases the server's work by roughly 1000x. Typical RADIUS servers support thousands of authentications per second, so it's not realistic to assume very long client-selected peppers. (And even if server capacity was not a concern, users would get annoyed if the authentication process took more than a couple of seconds.) Thus, let's assume pepper length of 10 bits. Given these paremeters, it looks like the effective key strength would be roughly 41 bits (log2(10^6)+log2(2000)+10) (+- some small constant to scale to the effort comparable to [..] operations of a typical block cipher scale used in RFC3748). In other words: a completely feasible brute-force search that gives the attacker the MSK (could be used to decrypt captured WLAN traffic) and the SRK (could be used for session resumption). Even though the session lifetime could be quite short (but there's no guidance on how short would be secure enough!), the contents of the WLAN traffic (encrypted using keys derived from the MSK) could be valuable for a long time (several years). While some of these parameters could be larger (say, 8-digit output from token, PIN and iteration count/pepper length leading to 10x more effort), it seems that parameter values large enough to get 128 bit of key strength (as required by RFC 4017) are simply not feasible: while an attacker can spend 2^40 effort on a brute force attack, the real server cannot do that much for each valid authentication. In other words: I believe the document should at least clearly say that when used without a server-authenticated tunnel, and with typical values for client-selected pepper length and iteration count, EAP-POTP is vulnerable to brute-force attacks, and does not provide sufficient key strength to meet the requirements of [RFC4017]. Furthermore, given that in EAP-POTP the key strength depends heavily on user/administrator selected parameters, the document should follow RFC 3748's advice about key strength: The statement SHOULD be accompanied by a short rationale, explaining how this number was derived. This explanation SHOULD include the parameters required to achieve the stated key strength based on current knowledge of the algorithms. Similarly, statements such as If the server did not indicate support for pepper searching, then the PBKDF2 computation MUST be carried out with a sufficiently higher number of iterations so as to compensate for the lack of pepper. do not allow the average reader to determine how high number would be sufficient (and it looks like that without a server-authenticated tunnel, high enough numbers can't be used in practice). 2) The document suggests that some EAP-POTP exchanges can be done inside a server-authenticated tunnel while others could be outside of it (e.g., Section 6.4 initial exchanges with EAP servers SHOULD occur in a secure environment (e.g. in a PEAP tunnel)). This would be extremely unwise if the tunnel method does not support cryptographic binding (e.g., EAP-TTLSv0, PEAPv0, or PEAPv1), as it leads to an easy man-in-the-middle attack. Couple of minor comments: 3) The document would be much easier to understand if it said in the introduction that the basic variant can be
RE: [TLS] Review of draft-housley-tls-authz-extns-05
Russ,
I don't think this is good use of informative text. Other
standards bodies often mark some sections of a specification
as informative, but those sections are text that is helpful
for understanding the specification, but is not required to
implement it.
The KeyNote section is clearly part of the technical specification,
and required reading to get interoperable implementations of this
feature.
Also, my reading of RFC2026 is that the Proposed Standard status
applies to whole documents, and I found nothing there that would
support approving only some specific sections of a document as
Proposed Standard, while leaving other sections as Informational
or Experimental
Best regards,
Pasi
-Original Message-
From: ext Russ Housley [mailto:[EMAIL PROTECTED]
Sent: 23 May, 2006 19:59
To: Eronen Pasi (Nokia-NRC/Helsinki)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: [TLS] Review of draft-housley-tls-authz-extns-05
Pasi:
Steve Kent and Eric Rescorla made similar comments to your
third point:
3) The document is last called for Proposed Standard, but contains
a normative reference to Informational RFC (RFC 2704). I'd
suggest removing the KeyNote stuff from this document (if someone
really wants to do KeyNote, it can be a separate document).
I would like to propose a way forward on this point. It involves
three changes.
First, I suggest a different code point assignment:
enum {
x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
saml_assertion_url(3), keynote_assertion_list(64), (255)
} AuthzDataFormat;
Second, I propose the following text:
3.3.4. KeyNote Assertion List (Informative)
When KeyNoteAssertion List is used, the field contains an ASCII-
encoded list of signed KeyNote assertions, as described
in RFC 2704
[KEYNOTE]. The assertions are separated by two '\n' (newline)
characters. A KeyNote assertion is a structure similar
to a public
key certificate; the main difference is that instead of a binding
between a name and a public key, KeyNote assertions bind
public keys
to authorization rules that are evaluated by the peer
when the sender
later issues specific requests.
When making an authorization decision based on a list of KeyNote
assertions, proper linkage between the KeyNote assertions and the
public key certificate that is transferred in the TLS Certificate
message is needed. Receivers of a KeyNote assertion list should
initialize the ACTION_AUTHORIZER variable to be the
sender's public
key, which was used to authenticate the TLS exchange.
Third, I suggest making the [KEYNOTE] reference informational.
What do you think? Is this a reasonable compromise?
Russ
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Review of draft-housley-tls-authz-extns-05
The part about X.509 attribute certificates looks fine, but at least the SAML part still needs some work: 1) I think the document needs to discuss the security considerations of bearer SAML assertions in more detail. While the countermeasures described in 3.3.2 may help against passive eavesdroppers, they still allow an active MiTM to steal the permission. This is IMHO a significant difference to typical SAML usage with HTTP-over-TLS, where the server is authenticated before the bearer assertion is sent. 2) Section 3.3.2: When SAMLAssertion is used, the field contains XML constructs with a nested structure defined in [SAML1.1][SAML2.0]. This needs to be much more specific than some XML from these documents. What element/elements? Is this an XML document (with XML declaration etc.), or just a fragment? Which encoding? And so on... 3) The document is last called for Proposed Standard, but contains a normative reference to Informational RFC (RFC 2704). I'd suggest removing the KeyNote stuff from this document (if someone really wants to do KeyNote, it can be a separate document). Minor editorial comments: 4) Section 2.3: the list type is AuthorizationDataFormats but enum is spelled AuthzDataFormat. Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard
My personal comments about draft-santesson-tls-ume-01: The draft defines an extension to TLS that allows the client to send user mapping information to the TLS server. The server uses this information to fetch authentication/authorization-related information from a directory server. The draft is quite similar to draft-housley-tls-authz-extns, which allows sending X.509 attribute certificates and SAML assertions in TLS. The main difference seems to be that we only send a pointer to the authorization information (a bit like IKEv2, which supports sending an URL of the certificate instead of the cert itself). From a purely technical point of view, it would probably make sense to merge these drafts. The tls-authz-extns draft does some details better: e.g., the information is sent encrypted, and only after the server has been authenticated. The solution is also quite similar to the client_certificate_url extension defined in RFC 3546 (the User Principal Name could be considered as one type of certificate URL). Here even the placement of the handshake messages is identical to tls-ume. Unfortunately, it seems that sending both CertificateURL and Certificate handshake messages is not allowed, complicating the situation. However, it might be that process and timing issues make mergers infeasible. Also, the authors of draft-santesson-tls-ume seem to be unwilling to make changes to the protocol. About the technical details: In general, the solution seems to work, and does not contain any serious flaws. I don't count sending the user mapping information unencrypted as a serious flaw -- this information is sent only when a client certificate is also sent, and the client certificate is not encrypted either (unless the double-handshake hack is used, in which case the user mapping information would be encrypted, too). It's probably not the most elegant design possible (see e.g. Eric Rescorla's review). However, I think we should clearly distinguish between 'it won't work' and 'it could/should work better' (as Dave Crocker well put it in one email). The document solves a real (but maybe not extremely large or important) problem, and the solution works. That's better than many documents these days... Given these, I think this would be an excellent document for Informational, especially if the title was changed to Microsoft TLS User Mapping Extension to indicate that it's a proprietary extension where the IETF community had no chance to change anything. I also think vendors should be encouraged to publish their extensions, even if they are not perfect. However, due to the IANA allocation rules in 2246bis, this draft is being last called for standards track, and this is slightly more problematic. One observation is that the TLS allocation rules are quite strict, and not always totally logical. Specification Required is sufficient to get a ClientCertificateType number, and IETF Consensus gets you an ExtensionType number. But many extensions (including this one, and also some of the extensions in 3546bis) also require a handshake message number, and thus Standards Track. Or in other words: the degree of consensus and process required for a document that extends TLS depends heavily on minor technical details, not on what the extension actually does. RFC 2026 also says that A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. I don't think we're quite there yet with this document. On the other hand, I also think that just refusing to publish this document would be a highly unproductive approach. If the document solves a reasonable problem, the solution works, and it looks likely it will be widely deployed, I don't think preventing publication on minor process details would exactly make the Internet work better. I'm not sure what would be the best way to handle this, though. Merge this with draft-housley-tls-authz-extns? Refine the technical details so that it does not need a new handshake message number? (E.g., map the UPN to an URL, and use the existing CertificateURL message?) Change the IANA allocation rules for TLS? I don't have a strong opinion here... Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'TLS User Mapping Extension' to Proposed Standard
Bill Strahm wrote: I saw all of the huff, and while I agree with it, I am more concerned about Appendix A. IPR Disclosure TBD What does that mean, and more specifically is a document with a TBD section really ready for last call at all ? RFC 3979 Section 11 title says it all: No IPR Disclosures in IETF Documents -- so this section needs to be removed. But the TBD part probably means the authors were in the process of finding out exactly where and how IPRs should be disclosed. It looks like they've now figured it out: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=688 Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
