Re: [IPsec] #117: Hash and URL interop

+1 Even things that seem obvious like https and ftp require a lot of considerations, like how to verify the certificate in https, or what identity to present in ftp. If someone wants to specify additional URL methods, they can specify then in an I-D. On Nov 24, 2009, at 8:24 PM, Paul Hoffman

Re: [IPsec] WESP - Roadmap Ahead

Hi Manav, I agree that for an already negotiated SA, the SPD lookup detects IP source address spoofing. So in that case ESP detects the address spoofing during the SPD check whereas AH would detect it while checking the signature check. However SAD lookup is done with the longest match rule, and

Re: [IPsec] #116: The AUTH payload signature

Yaron Sheffer writes: > 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-

Re: [IPsec] #117: Hash and URL interop

Yaron Sheffer writes: > Resending. There may be value in other URL methods, just maybe, but > OTOH they would confuse developers and add security issues. I still reiterate that I do not think we can add "MUST NOT" for other URL methods, as that would be change that can make existing implementation

Re: [IPsec] #118: Reference for PKCS #7

Yaron Sheffer writes: > Russ later pointed out that there are multiple RFCs defining PKCS > #7. Inputs on current implementations are welcome. > > PKCS#7 should reference RFC 2315. I think the two options is either RFC5652 (latest CMS) or RFC2315 (original PK

Re: [IPsec] #119: Which certificate types can be mixed in one exchange?

Yaron Sheffer writes: > There was very limited discussion of this issue, which I see as the > main reason why Sec. 3.6 is underspecified. If my proposal below is > too restrictive we can expand it somewhat but still keep the number > of possible combinations at a level where testing (and > interope

Re: [IPsec] #120: CA indication with cert req - allowed types

Yaron Sheffer writes: > Please also see Tero's follow-up here: > http://www.ietf.org/mail-archive/web/ipsec/current/msg04990.html I still agree what I said back then :-) > Subject: [IPsec] #120: CA indication with cert req - allowed types > > > Sec. 3.7 has: > > The contents of the "Certifica

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

Paul Hoffman writes: > Yes, I should have worked this out more fully before posting. > > In all cases, I would add a reference to the IANA registry. > > Only lists code points: remove the whole table > 2.22: IPComp Tranform IDs > 3.3.2: Encryption, PRF, integrity, DH group, ESN I can agree r

Re: [IPsec] #118: Reference for PKCS #7

No, Sec. 1.1.1 of RFC 5652 (which you are quoting) only describes the differences between the original PKCS #7 v1.5 and RFC 2630. There follow a few more sections with other bells and whistles leading to RFC 5652. Besides, even if the later RFCs are (mostly) *backward compatible* with RFC 2315,

Re: [IPsec] #122: Integrity proposals with combined algorithms

Paul Hoffman writes: > I'm pretty sure others have read this the other way: you must give a > transform of "none". I do not see any point why I should send none, when it is better to just leave it out, this is what you normally do for ESP when you use combined mode ciphers. Leaving it out makes pa

Re: [IPsec] WESP - Roadmap Ahead

Jack Kohn writes: > Assume we dont have WESP. I would like to, but unfortunately I lost :-) > The end router having scores of OSPF adjacencies will have following > rules in its database for *each* adjacency: > > Incoming Pkt carries SPI X, then look at the nth bit and if its a OSPF > HELLO, put

Re: [IPsec] #117: Hash and URL interop

Yoav Nir writes: > Even things that seem obvious like https and ftp require a lot of > considerations, like how to verify the certificate in https, or what > identity to present in ftp. > > If someone wants to specify additional URL methods, they can specify > then in an I-D. Yes, and but if the

Re: [IPsec] WESP - Roadmap Ahead

Daniel Migault writes: > I agree that for an already negotiated SA, the SPD lookup detects IP source > address spoofing. Not quite true, as you point out yourself. > So in that case ESP detects the address spoofing during > the SPD check whereas AH would detect it while checking the signature ch

Re: [IPsec] comments on esp-null-heuristics-01

Michael Richardson writes: > Tero> How does that disagree in their definition of flow? > > A flow in the routing and ASIC space is an origin/destination IP address > pair only. A microflow is the 5-tuple. Never heard about microflow before. Wikipedia says: Applied to Internet routers,

Re: [IPsec] WESP - Roadmap Ahead

At 9:05 AM +0530 11/25/09, Jack Kohn wrote: > >... Assume we dont have WESP. The end router having scores of OSPF adjacencies will have following rules in its database for *each* adjacency: Incoming Pkt carries SPI X, then look at the nth bit and if its a OSPF HELLO, put it in Ospfv3HighPrio

Re: [IPsec] WESP - Roadmap Ahead

At 12:11 PM +0100 11/25/09, Daniel Migault wrote: Hi Manav, I agree that for an already negotiated SA, the SPD lookup detects IP source address spoofing. So in that case ESP detects the address spoofing during the SPD check whereas AH would detect it while checking the signature check. Howe

