Paul Hoffman wrote:
We earlier agreed in issue #50 to make the KEr in Section 1.3.2
(Rekeying IKE SAs with the CREATE_CHILD_SA Exchange) mandatory:
-- HDR, SK {SA, Nr, KEr}
Note that this is not in the current draft, but will be in the next
one.
So, what
Paul Hoffman writes:
We earlier agreed in issue #50 to make the KEr in Section 1.3.2
(Rekeying IKE SAs with the CREATE_CHILD_SA Exchange) mandatory:
-- HDR, SK {SA, Nr, KEr}
Note that this is not in the current draft, but will be in the next one.
So, what
Paul Hoffman writes:
The 4th paragraph of section 3.3 says If an algorithm that combines
encryption and integrity protection is proposed, it MUST be proposed
as an encryption algorithm and an integrity protection algorithm
MUST NOT be proposed. This means that an integrity protection
Paul Hoffman writes:
This has flummoxed a few reviewers. Tables such as those in section
3.3.2 are already out of date because things have been added since
RFC 4306. I propose that we remove all these tables from IKEv2bis,
and add notes pointing to the current IANA registries. I cannot see
Michael Richardson writes:
It is? I'll bet 95% of actual transport mode IPsec has an L2TP
layer inside.
Tero Inside one enterprise? I do not think so. I guess most of the
Tero IPsec traffic is VPN style tunnel mode, but as that is going
Tero over untrusted networks
Section 2.18 also states that in the case of the old and new IKE SA
selecting different PRFs, that the rekeying exchange (for SKEYSEED)
is done using the *old* IKE SA's PRF. What happens after that? The
end of section 2.18 says that SK_d, etc are computed from SKEYSEED
as specified in
Tero requested a clarification: I'm proposing to say that the certificate's
hash algorithm does not determine the AUTH hash function (which is the
negotiated PRF). Implementations may use the certificates received from a given
peer as a hint for selecting a mutually-understood PRF with that
Folks,
Is there anybody interested in helping completing the BTNS IPsec APIs
documents? If you are, please also state the level of commitment you're willing
to dedicate to that goal (e.g., editing, contributing, reviewing.)
If there isn't enough interest it seems the logical next step for the
At 4:08 PM +0200 11/24/09, Tero Kivinen wrote:
Paul Hoffman writes:
The 4th paragraph of section 3.3 says If an algorithm that combines
encryption and integrity protection is proposed, it MUST be proposed
as an encryption algorithm and an integrity protection algorithm
MUST NOT be proposed.
At 7:09 PM +0200 11/24/09, Yaron Sheffer wrote:
Russ later pointed out that there are multiple RFCs defining PKCS #7. Inputs
on current implementations are welcome.
PKCS#7 should reference http://tools.ietf.org/html/rfc2315RFC 2315.
I think we should leave this as UNSPECIFIED. There are many
10 matches
Mail list logo
