Re: [IPsec] IPR confirmations for draft-ietf-ipsecme-multi-sa-performance
Hi Tero, > Are any authors of the draft-ietf-ipsecme-multi-sa-performance (or > anybody else) aware of any IPRs related to this draft? I'm not aware of any IPRs. > Are authors willing to be listed as authors? I'm willing to be listed as author. Regards, Tobias OpenPGP_signature.asc Description: OpenPGP digital signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update
Hi Paul, >> That's exactly what I'm proposing. Make it *mandatory* that the first >> rekeying of the Child SA that's created with IKE_AUTH is a regular one. >> Because if that's not the case, it might be impossible for a responder >> to deduce what the initiator's proposal is. All further rekeyings of >> that Child SA can be optimized afterwards. > > I do not want to make it mandatory because for IoT devices with provisioning, > this is not needed and the whole point is saving energy by not sending > unnecessary bytes and a regular rekey is a LOT of bytes. OK, I understand that there are situations where it would be an advantage to only do optimized rekeyings for the Child SA created with IKE_AUTH (although in the IoT case I'd assume the proposals and TS are relatively small to begin with). And I think there are scenarios where we can do so (relatively) unambiguously. For instance, if no PFS is needed and the initiator omits the KE payload, that's quite clear for the responder. And if a KE payload is received, the responder could perhaps safely assume that that's the only and required key exchange (i.e. the initiator would not have NONE or any additional key exchanges in the proposal if it were to initiate a regular rekeying). So maybe we could define a set of conditions/requirements that allow initiators to use an optimized rekeying for the first rekeying of the initial Child SA (or that require a regular rekeying, whatever is shorter/easier). Of course, there could still be mismatches. PFS vs. no PFS results in a NO_PROPOSAL_CHOSEN error, like with a regular rekeying, so that's fine. But if the proposed KE method is unsuitable for the responder, it would either have to respond with NO_PROPOSAL_CHOSEN, too, or there need to be guidelines on what KE method to encode in an INVALID_KE_PAYLOAD notify, as we don't have a proposal from the initiator to select from (maybe NONE, which normally doesn't make sense, to trigger a regular rekeying?). And also what the initiator would do after receiving such an INVALID_KE_PAYLOAD error (always retry with a regular rekeying, or maybe with an optimized rekeying using the requested method if there is one and it's in its proposal). Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME errata items
Hi Tero, > https://www.rfc-editor.org/errata/eid6339 > > This complains that "Curve25519 and Curve448 for IKEv2" RFC > 8051, has Appendix A public keys for X25519 generated > incorrectly. I am not able to verify this as I do not have > code to verify the generated test vectors. If someone has code > that can verify the test vectors, please do so and report > here. The original test vector works for us (verified with multiple X25519 implementations). I think most of the confusion comes from the different formatting of the values when compared to the test vectors in RFC 7749 (in particular d_i/r). In the latter, the values are given as long hex strings. It states: "The inputs are generally given as 64 or 112 hexadecimal digits that need to be decoded as 32 or 56 binary bytes before processing." So these values are byte strings, i.e. each two hex digits simply represent a byte. For the random_i/r, pub_i/r and SHARED_SECRET values in RFC 8031 this has been made a bit clearer by separating the individual bytes. But then there are the d_i and d_r values. These are given as long hex strings, however, unlike those in RFC 7749, they are not byte strings but actually the numbers in base 16 after decoding the binary values fixed_i/r as little-endian. Note that RFC 7749 also gives the decoded numeric values of some of the inputs, but does so in base 10 thus avoiding this confusion. So in RFC 8031 it would have been clearer if these values were either prefixed with 0x: d_i = 0x549D5F4A460900E6D9F63F53586AD1DD8CEAF925739B78B676B4558630B41F70 d_r = 0x4856A039B8F178E9A1550722DCEF01559ECDBA30E0D0ADDD600D295352645408 or also given in base 10: d_i = 38272331938479145686941743521879072306 324697418955568337792079861743202082672 d_r = 32719579781175365148694953981896303820 37006999393827931153854512601603080 Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update
Hi Tero, >> It already states in section 3: "Non-optimized, regular rekey requests >> MUST always be accepted." > ... >> So you're saying some configs, that are valid for regular IKEv2, will >> just not work with this extension? And we'll only know once there is > > Combining those two, I think this is fine. I.e., this is optimization > and it does NOT NEED to optimize every single possible configuration. > We can clearly state that if you are using certain configurations you > can't use this optimization, and have to fall back to normal rekey. > > For example we could say that if you are negotiating multiple > protocols (AH + ESP or ESP + IPCOMP), or if you are using anything > else than one single KE algorithm for create child sa, you need to use > regular rekey. While there might be configurations that prevent this extension from working at all (but I think e.g. with IPComp sending the CPI with the regular IPCOMP_SUPPORTED notify in the optimized rekeying exchange should be fine), I think, with regards to key exchanges, a regular rekeying is really only necessary the first time the initial Child SA is rekeyed. For all other Child SAs it's perfectly fine to use optimized rekeyings because their proposals were negotiated with a regular CREATE_CHILD_SA exchange. >> The only way to avoid that would be the extension either making >> childless IKE SAs mandatory, or strictly prohibiting inconsistent KE >> configs between IKE and Child SAs, taking away quite a bit of >> flexibility IKEv2 offers. > > You do not need to make childless IKE SA mandatory, you simply need to > do first rekey after initial sa creation using normal rekey, and if > that normal rekey has SA/KE payloads that are acceptable for the > optimized rekey in the future, then you can use optimized rekeys in > the future. That's exactly what I'm proposing. Make it *mandatory* that the first rekeying of the Child SA that's created with IKE_AUTH is a regular one. Because if that's not the case, it might be impossible for a responder to deduce what the initiator's proposal is. All further rekeyings of that Child SA can be optimized afterwards. Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update
Hi Paul, >> * maybe add "incompatible proposal" as a reason for initiating a >> regular Child SA rekeying of the first SA (if the KE method used >> for IKE is not in the Child SA proposal). >> >> However, I'd honestly prefer if that was just the standardized >> behavior for the Child SA created with IKE_AUTH as we really don't >> know what KE methods the responder has in its Child SA proposal. > > I would really like to avoid requiring the regular rekey method in the > protocol. That way, some time in the far future, this could perhaps > become the only rekey method used. If this draft has a requirement > for the old method in it, we will never be able to get rid of the older > one. It already states in section 3: "Non-optimized, regular rekey requests MUST always be accepted." So e.g. strongSwan always doing a regular rekeying for the first Child SA as initiator is perfectly in line with the draft. It's currently just not described explicitly or the recommended or mandatory behavior. Which could pose a problem as responder of an optimized rekeying of the first Child SA. It works fine in the single KE case if the method in the KE payload is in the responder's Child SA proposal, but if not, or if there are multiple key exchanges involved, there could be issues (see below). > Additionally, having a different KE for the initial Child that comes > from the IKE KE and its Child SA rekey is already a questionable/bad > configuration, since you are not rekeying the child under the same > level of protection. Not sure if that's necessarily true for the multi-KE/PQC use case. One might want to just protect the IKE SA with multiple big and costly key exchanges and then only use a single, classic KE to create fresh keys for the Child SAs (whose KE payloads are exchanged under the protection of the quantum secure IKE SA). That the first Child SA will have key material derived from the "stronger" IKE keys is just an accidental by-product of how IKEv2 is designed. A different aspect of the multi-KE/PQC case is that only the IKE SA requires a classic KE method (to avoid fragmentation during IKE_SA_INIT), Child SAs could just be rekeyed/created using a single PQC key exchange. So the Child SA proposal might not contain the same number of key exchanges or any classic KE methods but only PQC methods that were used as additional KEs for the IKE_SA. Another way to avoid that would be to make childless IKE SA creation mandatory for implementations of this extension, so the first Child SA would always have to be created with a separate CREATE_CHILD_SA exchange. But since the creation of a new Child SA is pretty much the same as a classic rekeying, we could also just make the latter mandatory for the first Child SA if it was created with IKE_AUTH and only rely on stuff that's already specified in RFC 7296 ;) > I dont mind doing extra work for those who want > such questionable/bad configurations, but would not want to add it to > proper/good configurations that do not need it. So you're saying some configs, that are valid for regular IKEv2, will just not work with this extension? And we'll only know once there is some kind of failure during the optimized rekeying? Which can, admittedly, already happen with regular IKEv2 with mismatched PFS settings because we don't exchange KE methods during IKE_AUTH. But then at least we get a relatively clear NO_PROPOSAL_CHOSEN error immediately. In addition to that situation, which could occur here too (i.e. initiator sends KE payload, responder has no KE methods in its Child SA proposal and replies with NO_PROPOSAL_CHOSEN), we have multiple additional ones: * Initiator sends a KE payload with a method that the responder has not in its Child SA proposal. So it sends back an INVALID_KE_PAYLAOD notify (it doesn't really know what KE methods the initiator supports, so it has to guess the method it encodes in the notify from its own proposal and maybe the first KE method of the IKE_SA). What is the initiator to do then? Retry an optimized rekeying with the requested method (what if it's not in its proposal)? Retry with a regular rekeying (preferring the requested method, but again it could be an unsupported method)? Abort the rekeying? * Initiator has optional additional KE methods (i.e. with NONE) in its Child SA proposal while the responder does only have a single KE method configured. Then the initiator might expect multiple key exchanges, because that's what the IKE proposal says and it follows the draft's SHOULD. But the responder does not return an ADDITIONAL_KEY_EXCHANGE because it adheres to its Child SA proposal. What is the initiator to do then? * Same as above but reversed. So the responder expects an additional key exchange but the initiator just follows its Child SA proposal and is happy with the completed single key exchange, ignores the ADDITIONAL_KEY_EXCHANGE notify in the response and
Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update
Hi Paul, > I tried to formulate and solve the issues discussed at the previous > meeting. There was no clear outcome (based on rereading the minutes) > so please check the changes and let the authors know if you disagree. Thanks for the updates. Some notes: * maybe clarify that IPCOMP_SUPPORTED is only sent and a MUST if IPComp was negotiated in the original Child SA. RFC 7296 explicitly states "These payloads MUST NOT occur in messages that do not contain SA payloads." with regards to IPCOMP_SUPPORTED. Is there any clarification required on that? * maybe add "incompatible proposal" as a reason for initiating a regular Child SA rekeying of the first SA (if the KE method used for IKE is not in the Child SA proposal). However, I'd honestly prefer if that was just the standardized behavior for the Child SA created with IKE_AUTH as we really don't know what KE methods the responder has in its Child SA proposal. So just blindly assuming the IKE's KE methods will be accepted seems risky (in particular if multiple key exchanges were involved in creating the IKE SA). That IKE SA's first KE method can still be preferred in the Child SA rekeying request if it's in the initiator's proposal (i.e. use it for the KE payload and list it as first method in the SA payload). But if there is a mismatch, it seems easier to recover during a regular rekeying than blindly trying the IKE KE method, receiving an INVALID_KE_PAYLOAD and then having to initiate a regular rekeying all over anyway (if that's even an option, the draft currently doesn't explicitly say). * I'm still wondering why the critical bit has to be set for the OPTIMIZED_REKEY notify. It's a regular Notify payload, so it MUST be understood by all IKEv2 implementations and setting the bit is basically redundant (the critical bit only concerns the payload type, not the contents such as the notify message type - it's also only allowed to be set in requests so making it an unconditional MUST like that violates RFC 7296 anyway). Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKEv2: how to respond to REKEY_SA with bad protoid?
> The Child SA is identified by the protocol id and spi tupple, so if > you do not have matching child sa, returning CHILD_SA_NOT_FOUND is the > correct, and as in the section 2.25 the RFC7296 says: > >A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives >a request to rekey a Child SA that does not exist. The SA that the >initiator attempted to rekey is indicated by the SPI field in the >Notify payload, which is copied from the SPI field in the REKEY_SA >notification. A peer that receives a CHILD_SA_NOT_FOUND notification >SHOULD silently delete the Child SA (if it still exists) and send a >request to create a new Child SA from scratch (if the Child SA does >not yet exist). > > If the protocol id does not match the protocol id you are using, then > you do NOT HAVE matching Child SA, thus the other end is trying to > rekey sa that does not exists. > > I.e. the SPI field is copied from the REKEY_SA to CHILD_SA_NOT_FOUND > notify, then you needs to copy the protocol id too... > > Also the section 3.10 of RFC7296 says: > >o Protocol ID (1 octet) - If this notification concerns an existing > SA whose SPI is given in the SPI field, this field indicates the > type of that SA. For notifications concerning Child SAs, this > field MUST contain either (2) to indicate AH or (3) to indicate > ESP. Of the notifications defined in this document, the SPI is > included only with INVALID_SELECTORS, REKEY_SA, and > CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be > sent as zero and MUST be ignored on receipt. > > thus the Protocol ID field indicates the protocol id for the SA > indicated by the SPI field, thus Protocol ID and SPI are always going > together, and as REKEY_SA and CHILD_SA_NOT_FOUND are those few ones > that have Protocol ID and SPI non-zero you need to copy them. > > You could submit an errata saying that > > The SA that the >initiator attempted to rekey is indicated by the SPI field in the >Notify payload, which is copied from the SPI field in the REKEY_SA >notification. > > should say > > The SA that the initiator attempted to rekey is >indicated by the Protocol ID and SPI fields in the Notify payload, >which are copied from the Protocol ID and SPI fields in the REKEY_SA >notification. Hm, I just noticed that we (strongSwan) implement that incorrectly as we send the CHILD_SA_NOT_FOUND notify without SPI (or protocol ID). What's the purpose of repeating that information in the notify? There can only be a single REKEY_SA notify in the request, so how could there be any confusion for the exchange initiator about which SA wasn't found by the responder? Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec
In the SELinux case, and using your example, could the client actually propose "nfs-client in TSi and "nfs-server" in TSr? So the server could set "nfs-client" on the inbound SA/policy and "nfs-server" on the corresponding outbound SA/policy of the CHILD_SA (and vice-versa on the client)? Or won't that work? If it's a valid use case, should the document specify which of the two labels is to be applied to what SA/policy? Or is that an implementation aspect that you explicitly want to keep out of it? I was trying to keep that out of the draft. Because for example if the label is TOP_SECRET vs SECRET, then you might not want to allow this. Also, IKE daemons might not know how to interpret the label at all. Not sure I get your argument because if the local configuration allows what's proposed in TSi and TSr, why wouldn't we define on what SAs/policies the labels should get applied? That doesn't require knowing anything about the labels. Or maybe it's just obvious that the label in TSi is applied on the inbound SA/policy and the one in TSr on the outbound SA/policy on the responder of the CHILD_SA (and vice-versa on the initiator)? Also, I don't fully get the multiple label in TSi part. If multiple labels are allowed/supported per SA by the implementation (not sure how that would work inbound, but let's assume there is a way to mark packets with some kind of meta label that covers multiple negotiated ones), why would any narrowing take place for TSr? Whether or not a label could be narrowed is something that is outside of the scope of IKE. We don't want to require labels properties that might not be compatible with a labeling structure we haven't thought or (or aren't allowed to know about :) Not sure about that as for instance with SELinux, the IKE daemon, as responder, doesn't seem to be able to avoid interpreting labels to some degree as it usually won't have configurations for all possible labels that could get negotiated. So it might have to do an SELinux policy check with the received label (I guess you could say the interpretation happens in the SELinux subsystem, but it has to at least interpret or convert the label to a null-terminated string). I wanted to leave the option open of being able to suggest multiple labels to support potential migrations or 'narrowing' or 'widening'. I also assumed that if the labeling system supports label A and B, i could also support a different label with the meaning of A|B or A&B. I guess we could extend the mechanism to allow selecting multiple labels, but it just seemed a complexity that was likely not to be used in practise (AFAWK). In fact, I'd much rather remove allowing multiple labels to be selected, than add complexity to allow multiple labels to be negotiated. Did you mean "remove allowing multiple labels to be *proposed*" (not "selected")? Otherwise, I'm not sure what you mean. On the other hand, if multiple labels are not supported, in what situation could proposing multiple labels be useful? One reason could be to try and get the most secure label we both support (or are allowed to use) in place. Eg if the information is SECRET, but perhaps you and I have TOP_SECRET, by sending both we could end up on the more secure TOP_SECRET. But if you only have SECRET, I might be willing to allow SECRET for this as well. Another example is migration. Perhaps we introduce a new TOPPEST_SECRET, and I don't know if you upgraded to support this level yet, so I can send TOPPEST_SECRET and TOP_SECRET and you pick TOP_SECRET when nog yet upgraded and TOPPEST_SECRET when already upgraded. It might help if those examples are documented as possible uses of the extension and as rationale for the design decisions. Wouldn't traffic with the omitted labels just get dropped afterwards? Or is the assumption that this triggers a new acquire/SA? Not all labeling systems might be assigned labels based on IP trafic properties. We would want to avoid things just "not working". Eg if you don't support TOPPEST_SECRET, we wouldn't want to get stuck with not being able to exchange traffic at all. If so, would the request not contain multiple labels again and, if that's the case, what prevents the peer from selecting the same label as before? Is it to keep track of what label it selected previously and that the intention of the initiator now might be that another should get selected? I dont have expectations that using the wrong label or omitting a label would result in a new working SA. It might or it might not. Or is it up to the initiator not to propose multiple labels the second time around (or just omit the ones it already has an SA for)? If so, why would it send multiple the first time (in particular if the SA was triggered by an acquire)? I think you are thinking too much about actual packet properties, and not take organizational / administratie labels into account ? I guess I am, but they are negotiated as traffic sel
Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec
Hi Paul, 8. Section 3.2: It would be unlikely that the traffic for TSi and TSr would have a different Security Label, but this specification does allow this to be specified. Can you please provide some examples of possible semantics of different TS_SECLABELs in TSi and TSr? Sending different security labels in different directions? Just for curiosity. I cannot, but I wanted to ensure not to accidentally forbid it. What we do see with our implementation though, that we end up with two IPsec Sa's where each is only used in one direction. For example, image you have an SElinux context for nfs-server and nfs-client. What happens is that the NFS client triggers one label on the outgoing connection, triggers ACQUIRE, sets up an IPsec SA with a label "nfs-client". The first packet hits the NFS server, which to reply hits a different SElinux context of "nfs-server". So it will trigger an ACQUIRE and setup a second IPsec SA with a label "nfs-server". Both IPsec SA's will only be used in one direction. I did not add any of this into the document, as it is very SElinux specific, where as the draft is agnostic on the meaning of SEC_LABEL and allows for other mechanisms that might not have this complexity. In the SELinux case, and using your example, could the client actually propose "nfs-client in TSi and "nfs-server" in TSr? So the server could set "nfs-client" on the inbound SA/policy and "nfs-server" on the corresponding outbound SA/policy of the CHILD_SA (and vice-versa on the client)? Or won't that work? If it's a valid use case, should the document specify which of the two labels is to be applied to what SA/policy? Or is that an implementation aspect that you explicitly want to keep out of it? Also, I don't fully get the multiple label in TSi part. If multiple labels are allowed/supported per SA by the implementation (not sure how that would work inbound, but let's assume there is a way to mark packets with some kind of meta label that covers multiple negotiated ones), why would any narrowing take place for TSr? On the other hand, if multiple labels are not supported, in what situation could proposing multiple labels be useful? Wouldn't traffic with the omitted labels just get dropped afterwards? Or is the assumption that this triggers a new acquire/SA? If so, would the request not contain multiple labels again and, if that's the case, what prevents the peer from selecting the same label as before? Is it to keep track of what label it selected previously and that the intention of the initiator now might be that another should get selected? Or is it up to the initiator not to propose multiple labels the second time around (or just omit the ones it already has an SA for)? If so, why would it send multiple the first time (in particular if the SA was triggered by an acquire)? I think either the narrowing to a single label should be optional, or sending multiple labels in TSi should be prohibited in the first place. Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev2-multiple-ke
Hi Paul, Trying to clarify some things from my experience implementing this extension. The authors might have some more insights on these points. Key exchange methods negotiated via Transform Type 4 MUST always take place in the IKE_SA_INIT exchange. Additional key exchanges negotiated via newly defined transforms MUST take place in a series of IKE_INTERMEDIATE exchanges, in an order of the values of their transform types, so that key exchange negotiated using Transform Type n always precedes that of Transform Type n + 1. I don't understand this section, specifically the use of "Transform Type 4" and "Transport Type n+1", as we only have transform type 5 and nothing higher and that is Extended Sequence Number. The documents defines additional transform types for the additional key exchanges. I think it might be trying to say if there are more than one Key Exchange, that the subsequent key exchange should follow in the next IKE message exchange (eg in a round of IKE_INTERMEDIATE) ? They should, but the exchanges should also be performed in order. So if e.g. algorithms for Additional Key Exchange 1 and Additional Key Exchange 2 are negotiated, the key exchange for Additional Key Exchange 1 has to be done before the one for Additional Key Exchange 2. Each IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method. I don't understand why there is this limitation. What if some Key Exchange mechanism will require 2 RTTs. Why preventively forbid that? That would be a new type of key exchange that couldn't be used with IKEv2 as it is currently defined (neither for IKE nor Child SAs). But I think you misunderstood. What the above means is that you can't send two KE payloads in a single IKE_INTERMEDIATE exchange (i.e. you can't send the KE paylaods for Additional Key Exchange 1 and Additional Key Exchange 2 if algorithms were negotiated for both). Additional key exchange methods are proposed using Additional Key Exchanges transform types. All these transform types are optional, the initiator is free to select any of them for proposing additional key exchange methods. Consequently, if none of Additional Key Exchange transforms are included in the proposal, then this proposal indicates performing standard IKEv2, as defined in [RFC7296]. So how does an intiiator convey that it deems an additional Key Exchange to be mandatory? It proposes the respective transform type without adding NONE. What the above means is that the initiator can freely choose to propose e.g. Additional Key Exchange 1, but not Additional Key Exchange 2 and 3, and Additional Key Exchange 4 (for whatever reason, maybe each transform type is somehow linked to a specific class of algorithms in this implementation and it only has some of them available). Or it can also not propose any of them or include NONE in some or all of them to leave it up to the responder if a specific key exchange is performed. If the initiator includes any transform of type n (where n is among Additional Key Exchanges) in the proposal, the responder MUST select one of the algorithms proposed using this type. A transform ID NONE may be added to those transform types which contain key exchange methods that the initiator believes are optional. And so I again do not understand this. What is "n" here? a new transform type ? ( eg n=6 ??) or a new entry in the Transform Type 4 Key Exchange registry? Yes, a new transform type (Additional Key Exchange 1-7), not a new entry in the registry for transform type 4. At his point, the Additional Key Exchange is introduced, and I am beginning to understand things. This should really be explained before the text I pointed at above to make any sense to the reader. And see below on placing "Additional Key Exchanges" into the "Key Exchanges" Registry. I see :) The next part explains the CREATE_CHILD_SA and IKE_FOLLOWUP_KE exchanges. I personally would prefer that a different exchange than CREATE_CHILD_SA is used if the completion of such an exchange does not lead to a fully rekeyed state. This use of completing a CREATE_CHILD_SA and being in a state that is not "rekeyed" or "failed" complicates the state machine. Until the proposals are negotiated during the CREATE_CHILD_SA exchange, the initiator doesn't know if any new mechanisms or exchanges are needed. And because a PQ-safe IKE_SA protects the negotiation of additional CHILD_SAs or their rekeying, classic key exchanges could be considered perfectly safe for those if forward secrecy is desired. The data associated with this notification is a blob meaningful only to the responder Why a blob? Why not the imminent new SPI it generated for this new IKE SA? If you really want a blob, there should be an example of how to generate the blobs. I don't see any
Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07
Hi Paul, The ports used for IKE packets would not be randomized since IKE would not use source port for LB and so should be stable at the NAT. I was not referring to the IKE but the ESP packets sent by the responder to the natted IKE port for LB. Wasn't that what you were proposing? Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07
Hi Paul, Instead, the responder should use the port received by the responder in the IKE exchanges. Note that if these packets have random source ports, this will only work if the NAT implementation plays along or there is static port forwarding configured. NATs might filter inbound packets from endpoints that don't equal the IP/port to which the host behind the NAT originally sent packets when the NAT mapping was created (address and port-dependent filtering in terms of RFC 4787). I guess the same could happen in scenarios where there are no NATs but restrictive firewalls that block traffic from endpoints to which the host behind the firewall did not send traffic. Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Technical Errata Reported] RFC8031 (6339)
> I verified that the example in Appendix A of RFC 8031 is incorrect as > reported, but I do not believe that updating the values as suggested > in this errata completely fixes the example. > > The corrected values given in the report are valid if they are > interpreted as little-endian encoded coordinates (i.e. apply > decodeUCoordinate from RFC 7448). However, RFC 8031 (and the reporter) > represented pub_i, pub_r and SHARED_SECRET as a byte-separated > strings, whereas earlier values in 8031 in this byte-separated format > (random_i, random_r, fixed_i, fixed_r) all appear to be in big endian > order and the d_i and d_r explicitly encoded in little-endian are > given as a single string. I think it's the other way around. The byte-separated values are all in little-endian encoding and d_i and d_r are simply given as hex-encoded numbers (in their natural big-endian encoding as you'd write a decimal number). So I think the test vectors are correct. Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Matching of IKE ID on certificate subject and RDN ordering
Hi Paul, > For openssl, when checking the subject of the cert, it matches in this > order. but when I generated the same certificate with nss cert-util > and re-read it back in openssl, it showed me: > > CN=server, OU="Global, Support, Services", O=Test Example, L=Brno, > ST=Moravia, C=CZ > > Note that C= and CN= are swapped. These are differences in the binary data, > not the presentation. That's because, according to the documentation and examples, NSS certutil follows RFC 1485 when it comes to string representations of DNs, which states: The name is presented/input in a little-endian order (most significant component last). The latest RFC that replaced it, RFC 4514, states it this way, which is a bit clearer: Otherwise, the output consists of the string encodings of each RelativeDistinguishedName in the RDNSequence ..., starting with the last element of the sequence and moving backwards toward the first. Why the last RDN first? Could be to see the CN immediately, which usually identifies the actual entity. What you see in OpenSSL is the physical representation in the ASN.1 encoding of the certificate, i.e. the RDNs in their actual order in the RDNSequence. We follow the same principle in strongSwan when logging and parsing DNs. > So technically, when we expect one, receiving the other order would be > wrong. So should we really do matching based on the same order of RDNs. > What do other implementations do? In strongSwan we have an option (charon.rdn_matching) that allows changing how DNs in certificates are matched against configured IKE identities. It defaults to 'strict', which results in what RFC 5280 describes, i.e. all RDNs have to match in the same order (wildcards to ignore the values of RDNs are always allowed). With 'reordered', all RDNs have to be there, but their order doesn't matter. Finally, with 'relaxed', the certificate's DN may additionally contain RNDs that are not configured, which are then treated like wildcards. For example, with 'relaxed' you could configure CN=server which would be the same as configuring C=*, ST=*, L=*, O=*, OU=*, CN=server which matched both certificates with 'relaxed' and 'reordered' but only one with 'strict'. Using 'reordered' and 'relaxed' causes some overhead (memory and runtime) so 'strict' continues to be the default. Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [Technical Errata Reported] RFC7634 (5441)
Hi Paul, > Some note would be good because apparently strongswan insists of the > KEY_LENGTH attribute they shouldn’t be there? Yes, we did that incorrectly before 5.6.3 [1]. Since then the key length attribute is omitted, but it's still possible to add a transform with it to a proposal by using the chacha20poly1305compat keyword (for compatibility with older releases). Regards, Tobias [1] https://wiki.strongswan.org/versions/69 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] RFC8229 (IKE over TCP) and retransmissions
Hi Valery, I agree that generally retransmits are not useful or needed with TCP encapsulation. But as I see it, retransmits might actually be required in some situations. If the client sends e.g. a CREATE_CHILD_SA request but the TCP connection is closed or gets unusable for some reason before the server's response is received, the client has to reestablish the TCP connection. And the only way to do this (with window size 1, so no DPD or MOBIKE update can be sent) is to send a retransmit of the already sent message (otherwise the server might not know which TCP connection to use to send the CREATE_CHILD_SA response - I guess ESP packets could be used for that too, if there are any and there is a way to get notified in userland). On the other hand, RFC 8229 explicitly says that a responder should not consider retransmitted messages when deciding which TCP connections should be used...so I guess there is no way to recover properly if the TCP connection is severed mid-exchange (e.g. because a NAT device is rebooted or the client device roams between networks). Regards, Tobias ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