Re: [IPsec] #117: Hash and URL interop

Can you live with: Implementations MUST support HTTP. The behavior of other URL methods is not currently specified, so such methods SHOULD NOT be used in the absence of a Standards Track document defining them. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [

Re: [IPsec] #118: Reference for PKCS #7

Yaron Sheffer writes: > No, Sec. 1.1.1 of RFC 5652 (which you are quoting) only describes > the differences between the original PKCS #7 v1.5 and RFC 2630. I took the text from RFC2630 Abstract, didn't check the later ones in that much detail to find out the changes since sections... :) > There f

Re: [IPsec] #117: Hash and URL interop

Yaron Sheffer writes: > Can you live with: > > Implementations MUST support HTTP. This is already in the RFC4306. > The behavior of other URL methods is not currently specified, so > such methods SHOULD NOT be used in the absence of a Standards Track > document defining them. This addition is o

Re: [IPsec] #117: Hash and URL interop

> > The behavior of other URL methods is not currently specified, so > > such methods SHOULD NOT be used in the absence of a Standards Track > > document defining them. > > This addition is ok for me, altough I do not think we need to have > *Standard Track* documents to be able to use, I would ju

[IPsec] SS certificate question

Hello, I have two IPsec peers that shared self-signed certificates via a secure out-of-band channel. Where should I put the peer's certificate so that IKEv2 can use it for authentication? Is it the Peer Authorization Database? Regards, Harhit ___ IPs

Re: [IPsec] #117: Hash and URL interop

At 4:44 PM +0200 11/25/09, Yaron Sheffer wrote: >Can you live with: > >Implementations MUST support HTTP. The behavior of other URL methods is not >currently specified, so such methods SHOULD NOT be used in the absence of a >Standards Track document defining them. No. There is no technical or in

Re: [IPsec] #116: The AUTH payload signature

At 1:44 PM +0200 11/25/09, Tero Kivinen wrote: >Yaron Sheffer writes: >> 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 fro

Re: [IPsec] #122: Integrity proposals with combined algorithms

At 3:04 PM +0200 11/25/09, Tero Kivinen wrote: > > Are people OK with wording that says "MUST either offer an integrity > > algorithm or a single integrity algorithm of 'none'"? > >If you add "no" somewhere there (i.e. MUST either offer no integrity >algorithm...) then I can accept it. Er, right.

Re: [IPsec] #122: Integrity proposals with combined algorithms

> MUST either offer no integrity algorithm or a single integrity algorithm of "none" > > Does anyone have a problem with this new wording? I suggest we specify that one or the other as the preferred approach. Maybe add an additional sentence saying SHOULD for no transform and MAY for transform=

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

Based on Tero and Yaron's responses, I have a different idea: - Leave all the tables in - Remove the numbers from every table - Removed the "reserved", "reserved to IANA", and "private use" lines - Precede each table with the following boilerplate paragraph: The following table only lists th

Re: [IPsec] SS certificate question

On Wed, Nov 25, 2009 at 06:09:48PM +0200, Harhit Tam wrote: > Hello, > > I have two IPsec peers that shared self-signed certificates via a secure > out-of-band channel. This sort of deployment is not as uncommon as some might think. > Where should I put the peer's certificate so that IKEv2 can u

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

On Wed, Nov 25, 2009 at 08:39:08AM -0800, Paul Hoffman wrote: > - Add [IKEV2IANA] to the Normative References; it will point to the URL of > the IANA registry. Yes, this is better. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mai

Re: [IPsec] #122: Integrity proposals with combined algorithms

At 11:34 AM -0500 11/25/09, Scott C Moonen wrote: > > MUST either offer no integrity algorithm or a single integrity algorithm of > > "none" >> >> Does anyone have a problem with this new wording? > >I suggest we specify that one or the other as the preferred approach. Maybe >add an additional s

Re: [IPsec] #122: Integrity proposals with combined algorithms

> MUST either offer no integrity algorithm or a single integrity algorithm of "none", with no integrity algorithm being the preferred method Sounds good, thanks, Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Paul Hoff

[IPsec] I-D ACTION:draft-ietf-ipsecme-aes-ctr-ikev2-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 Author(s) :

Re: [IPsec] WESP - Roadmap Ahead

> >> Now, assume that we were using WESP. >> >> You would need just two rules in your filter database saying the >> following: >> >> Incoming Pkt is WESP integrity Protected, then look at the nth bit and >> if its a OSPF HELLO, put it in Ospfv3HighPrioQueue. >> Incoming Pkt is WESP integrity Protec

[IPsec] draft-ietf-ipsecme-aes-ctr-ikev2-03 was submitted

Dear IPsec people, The updated version of draft-ietf-ipsecme-aes-ctr-ikev2 was just submitted: http://www.ietf.org/staging/draft-ietf-ipsecme-aes-ctr-ikev2-03.txt Abstract: This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit initialization vect