Re: review of draft-sheffer-emu-eap-eke-06
Dan Harkins dhark...@lounge.org writes: Hi Simon, On Mon, May 3, 2010 3:32 pm, Simon Josefsson wrote: Dan Harkins dhark...@lounge.org writes: Issues with prf and prf+ - In sections 5.1 and 5.2 the password is passed directly into prf+ (which is the same as the one from RFC 2409 and uses HMAC-SHA1 or HMAC-SHA256). This is a key derivation type function and assumes it has been passed a key having properties, like a uniformly random distribution, that a low-entropy password does not have. I recommend deriving a key for Encr() in a 2-step process using and extractor and expander KDF. It might also be good to mention that the first, leftmost, length-of-cipher-key bits are used as the cipher key. I agree with your comments. However would not salting and an iterative design, as provided by PKCS#5 PBKDF2, be more appropriate than extract-and-expand? See section 4 of the extract-and-expand document to see why it is not always appropriate for passwords. I don't believe so. PBKDF2 does 1000 iterations of HMAC-ing to increase the work factor of brute force guessing the password. This is useful when the protocol using the password is not based on a zero knowledge proof. In this case it is, and an active attacker gets only one guess at the password per attack (a passive attacker gets zero guesses) and that would be the case even if the password is used directly as a key to an HMAC-based KDF. Section 4 of the extract-and-expand document says, In the case of password-based KDFs, a main goal is to slow down dictionary attacks using two ingredients: a salt value and the intentional slowing of the key derivation computation. HKDF naturally accommodates the use of salt; however, a slowing down mechanism is not part of this specification. But in the case of EAP-EKE a dictionary attack is foiled outright by the protocol. There is no need to use a KDF to slow one down. Right. I agree. Issues with elliptic curves cryptography This raises a question. What is the patent status of the technologies used by this document? I recall concerns with some non-HMAC-based password based authentication protocols. I believe it has been submitted: https://datatracker.ietf.org/ipr/1071/ Thanks for the pointer. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: review of draft-sheffer-emu-eap-eke-06
Hi Simon, to answer your last point: EKE is patented, see https://datatracker.ietf.org/ipr/1071/. The patent is due to expire on October of next year. This is (obviously) unrelated to any elliptic curve patents. Thanks, Yaron Thanks, Yaron On 05/04/2010 01:32 AM, Simon Josefsson wrote: Dan Harkinsdhark...@lounge.org writes: Issues with prf and prf+ - In sections 5.1 and 5.2 the password is passed directly into prf+ (which is the same as the one from RFC 2409 and uses HMAC-SHA1 or HMAC-SHA256). This is a key derivation type function and assumes it has been passed a key having properties, like a uniformly random distribution, that a low-entropy password does not have. I recommend deriving a key for Encr() in a 2-step process using and extractor and expander KDF. It might also be good to mention that the first, leftmost, length-of-cipher-key bits are used as the cipher key. I agree with your comments. However would not salting and an iterative design, as provided by PKCS#5 PBKDF2, be more appropriate than extract-and-expand? See section 4 of the extract-and-expand document to see why it is not always appropriate for passwords. - Section 5.1 says If the password is non-ASCII, it SHOULD be normalized by the sender before the EAP-EKE message is constructed. The normalization method is SASLprep, [RFC4013]. Note that the password is not null-terminated. I don't think this will work. The SHOULD should be a MUST and the mention of SASLprep should use normative language-- i.e. it MUST be SASLprep. Is there a mandatory-to-implement format? Is support for ASCII a MUST? Also, there's no mention of unassigned code points? What happens if one of these is hit during normalization? I don't believe the text as written will assure interoperability and it will also be a DISCUSS target, said using the voice of experience :-) I agree strongly with this comment as well. Issues with elliptic curves cryptography This raises a question. What is the patent status of the technologies used by this document? I recall concerns with some non-HMAC-based password based authentication protocols. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard
On 03/May/10 22:26, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Authentication-Results Registration For Differentiating Among Cryptographic Results ' draft-kucherawy-authres-header-b-01.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 2010-05-31. The I-D identifies a possible result forgery (section 6.2). Although I haven't fully grasped the reasons why such attack would be attempted, I think that condition is a case where the spoofed signature SHOULD be removed by the verifier. I'm not sure the latter spec would be an update of rfc 4871, since it says /Signers/ SHOULD NOT remove any DKIM-Signature header field [emphasis added]. (Other cases where signatures might be removed --mailing lists-- are currently being discussed on ietf-dkim.) For a minor point, the example (A.1) the I-D makes does not illustrate the reason for introducing header.b. The exemplified signatures can already be distinguished by their header.i values. By setting that attribute also in this case, the example conveys the impression that header.b should not be omitted, even when it is unnecessary. If that's the intended meaning, it should be stated more explicitly, IMHO. OTOH, the example shows a case where a signature had been validated before being broken (discussed on ietf-dkim and [1]). However, that is apparently the only part of the I-D discussing such topic. -- [1] http://mipassoc.org/pipermail/mail-vet-discuss/2010q2/000602.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
[Gen-art] Gen-art review of draft-ietf-ipsecme-ikev2bis-08.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-ipsecme-ikev2bis-10.txt Reviewer: Elwyn Davies Review Date: 4 May 2010 IETF LC End Date: 18 March 2010 IESG Telechat date: 6 May 2010 Summary: When I reviewed this document at IETF Last call, I discovered that compared to previous documents, it contains no mention of mandatory to implement ciphersuites. In a discussion with Paul Hoffmann, I was pointed at various other RFCs that specify ciphersuites, and informed that the IESG and WG had approved the current situation. However it seems to me that somebody looking at the IKE documents would be likely to come to this document first and would find it difficult to locate the auxiliary documents without considerable effort (and risk of missing some). I continue to believe that f there is not to be a list of appropriate ciphersuites here, there needs to be some pointers to places to look. A number of my comments have been implemented, but there are quite a few that I have seen no response to amd have not been implemented. The list below represents the remaining comments. I have left in a number of comments regarding the cut off time (publication date of RFC 3406) for updating of registration tables. It strikes me that it would be relatively little work and quite helpful to bring these tables up to date. There are also a number of relatively minor points where items and processes are explicitly not fully specified. Thus could lead to annoying corners where implementations are totally interoperable (e.g., what is the complete set of 'terminators' forbidden in IP_FQDNs? What is an acceptable 'sort of' email address/NAI on EAP?) Finally there are a number of points where it is recommended that network traffic needs to be limited but no concrete guidelines are given. I think that some sort of suggestions for the parameters to be applied (e.g., time constants, number of repeats, backoff algorithm) would be desirable. Major issues: s3.3.4: The draft states that the list of mandatory to implement suites has been removed due to evolution going too fast. However there are effectively some mandatory to implement suites; they are listed in other documents. There should be a way of finding them so that users and implmenters can find them easily. Minor issues: s1: At para 6 in s1 the draft states: The first request/response of an IKE session (IKE_SA_INIT) negotiates security parameters for the IKE SA, sends nonces, and sends Diffie- Hellman values. As a (not really) naive reader, I asked myself 'Why does this text suddenly mention that we need to send nonces and Diffie-Hellman values?' Looking back at the text so far I realized that the text has not introduced the techniques that it is going to use to establish the authenticated IKE channel etc. It is assumed that readers know that as soon as D-H is mentioned we are talking public key cryptography. A paragraph explaining the underlying ideas would be useful. s1.2, last para: Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with any value other than NONE. Implementations SHOULD omit the whole transform substructure instead of sending value NONE. Does 'cannot contain' conflict with the 'SHOULD'? I am unclear what an implementer would do if s/he chose to do otherwise than omit the transform structure in the light of the previous statement. s2.1, last sentence: The retransmission policy for one-way messages is somewhat different from that for regular messages. Because no acknowledgement is ever sent, there is no reason to gratuitously retransmit one-way messages. Given that all these messages are errors, it makes sense to send them only once per offending packet, and only retransmit if further offending packets are received. Still, it also makes sense to limit retransmissions of such error messages. Does this need to be more precise? Some explicit policy for restricting retransmissions? Possibly in s2.21.4. s2.3: Should there be some discussion of the interaction of rekeying of the IKE_SA and windows? Presumably a rekey message should not be actioned until all previous messages have been responded to. Likewise receiving a Message ID with a sequence number bigger than that in the rekey message should be very suspect! Should the INVALID_MESSAGE_ID notification be sent in this case (and before or after the rekey?) There might be some knock on into s2.8 where rekeying is discussed. And maybe into s2.25? s2.4, para 2: The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request or response, not as a
Re: Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC
Hello folks, Here is a first installment of comments on the abovementioned Internet Draft. The list is not meant to be exhaustive. Moreover, this document presents and identifies all issues pertained to these scenarios and discusses possible means and mechanisms that are recommended to enable them. These two sentences clash, even though it's true a logician can make sense of them. Figure 2 is out of order. The captions to all figures ought to be centered. The following figure illustrates an example following figure -- Figure 3 below of this scenario, where the MN is moving from an access network where PMIPv6 is supported (i.e. MAG functionality is supported) to a network where PMIPv6 is not supported (i.e. MAG functionality is not supported by the AR). This implies that the home link of the MN is actually a PMIPv6 domain. It's true that the figure is drawn this way, but there might be an unwanted inference that such heterogeneous network support _always_ requires PMIP support in the home network. I reckon that was not intended. This scenario is very similar to other hierarchical mobility schemes, including a HMIPv6-MIPv6 scheme. Please make the relevant citations. Note that a race condition where the MN registers the CoA at the HA before the CoA is actually bound to the MAG at the LMA is not possible. Better: Note that there is no race condition whereby the MN registers the CoA at the HA before the CoA is actually bound to the MAG at the LMA. In particular, based on the base specification [RFC3775], Better: In particular, based on [RFC3775], Or, even better: In particular, the base specification [RFC3775] doesn't require the MN to include any identifier, such as the MN-ID [RFC4283], in the Binding Update message other than its Home Address. As described in [RFC4877], the identifier of the MN is known by the Home Agent after the IKEv2 exchange, but this is not used in the MIPv6 signaling, nor as a lookup key for the binding cache. Which naturally leads to the question, Why Not?! This is a problem that really needs to be fixed. Therefore PMIPv6 and MIPv6 will always create two different binding cache entries in the HA/ LMA which implies that the HA and LMA are logically separated. I think this statement is too strong. If I were building such a system, my HA/LMA would probably be aware that the MN-ID was tightly bound to the MN-HoA. So I would almost certainly make sure that there was a single binding cache entry. If you replace will always by might well, and are by might be, then I would agree. Also, it's unfortunate if the typography separates HA from LMA in HA/LMA. * When the mobile node moves from a MIPv6 foreign network to the PMIPv6 home domain, the MAG registers the mobile node at the LMA by sending a Proxy Binding Update. Subsequently, the LMA updates the mobile node's binding cache entry with the MAG address and the MAG emulates the mobile node's home link. Upon detection of the home link, the mobile node will send a de-registration Binding Update to its home agent. It is necessary to make sure that the de-registration of the MIPv6 BU does not change the PMIPv6 binding cache entry just created by the MAG. To me this looks like a major design flaw. It would be better if the mobile node were aware that its registration authority was delegated to the MAG on the home link. Then it would know to avoid this problem. Stated another way, this would be a requirement induced by PMIP on MIPv6-compliant nodes. Asking the obvious, one wonders why an operator of a home network would a) assume that the nodes were MIPv6-unaware, necessitating a PMIP solution, and yet b) assume that the nodes might be MIPv6-aware, so that there is danger of conflict with a PMIP solution. What am I missing? * MIPv6 and PMIPv6 use different mechanisms for handling re- ordering of registration messages and they are sent by different entities. Looks like another design flaw to me. If the HA/LMA is aware of MIPv6 sequence numbers (i.e., actually _is_ a HA), why not require the MAG to _use_ sequence numbers? This would be a trivial matter of inclusion into the PBA. (or binging cache) -- (or binding cache) :-) thanks, I needed that :-) :-) in fact, I need more $$ for my binges :-) * In this mixed scenario, both host-based and network-based security associations are used to update the same binding
Re: Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC
Hello folks, Here are the rest of my comments on the abovementioned Internet Draft. For this reason, it is recommended that when the MIPv6 home link is implemented as a PMIPv6 domain, the HA/LMA implementation treats the two protocol as independent. Why not first recommend that the HA/LMA implement some platform-specific mechanism for identifying the alternate identifiers (e.g., MN-ID and MN-HoA)? More in details the following principles ... -- In more detail, the following principles ... ... The mobile node needs to bootstrap -- ... The mobile node may need to bootstrap service continuity. Therefore the following steps must be performed by the UE: -- service continuity. Therefore the following steps might be performed by the MN: In the following steps one and two: needs to -- may need to In step three: assign -- may assign Since all these steps must -- If all these steps must that the mobile node establishes -- that the mobile node establish or, better: it is recommended that the mobile node establishes -- the mobile node SHOULD establish along with a little rewording of the next subordinate clause. has Mobile IPv6 stack active -- continues to make use of Mobile IPv6 as if it is attached -- as if it were attached -- BUT: in the scenario under discussion, isn't it? [boot-integrated]: This citation needs to be updated; and, apparently it now has a distinguished author as well as an editor. But, it's been in the RFC editor's queue for TWO YEARS?! That's a new one on me. MN-HoA.For -- MN-HoA. For is this a bug in xml2rfc? For this reason, the mobile node must be configured to propose MN-HoA as the home address in the IKEv2 INTERNAL_IP6_ADDRESS attribute during the IKEv2 exchange with the HA/LMA. I think this qualifies as another requirement placed by PMIP on MIPv6 nodes. Maybe it would be a good idea to make a new section and list these requirements newly placed by PMIP. I'm starting to wonder whether these new mandates might belong in rfc3775bis. When the mobile node hands over -- When the mobile node migrates to basestations perform handovers, not mobile nodes The mobile node may set the R bit defined in NEMO specification a) citation required for NEMO specification b) NEMO specification -- the NEMO specification c) _ouch_! Now we have a new mandate placed by PMIP onto NEMO.! is created irrespective -- may be created regardless I think it is unwise to prohibit implementers from coordinating the binding cache entries of PMIP and MIPv6 if they serve the same mobile node, as I have mentioned earlier In this section it is assumed -- In this section we consider the case where 4.3. Solutions related to scenario B This conflicts with the sentence in section 1: this document presents and identifies all issues pertained to these scenarios and discusses possible means and mechanisms that are recommended to enable them. On 5/3/2010 7:24 AM, The IESG wrote: The IESG has received a request from the Network-based Localized Mobility Management WG (netlmm) to consider the following document: - 'Interactions between PMIPv6 and MIPv6: scenarios and related issues ' draft-ietf-netlmm-mip-interactions-05.txt as an Informational RFC 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 2010-05-17. Exceptionally, comments may be sent to i...@ietf.org 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-netlmm-mip-interactions-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17831rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Maastricht IETF Codesprint
Maastricht IETF Codesprint When: 24 July 2010 beginning at 9:30 AM Where: IETF Hotel What: A bunch of hackers get together to work on code for the IETF. Some people may be preparing for the transition to a new database schema; some people may be preparing for the upcoming extensions to support working groups; some people may be adding exciting new functionality. All code will become part of the open source IETF tools. How: See http://tools.ietf.org/tools/ietfdb/wiki/IETFSprintHowto Who: Hopefully you can help Many of the results of previous codesprint activities are being used every day by the IETF community. Steve Conte will be helping with advance planning. Henrik Levkowetz will be coordinating the event in Maastricht. More information is available at: http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF78Sprint If you are able to participate, please sign up on the wiki at: http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF78SprintSignUp Please support the tools development effort, Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alessandro Vesely Sent: Tuesday, May 04, 2010 2:46 AM To: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard For a minor point, the example (A.1) the I-D makes does not illustrate the reason for introducing header.b. The exemplified signatures can already be distinguished by their header.i values. By setting that attribute also in this case, the example conveys the impression that header.b should not be omitted, even when it is unnecessary. If that's the intended meaning, it should be stated more explicitly, IMHO. Thanks, that was an oversight on my part. I'll correct it in the next version. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
Has anyone bother by Dean considered using filters as a means of dealing with this? Joe On Mon, May 3, 2010 at 2:21 PM, todd glassey tglas...@earthlink.net wrote: On 5/3/2010 11:06 AM, Arnt Gulbrandsen wrote: On 05/03/2010 07:48 PM, todd glassey wrote: Maybe Joe but I do not want to be a party to his mailing lists, and he will not allow me off of them, so I have no choice but to file the spam compliant. I direct your attention to the IETF's standard for unilateral list unsubscription, RFC 5228 as extended by RFC 5429. Arnt These are extensions for Sendmail. The problem is that Dean created a list outside of the IETF and subscribed IETF members to it. The members have NO passwords and cant get them without interacting with Dean making this harassment. As to whether the IETF postings are commercial or not they clearly are since they are work on standards for commercial networking. Todd Dean subscribed me too, but I had forgotten about it until just now. Arnt ___ 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 -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: http://baptista.cynikal.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
