Still might be worth a document proposing some profile, even if it does not
match current practice.
On Sep 24, 2013, at 9:12 PM, Yaron Sheffer wrote:
> I'll defer to Paul on this one.
>
> Thanks,
> Yaron
>
> On 09/24/2013 05:00 PM, Paul Hoffman wrote:
>>
>>
>> On Sep 24, 2013, at 4:21
I'll defer to Paul on this one.
Thanks,
Yaron
On 09/24/2013 05:00 PM, Paul Hoffman wrote:
On Sep 24, 2013, at 4:21 AM, Tero Kivinen 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 f
On Sep 24, 2013, at 4:21 AM, Tero Kivinen 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 better
> to lea
On Sep 24, 2013, at 3:04 PM, Valery Smyslov 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 5996
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 5996bis.
If we leave it out, than original Yoav's question "is there an
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 better
to leave it out from 5996bis.
> It is definitely not a "profile" in
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 fil
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 implementati
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 ID_IPV*_A
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 o
> > 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
On Sep 16, 2013, at 2:02 PM, Valery Smyslov wrote:
> 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
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 l
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
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.
S
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 r
16 matches
Mail list logo
