On Sep 24, 2013, at 3:04 PM, Valery Smyslov sva...@gmail.com wrote:
I just reread the introduction of RFC 4945 and I don't understand its
purpose. So I'm not sure it should be referenced from 5996bis.
Ok, if there is any disagreement about it, then I think it is better
to leave it out from
no hat
On Sep 24, 2013, at 4:21 AM, Tero Kivinen kivi...@iki.fi wrote:
Yaron Sheffer writes:
I just reread the introduction of RFC 4945 and I don't understand its
purpose. So I'm not sure it should be referenced from 5996bis.
Ok, if there is any disagreement about it, then I think it is
Valery Smyslov writes:
And this not the only contradiction between RFC5996 and RFC4945 -
the latter requires ID_IPV*_ADDR to match source IP address of IKE
packet by default, while the former explicitely allows not to do it
in any case.
RFC4945 requires that implementations MUST be
I just reread the introduction of RFC 4945 and I don't understand its
purpose. So I'm not sure it should be referenced from 5996bis.
It is definitely not a profile in the sense that Tero is alluding to.
Tero's own minimal IKEv2 is a profile for a specific use. RFC 4945
just attempts to fill
So do you think it would be appropriate to mandate these matching
rules in rfc5996bis,
or should this be left to AD-VPN solutions. IOW, is such a standard
rule needed for generic IKE/IPsec?
It's definitely worth to mention these rules in RFC5996bis, or at least
point to the RFC4945.
Valery Smyslov writes:
Yes, there is no obvious mapping between ID_KEY_ID and certificates and
thus ID_KEY_ID is out of scope for RFC4945.
As rfc5996 describes ID_KEY_ID as
An opaque octet stream that may be used to pass vendor-specific
information necessary to do certain proprietary types of
And this not the only contradiction between RFC5996 and RFC4945 -
the latter requires ID_IPV*_ADDR to match source IP address of IKE
packet by default, while the former explicitely allows not to do it
in any case.
RFC4945 requires that implementations MUST be capable of verifying
the
Hi Yoav,
What I could not find anywhere in the RFC is how to match name in the ID
payload to the certificate. In HTTPS we have a requirement that either the
CN or the dNSName alternate name match the domain name in the URL. We
don't have similar rules for IKE, do we?
Yes, we do: RFC4945.
Yoav Nir writes:
What I could not find anywhere in the RFC is how to match name in
the ID payload to the certificate. In HTTPS we have a requirement
that either the CN or the dNSName alternate name match the domain
name in the URL. We don't have similar rules for IKE, do we?
That is mostly
Valery Smyslov writes:
So do you think it would be appropriate to mandate these matching rules in
rfc5996bis, or should this be left to AD-VPN solutions. IOW, is such a
standard rule needed for generic IKE/IPsec?
It's definitely worth to mention these rules in RFC5996bis, or at least
Hi
While working on some text for the AD-VPN document, I came across some
weirdness in the base IKEv2 specification:
The IDi and IDr payloads have any of several types: ID_IPV4_ADDR, ID_FQDN,
ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID.
Section 4 (conformance
11 matches
Mail list logo
