Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth-03
Is the following text for the entire section 2.4 OK for you? (I've borrowed some of your text): Looks mostly ok. 2.4. Interaction with Peer Authorization Database (PAD) Section 4.4.3 of [RFC4301] defines the Peer Authorization Database (PAD), which provides the link between Security Policy Database (SPD) and the IKEv2. The PAD contains an ordered list of records, with peers' identities along with corresponding authentication data and Child SA authorization data. When the IKE SA is being established the PAD is consulted to determine how the peer should be authenticated and what Child SAs it is authorized to create. When using NULL Authentication, the peer identity is not authenticated and cannot be trusted. If ID_NULL is used with NULL Authentication, there is no ID at all. The processing of PAD described in Section 4.4.3.4 of [RFC4301] must be updated. The NULL authentication needs to be added as one of supported authentication methods. This method MUST contain no authentication data. I do not understand why there is MUST NOT for authentication data. Yes, there is no authentication data, but that is not really something that needs to be enforced in MUST level. Perhaps just change This method MUST contain no authentication data. to The NULL authenticaiton method does not have any authentication data. or similar. OK. To add support for ID_NULL, it needs to be included into the list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The matching rule for ID_NULL is just whether this type is used, i.e. no actual ID matching is done, as ID_NULL contains no identity data. Section 4.4.3.3 of the [RFC4301] describes how the IKE ID is matched against the SPD entries. When using the NULL authentication method those matching rules MUST include matching of a flag in the SPD entry ^ change "a flag" to "a new flag", so it clearly indicates we are talking about something that is modified in the RFC4301, not something that already is there. Done. specifying whether unauthenticated users are allowed to use that entry. I.e. each SPD entry needs to be augmented to have flag specifying whether it can be used with NULL authentication or not, and only those rules explictly having that flag turned on can be used with unauthenticated connections. I wonder should we explitly mention something about dangers which can happen if this flag is not implemented properly, i.e. because the RFC4301 describes that we lookup SPD based on the ID, and that ID is not authenticated when using NULL authentication, we cannot mix it with authenticated IDs. Either here, or in the security considerations section. We do already have section 3.3 which covers this, but it does not go to this kind of lower level details of PAD and SPD. On the other hand we already describe that you need the flag, and we warn that combining authenticated and unauthenticated peers in same host is dangerous, so that might be enough. But it is said that unauthenticated IDs can only be matched if SPD entry has a new flag set. I think it must be enough. Valery. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth-03
Valery Smyslov writes: > Is the following text for the entire section 2.4 OK for you? > (I've borrowed some of your text): Looks mostly ok. > 2.4. Interaction with Peer Authorization Database (PAD) > >Section 4.4.3 of [RFC4301] defines the Peer Authorization Database >(PAD), which provides the link between Security Policy Database (SPD) >and the IKEv2. The PAD contains an ordered list of records, with >peers' identities along with corresponding authentication data and >Child SA authorization data. When the IKE SA is being established >the PAD is consulted to determine how the peer should be >authenticated and what Child SAs it is authorized to create. > >When using NULL Authentication, the peer identity is not >authenticated and cannot be trusted. If ID_NULL is used with NULL >Authentication, there is no ID at all. The processing of PAD >described in Section 4.4.3.4 of [RFC4301] must be updated. > >The NULL authentication needs to be added as one of supported >authentication methods. This method MUST contain no authentication >data. I do not understand why there is MUST NOT for authentication data. Yes, there is no authentication data, but that is not really something that needs to be enforced in MUST level. Perhaps just change This method MUST contain no authentication data. to The NULL authenticaiton method does not have any authentication data. or similar. > To add support for ID_NULL, it needs to be included into the >list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The >matching rule for ID_NULL is just whether this type is used, i.e. no >actual ID matching is done, as ID_NULL contains no identity data. > >Section 4.4.3.3 of the [RFC4301] describes how the IKE ID is matched >against the SPD entries. When using the NULL authentication method >those matching rules MUST include matching of a flag in the SPD entry ^ change "a flag" to "a new flag", so it clearly indicates we are talking about something that is modified in the RFC4301, not something that already is there. >specifying whether unauthenticated users are allowed to use that >entry. I.e. each SPD entry needs to be augmented to have flag >specifying whether it can be used with NULL authentication or not, >and only those rules explictly having that flag turned on can be used >with unauthenticated connections. I wonder should we explitly mention something about dangers which can happen if this flag is not implemented properly, i.e. because the RFC4301 describes that we lookup SPD based on the ID, and that ID is not authenticated when using NULL authentication, we cannot mix it with authenticated IDs. Either here, or in the security considerations section. We do already have section 3.3 which covers this, but it does not go to this kind of lower level details of PAD and SPD. On the other hand we already describe that you need the flag, and we warn that combining authenticated and unauthenticated peers in same host is dangerous, so that might be enough. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DDoS puzzle: PRF vs Hash
Thinking it over, you don’t really need AES at all, and in any case it doesn’t matter. The initiator doesn’t know the key and doesn’t know the algorithm, so it’s entirely a local matter. You are right, it's a local matter. For example, the responder could pick HMAC-SHA256 with a fixed key, and calculate HMAC-SHA256(K,cookie). And it’s not even necessary for the initiator to solve all of the response. We can limit it to 8 Si-s (m=8), each 16 bits (k=16) even though the output of HMAC-SHA256 is 256 bits. m only serves to force the initiator to go through most of the 2^k possibilities. And another drawback of this approach is that the responder must do quite a lot of work to prepare puzzle. It must first calculate S1||S2||…||Sm and then for each Si calculate Hi. That is not an enormous work, but comparing with the current "zero bits" proposal, where the puzzle goes for free, it is non insignificant (especially as we're trying to protect responder against DoS attack). And again, my main concern is whether we are solving the right problem. This approah makes time requiring to solve random puzzle more consistent. But it doesn't help weak clients, unless we allow them to return as many Si-s, as they can. But in this case I see no significant advantages of this approach, but I can see its complexity, increased message size and increased load on responder. Valery. Yoav On Feb 6, 2015, at 8:30 AM, Valery Smyslov wrote: I can see two drawbacks with this approach. First, to make it aligned with algorithm agility, we need to negotiate not only PRF, but also the encryption algorithm. And the selection criteria would become more complex. And second - it significantly increases the size of IKE_SA_INIT response message, as the puzzle must include m hashes. With SHA256 and m = 8 it is additional 256 bytes. With SHA512 and m = 16 it is additional 1024 bytes. That is not good as it increases the chance for IP fragmentation. Regards, Valery. > On Feb 1, 2015, at 8:38 PM, Scott Fluhrer (sfluhrer) > > wrote: > > If you want to tighten up the time between worse case and average case > > time taken by the problem solver, might I suggest this: > > - When the verifier is asked to generate a problem, it pick a nonce N, > > and use it to compute m k-bit values S_1, S_2, ..., S_m (for example, S_1 || S_2 || ... || S_m = AES_key(N), where the AES key is secret to the verifier), and publish k, N, HASH(N, S_1), HASH(N, S_2), ..., HASH(N, S_m) > > - To solve the problem, the solver needs to produce the values S_1, > S_2, > ..., S_m, and send back N, S_1, S_2, ..., S_m > > - The verifier verifies that the value N was what was originally given > > (for example, the nonce might include the solver's IP address and a timestamp), and that the values S_1 || S_2 || ... || S_m = AES_key(N||0), (or alternatively, that those values produces the hashes it sent). > > The solver can always solve the problem by computing 2**k hashes; with > > moderate m, we can make it unlikely that it can be done with significantly fewer hashes; I would suggest m=4. > > Of course, the cost of doing this is a) larger messages, and b) larger > > up-front cost generating the problem (which, IMHO, isn't too bad -- one AES encryption, and m hash computations; however, you are free to disagree). > Hi, Scott. Thanks for the suggestion. Let me see if I understand it correctly: Responder has a fixed AES key (let’s call it K). Let’s assume that N is a COOKIE calculated as in RFC 5996. The responder Calculates S1||S2||…||Sm = AES(K, COOKIE). COOKIE can be any length, but for simplicity let’s assume 128-bit so that we don’t have to deal with IVs, ICs or any other artifacts of modes of operation. Also, let’s set m=8 and all Si as 16-bit. So the responder now calculates 8 hashes: for each i Hi = SHA256(COOKIE || Si) or better yet, Hi = PRF(Si, COOKIE). The responder sends to the initiator: - The COOKIE - Hi for all i. - The number k, although that can be deduced from the number of His - An identifier for the PRF algorithm chosen. The initiator needs to find Si values such that Hi = PRF(Si, COOKIE). The silly way to do this is to solve run through all 2^16 possible Si values once for each Hi (8 times), but a better way would be to run once through the possible Si-s and find all of them. There is a small chance of making an error if two 16-bit values produce the same result when using the PRF on the cookie. The initiator repeats the request along with the nonce and Si for all i. The responder now needs to do the following: - Verify the COOKIE - Encrypt the COOKIE, resulting (hopefully) in the concatenation of the Si values. With the numbers I used in the example, k=16 resulting in 2^16 PRF calculations on the client. The puzzle can be made harder by increasing k and breaking the encrypted COOKIE into larger chunks. Did I get this correctly? Thanks Yoav ___ I
