RE: Gen-ART Review of draft-ietf-smime-sha2-03.txt
Spencer, Thanks for taking the time to read the draft. Responses are inline. spt -Original Message- From: Spencer Dawkins [mailto:[EMAIL PROTECTED] Sent: Friday, February 29, 2008 12:27 AM To: General Area Review Team Cc: Sean Turner; Blake Ramsdell; ietf@ietf.org; [EMAIL PROTECTED] Subject: Gen-ART Review of draft-ietf-smime-sha2-03.txt 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. Will do. Document: draft-ietf-smime-sha2-03.txt Reviewer: Spencer Dawkins Review Date: 2008 02 28 IETF LC End Date: 2008-03-07 IESG Telechat date: (if known) Summary: This document isn't ready for publication as a Proposed Standard - it's got enough cut-and-paste errors and apparently-omitted text that I'd think twice about trying to implement it. And if it has a note that says normative reference still in progress, should be brought in line with normative reference before publishing as an RFC, I'm not sure why it's being last called now (of course, that decision is above my pay grade). Wrt the reference, that draft is being worked in PKIX. Hopefully, it will progress quickly - I'm hoping for this summer (or sooner) for it to complete WG LC and IETF LC. Also, the reference is for object identifiers all of which were assigned years ago and are stable. Comments: Please include any nits listed in http://www.ietf.org/mail-archive/web/ietf/current/msg50518.html that I may have missed in this review, by reference :-( Will do. When one of the last call comments is There are obvious errors (intentionnaly left by the editor in order to know how many people read the document), this does not inspire confidence. I note there is no shepherd writeup in the tracker yet. The of for typo below has been in every version since 00. Who else has read this draft? This was, I believe, his attempt at humor. See my response to Denis' email. Abstract This document describes the conventions for using the message digest algorithms SHA-224, SHA-256, SHA-384, SHA-512, as defined in FIPS Nit - I'm not sure what passes for normal in security drafts, but I'd expect to see SHA and FIPS expanded on first use in the abstract, and in the introduction of the document. Ditto for DSA, RSA, and ECDSA. I will expand the acronyms. 180-3, with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with CMS and the DSA, RSA, and ECDSA signature algorithms. Conventions used in this document Nit - it is odd to see this section as part of the abstract... For some reason the tool picks up this section as part of the abstract. It's got a heading title so I don't think it's in the abstract. 1. Introduction This document specifies the algorithm identifiers and specifies parameters for the message digest algorithms SHA-224, SHA-256, SHA- 384, and SHA-512 for use with the Cryptographic Message Syntax (CMS) [RFC3852]. The message digest algorithms are defined in and [SHS]. Concern: in and seems to be missing something. Denis caught this too. Will fix by removing the and. If an implementation chooses to support one of the algorithms discussed in this document, then the implementation MUST do so as described in this document. Concern: this MUST (and the parallel MUST in the next paragraph) seem odd - do you need to say this? Hmmm ... I guess not. I'll remove both sentences. Note that [RFC4231] specifies the conventions for use of for the Concern: of for seems to be missing something. I will remove for use of so the sentence will read: Note that [RFC4231] specifies the conventions for the message authentication code (MAC) algorithms message authentication code (MAC) algorithms: HMAC with SHA-224, HMAC with SHA-256, HMAC with SHA-384, and HMAC with SHA-512. 2. Message Digest Algorithms The following addresses the parameters field: Nit - this sentence isn't clear and isn't required. I'd strike it. Removed. There are two possible encodings for the SHA AlgorithmIdentifier parameters field. The two alternatives arise from the fact that when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. Later the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations encode parameters as a NULL element and others omit them entirely. The correct encoding is to omit the parameters field; however, implementations MUST also handle a SHA AlgorithmIdentifier parameters field which contains a NULL. Nit - I'd describe the normative behavior, and then provide the history (in a
Gen-ART review of draft-ietf-sipping-pending-additions-04.txt
Gonzalo, 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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sipping-pending-additions-04.txt Reviewer: David L. Black Review Date: 29 February 2008 IESG Telechat date: 06 March 2008 Summary: This draft is on the right track, but has open issues, described in the review. Comments: The following two issues noted the Gen-ART review of the -03 version of this draft do not appear to have been addressed in the -04 version. [1] 5.1.2. SUBSCRIBE Bodies A SUBSCRIBE for Pending Additions events MAY contain a body. This body would serve the purpose of filtering the subscription. The definition of such a body is outside the scope of this specification. How is that supposed to be interoperable? A better approach would be to prohibit bodies now and allow a future specification to define them. [2] 5.1.7. Subscriber Processing of NOTIFY Requests NOTIFY requests contain full state. The subscriber does not need to perform any type of information aggregation. This text doesn't explain the process followed by the subscriber upon receipt of a NOTIFY request, including any logic required to form a coherent resource state (if applicable) (see Section 4.4.8 of RFC 3265). This text needs to be rewritten and expanded. The -04 draft addresses the partial notification case, but not the full notification case, unless Section 6.2 was intended to cover all notification processing, in which case it has the wrong title. idnits 2.08.04 ran clean aside from finding a couple of referenced Internet-Drafts that have revised versions. The RFC Editor will remove the version numbers in any case, so it's not important to correct them. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-smime-sha2 (Using SHA2 Algorithms withCryptographic Message Syntax) to Proposed Standard
Denis, Thanks for taking the time to review this ID. Responses are inline. spt -Original Message- There are obvious errors (intentionnaly left by the editor in order to know how many people read the document). If I was going to leave something intentionally in the document to see if you'd read it, then it would have been a lot better ... something like (note this isn't an actual offer) if you mention this sentence to me I'll buy you a beer. This ID is way too short to sneak in this kind of phrase. On page 1: The message digest algorithms are defined in and [SHS]. ^^^ Also in section 2.4: Will remove the and. 2.4. SHA-512 The SHA-256 message digest algorithm is defined in [SHS]. whereas it should be: 2.4. SHA-512 The SHA-512 message digest algorithm is defined in [SHS]. Will replace SHA-256 with SHA-512 in 2.4. It would be valuable to explain why DSA cannot be used with SHA-384 and SHA-512. I'll add some text. In addition, it is not acceptable to reference in the *normative* references work in progess, i.e.[ECCADD]. I'm pretty sure this is done all the time. There are 17 IDs in the RFC editor queue with works-in-progress in normative references. The same applies for [SHS]. The text states: NOTE [to be removed upon publication as an RFC]: NIST has not yet finalized FIPS 186-3 and there is a chance that the draft may be changed. This may result in differences between what is documented in the current version of this document and what is in the FIPS. It is intended to synchronize the final version of this draft with the FIPS before publication as an RFC. The FIPS PUB 186-3 part that this ID needs has very little chance of changing. The WG wanted this note to be safe. There is a more substantive comment on the first paragraph of section 1. The text states: If an implementation chooses to support one of the algorithms discussed in this document, then the implementation MUST do so as described in this document. I believe the text should be: If an implementation chooses to support one of the algorithms discussed in this document, then the implementation MUST do so as described in [SHS]. The algorithms aren't defined in this document only the OIDs and where they go in CMS ... so I still think it's actually as described in this document. But, Spencer suggests removing the sentences because they're not needed and I tend to agree with him. A small discussion in the security considerations section on the advantages (in particular in terms of performances versus security) of using one or another function from the SHA2 family would be helpful. I'll see if I can't get something from NIST (or at least point to it). While I welcome this draft, everybody should take into consideration that, if the SHA2 family happens to be broken then we will be at risk. This should be mentioned into the security considerations section. If an algorithm is cracked then isn't it obvious that we're in trouble? No other algorithm document I could find says something like this so I'm inclined to not include this in the security considerations section. The NESSIE program has evaluated with succces the WHIRLPOOL algorithm. WHIRLPOOL would be a good substitute to SHA-512 and I would encourage that someone drafts an RFC to specify OIDs for using WHIRLPOOL with CMS. Denis The IESG has received a request from the S/MIME Mail Security WG (smime) to consider the following document: - 'Using SHA2 Algorithms with Cryptographic Message Syntax ' draft-ietf-smime-sha2-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-03-07. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_iddTag =16033rfc_flag=0 Regards, Denis Pinkas ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-netlmm-proxymip6-11.txt
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-netlmm-proxymip6-11.txt Reviewer: Elwyn Davies Review Date: 29 Feb 2008 IESG Telechat date: 06 March 2008 Summary: Version 11 resolves almost all of the issues and nits that I raised in the last call review of version 10. There is one editorial matter to complete the 'ease of reading' and an outstanding query which I think both I and the authors passed over a little lightly at the previous review. An editorial update added to s3, para 4 (just after fig 1) to emphasize the pivotal role of the MN-Identity would be helpful. Something like: 'The authenticated, stable identifier of the mobile node (MN-Identifier) uniquely identifies the mobile node to the LMA(s) as the node roams through the Proxy Mobile Domain.' Outstanding query: s6.1, bullet 2: This bullet refers to '*the* interface identifier' and suggests that it might be retrieved from a Router Solicitation. My original point was that the IID for IPv6 addresses is not necessarily common between the addresses configured on an interface. My comment was a little glib and the authors glossed over the point in their reply. I think this bullet may require clarification to indicate which of the IIDs would be implied here. Particularly if SEND is in use, the IID used for the link local address (that would typically be found in the solicitation) will a.s. differ from the IID used with the address assigned out of the prefix allocated by Proxy MIP. My original point was to ask the authors to clarify whether ProxyMIP actually cares which IID is used and, accordingly, state either that 'it doesn't matter' or specifically which IID should be transmitted. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-smime-sha2 (Using SHA2 Algorithms withCryptographic Message Syntax) to Proposed Standard
At 4:06 PM -0500 2/29/08, Turner, Sean P. wrote: In addition, it is not acceptable to reference in the *normative* references work in progess, i.e.[ECCADD]. I'm pretty sure this is done all the time. There are 17 IDs in the RFC editor queue with works-in-progress in normative references. Sean is correct. This will cause the draft to be stuck in the RFC Editor publication queue until the other document becomes an RFC, but there is absolutely nothing wrong with this in a last-call draft. The same applies for [SHS]. The text states: NOTE [to be removed upon publication as an RFC]: NIST has not yet finalized FIPS 186-3 and there is a chance that the draft may be changed. This may result in differences between what is documented in the current version of this document and what is in the FIPS. It is intended to synchronize the final version of this draft with the FIPS before publication as an RFC. The FIPS PUB 186-3 part that this ID needs has very little chance of changing. The WG wanted this note to be safe. Again, Sean is right. It is quite common to have comments like This section to be removed upon publication in documents going into the RFC Editor queue. There is a more substantive comment on the first paragraph of section 1. The text states: If an implementation chooses to support one of the algorithms discussed in this document, then the implementation MUST do so as described in this document. I believe the text should be: If an implementation chooses to support one of the algorithms discussed in this document, then the implementation MUST do so as described in [SHS]. The algorithms aren't defined in this document only the OIDs and where they go in CMS ... so I still think it's actually as described in this document. But, Spencer suggests removing the sentences because they're not needed and I tend to agree with him. Spencer wins on this one. The sentence doesn't make much sense in a standards-track document. A small discussion in the security considerations section on the advantages (in particular in terms of performances versus security) of using one or another function from the SHA2 family would be helpful. I'll see if I can't get something from NIST (or at least point to it). I'll disagree with this. These are not security considerations; they are performance considerations. And pretty obvious ones at that. While I welcome this draft, everybody should take into consideration that, if the SHA2 family happens to be broken then we will be at risk. This should be mentioned into the security considerations section. If an algorithm is cracked then isn't it obvious that we're in trouble? No other algorithm document I could find says something like this so I'm inclined to not include this in the security considerations section. ... or anywhere else. If any algorithm (hash, encryption, signing, ...) is broken, it is broken. Sean's right here. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Discussion about Federated Roaming
Hello! My name is Stefan Winter of the National Research and Education Network in Luxembourg, RESTENA. We are an ISP for academia and take the lead in research and development of a global academic wireless LAN federated roaming consortium: eduroam. This is based on EAP and 802.1X exclusively. In the course of development, prototyping and rollout of eduroam, we have discovered that some areas of the relevant standards required some tweaking or workarounds. After following IETF work for some time, we also saw that some of the efforts exclude roaming use cases from their agenda. So far I've heard that we are by far the biggest federated 802.1X roaming consortium at all, and I wonder if we are the only ones seeing some items that could use a second thought when considering roaming between independent administrative domains. I will be at IETF71, and would like to invite anyone who is interested in federated roaming scenarios for an informal get-together to exchange ideas. I was planning to do this on Monday evening, at a location that is still TBD, I'll follow up. Below I've put together the most prominent items that are on our radar right now to give you a glimpse of the issues we in eduroam are dealing with. The most prominent issue is the uneasy fact that RADIUS doesn't provide a reliable transport and only basic security, while Diameter has no implementations and NAS support in the wireless LAN area. With an EAP conversation requiring multiple, usually around eight, roundtrips, and a packet path that may literally span the whole world, this is a major concern. It also didn't particularly help that in a recent discussion on dime, it was stated that Diameter doesn't offer significant advances regarding roaming compared to RADIUS. We tried to mitigate this by proposing RadSec, RADIUS over TCP+TLS [1], and are pursuing this in the radext wg right now. Another thing is that we have no sufficient signalling mechanism to reach the end user if the 802.1X login couldn't be completed because of an intermediary RADIUS proxy being down - due to the lack of possibility to provide error messages in the 802.1X protocol, most supplicants provide the unhelpful advice that Probably the password is wrong, which is wrong and generates user frustration. Some kind of hijacking the EAP conversation by the last responsive proxy to inject EAP-Notifications would be needed probably, but this is not thought through in its entirety yet. I'm aware that there is a security argument: not disclosing the reason for a failure may make attacks more difficult, but still: it would then be desirable to at least have the *option* of providing the info - right now it is impossible. Then, encapsulating EAP in RADIUS may sometimes lead to RADIUS packets being so big that they have to be fragmented - not a conceptual problem, but a practical one, because out-of-order fragements, or even even in-order UDP fragments generate problems on unclever firewalls more often than not. Especially EAP-TLS, where both server and supplicant need to send large amounts of (certificate) data turned out to be a real challenge. A draft about that problem and a sketch of a possible solution is in the works. Another thing that bugged us about RADIUS is the inability to contact new auth servers on the fly, for example when a new user realm is observed. So far, we stacked together RADIUS servers in a realm-based aggregation hierarchy. A better approach, in combination with the TCP+TLS nature of RadSec, would be to use a dynamic lookup mechanism (e.g. DNS NAPTR/SRV) that allows to discover the authoritative home server for a user's realm and to verify that server's eligibility by examining the certificate. This is a concept we will try out in semi-production use in eduroam soon, but it may have implications also out of the eduroam community, since it will allow arbitrary service providers to create an authentication fabric very easily on the technical side - making the *paperwork* of bootstrapping a roaming consortium the only big challenge. We have been looking at the work of the NEA wg with a bit of concern, since its charter excludes the federated roaming case deliberately. For example, putting posture information into EAP will always convey the posture info to the home server, while it is the service provider that needs the posture information to make its admission decision. We understand though that there is work going on to make the use of NEA roaming-agnostic, which we would very much like to see. Finally, there is a more exotic area in connection to roaming scenarios: converging roaming on the network layer (802.1X+EAP) with Single-Sign On on the application layer (SAML et al), with the ultimate goal that using a set of credentials to log into the network also generates an application layer token to use for signing into services - without the need to re-authenticate. I realise that some of the
Correction: Impending publication: draft-iab-dns-choices-05
I managed to sneak in two errors: 1. a February 23 deadline, that should have been March 28 2. a link to version 03 of the document, that should have been 05. For completeness: The IAB is ready to ask the RFC-Editor to publish Design Choices When Expanding DNS draft-iab-dns-choices-05 as an Informational RFC. This document provides a number of considerations to assist application and protocol designers in choosing a mechanism to store and retrieve data in the DNS. It treats, among other things the pros and cons of using TXT records, and of adding prefixes or suffixes to owner names. It argues that adding a new Resource Record is the best solution to add new data to the DNS and that the use of TXT Resource Records is the worst. The IAB solicits comments by March 28, 2008. Please send comments to the IAB ([EMAIL PROTECTED]), or to [EMAIL PROTECTED] The document can be found at http://www.ietf.org/internet-drafts/draft-iab-dns-choices-05.txt From the Abstract: This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. Olaf Kolkman, For the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
