headers
Jan Vilhuber | 1 Nov 2002 06:05
Picon
Favicon

RE: I-D ACTION:draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt

Presumably only passive wiretapping kinds of attacks.

<joking>
Maybe we should standardize the april fools draft-rfc pre-shared key
for IKE as the default password for plug-and-play ipsec?
</joking>

I'm not sure if this is a really good idea or a really bad one (as a
professional paranoiac, I tend towards the later).

Bad idea? False sense of security because now everyone thinks they are being
protected by ipsec (and really aren't, at least not terribly much)?

or

Good idea? A quick way to roll standard IPsec out to the masses with a
clean upgrade path: start deploying real pre-shared keys or
certificates (or dnssec or whatever) and use the tasty goat key only
if all else fails (still leaving the impression we're very secure when
we're not?)?

Hm... tasty goat, if I do say so myself ;) Can you make me one?

jan

On Thu, 31 Oct 2002 rcharlet <at> SonicWALL.com wrote:

> Howdy,
>
> 	What threat would this succeed in averting?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charlie_Kaufman | 1 Nov 2002 16:04
Picon

Re: A question about traffic selector

<wmyking49 <at> yahoo.com.cn> wrote:
> I read the doc draft-ietf-ipsec-ikev2-03.txt, and i'm
> confused by the description about traffic selector.
> The follow is in 4.9:
> It is possible for the Responder's policy to contain
> multiple smaller ranges, all encompassed by the
> Initiator's traffic selector, and with the Responder's
> policy being that each of those ranges should be sent
> over a different SA. Continuing the example above, Bob
> might have a policy of being willing to tunnel those
> addresses to and from Alice, but might require that
> each address pair be on a separately negotiated
> child-SA. If Alice generated her request in response
> to an incoming packet from 10.2.16.43 to 18.16.2.123,
> there would be no way for Bob to determine which pair
> of addresses it is most urgent to  tunnel, and he
> would have to make his best guess or reject the
> request with a status of SINGLE-PAIR-REQUIRED.
>
> 1.What is it means that "might require that each
> address pair be on a separately negotiated child-SA"?
> If is the "each address pair" imply a pair of a single
> address, such as 10.2.16.43 and 18.16.2.123?

Yes. The current RFC on the configuration database for
IPsec says that an endpoint may have a policy that each
pair of tunnelled addresses gets it's own SA. This means
a <source, destination> pair of individual IP addresses.

> 2.The sentence "If Alice generated her request in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hoffman / VPNC | 3 Nov 2002 00:46

Fwd: Last Call: IPsec Configuration Policy Model to Proposed Standard

Earlier this week, the IESG issued the following announcement. Those 
folks here who care about IPsec policy management but haven't been 
active in the IPSP WG should definitely take a look at the documents 
that are now in IETF-wide last call.

--Paul Hoffman, Director
--VPN Consortium

>To: IETF-Announce: ;
>Cc: ipsec-policy <at> vpnc.org
>From: The IESG <iesg-secretary <at> ietf.org>
>SUBJECT: Last Call: IPsec Configuration Policy Model to Proposed Standard
>Reply-to: iesg <at> ietf.org
>Date: Mon, 28 Oct 2002 14:55:53 -0500
>Sender: owner-ipsec-policy <at> mail.vpnc.org
>List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
>List-ID: <ipsec-policy.vpnc.org>
>List-Unsubscribe: <mailto:ipsec-policy-request <at> vpnc.org?body=unsubscribe>
>
>
>
>The IESG has received a request from the IP Security Policy Working
>Group to consider publication of the following Internet-Drafts
>as Proposed Standards:
>
>  o IPsec Configuration Policy Model
>	<draft-ietf-ipsp-config-policy-model-06.txt> 
>  o IPSec Policy Information Base
>	<draft-ietf-ipsp-ipsecpib-05.txt>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charlie_Kaufman | 4 Nov 2002 02:25
Picon

Re: Fwd: Re: IKEv2 Key Size Conformance Requirements


Based on this discussion, I propose change the MUST requirements to 1024
and 2048 bit RSA keys (both public and private), with a MAY for all other
sizes. I would expect most implementations would implement a large
collection of sizes, but this avoids unnecessary growth of the testing
matrix. (And yes, I'll fix the wording so that the MUST requirements have
the keyword MUST in them).

Objections? I'm concerned about the following:

Bill Sommerfeld <sommerfeld <at> east.sun.com> wrote:
> For what it's worth, I'll repeat what I said last time.. *in real
> life* I've seen both PGP and SSH implementations generate keys with
> moduli which were a bit or two shorter than the desired size.

Key generation implementations that pick random primes sometimes come up
with moduli a bit or two shorter than they had intended. There is something
to be said for explicitly allowing them by requiring support for such
moduli. On the other hand, at one time the default CSP that shipped with
Microsoft Windows had a restriction that it could only work with moduli
that were a multiple of 8 bits (or was it 16 bits?) long. When I inquired
at the time, I was told that they knew about the problem but had no plans
to fix it. I don't know whether they have. There may be other
implementations around with similar restrictions, so there is something to
be said for disallowing keys that would break those implementations. My
opinion is that the conservative course is to only require support of 1024
and 2048 bit keys, but I really don't much care (so long as we make a
decision).

What about DSS keys? I made them a MUST in my draft, and one person
(Continue reading)

Permalink | Reply | 12 comments |
headers
Stephen Kent | 4 Nov 2002 18:27
Picon

Re: Fwd: Re: IKEv2 Key Size Conformance Requirements

At 8:25 PM -0500 11/3/02, Charlie_Kaufman <at> notesdev.ibm.com wrote:
>Based on this discussion, I propose change the MUST requirements to 1024
>and 2048 bit RSA keys (both public and private), with a MAY for all other
>sizes. I would expect most implementations would implement a large
>collection of sizes, but this avoids unnecessary growth of the testing
>matrix. (And yes, I'll fix the wording so that the MUST requirements have
>the keyword MUST in them).
>
>Objections? I'm concerned about the following:
>
>Bill Sommerfeld <sommerfeld <at> east.sun.com> wrote:
>>  For what it's worth, I'll repeat what I said last time.. *in real
>>  life* I've seen both PGP and SSH implementations generate keys with
>>  moduli which were a bit or two shorter than the desired size.
>
>Key generation implementations that pick random primes sometimes come up
>with moduli a bit or two shorter than they had intended. There is something
>to be said for explicitly allowing them by requiring support for such
>moduli. On the other hand, at one time the default CSP that shipped with
>Microsoft Windows had a restriction that it could only work with moduli
>that were a multiple of 8 bits (or was it 16 bits?) long. When I inquired
>at the time, I was told that they knew about the problem but had no plans
>to fix it. I don't know whether they have. There may be other
>implementations around with similar restrictions, so there is something to
>be said for disallowing keys that would break those implementations. My
>opinion is that the conservative course is to only require support of 1024
>and 2048 bit keys, but I really don't much care (so long as we make a
>decision).
>
>What about DSS keys? I made them a MUST in my draft, and one person
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geoffrey Huang | 1 Nov 2002 22:36
Picon
Favicon

RE: Dead peer detection

Hi Ed,

The draft has expired, but I've attached a copy of it.  I'd like to move the
draft forward (wherever that might be), but the focus in the WG lately has
been on IKEv2.

> I have wondered around the working groups site and could not find the
> draft-ietf-ipsec-dpd-00.txt any longer nor could I find any on going
> conversations on the subject.  Was this draft allowed to expire
> without any
> further discussions, or was another draft started.
> I understand that some products do "dead peer detection" and was wondering
> if this draft was how it was to be done or if the use of lower
> re-key timer

This is the method that Cisco devices use.

> (say 600 seconds) in phase one would have the same effect, if one was to
> delete the phase 2 sa's if the phase one negotiations failed.

It depends on your implementation.  If you always maintain a Phase 1 SA
("Continuous Channel Mode") when there are Phase 2 SAs, then doing as you
propose might be one solution.  Keep in mind, however, that it won't scale
well if you have to frequently rekey.  Essentially, you'd be using a Phase 1
negotiation to do the DPD; the difference is that DPD involves 2 notify
messages (a "hello" and an ACK).  Using a Phase 1 for DPD requires at least
3 messages, plus a DH...Added to this is the concern that 600 seconds might
be too coarse an interval before detecting a black hole.

-g
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 4 Nov 2002 17:16
Picon
Picon
Picon
Favicon

Re: Fwd: Re: IKEv2 Key Size Conformance Requirements

Charlie_Kaufman <at> notesdev.ibm.com writes:
>Bill Sommerfeld <sommerfeld <at> east.sun.com> wrote:
>>For what it's worth, I'll repeat what I said last time.. *in real
>>life* I've seen both PGP and SSH implementations generate keys with
>>moduli which were a bit or two shorter than the desired size.
>
>Key generation implementations that pick random primes sometimes come up with
>moduli a bit or two shorter than they had intended.

The PGP missing-bits problem was in old 2.x versions.  5.x used bnlib for its
bignum work which had code in there to ensure that if you asked for n bits,
you got exactly n bits (from memory I think it set the high bits to ensure
that the number is exactly n bits long, i.e. 2^(n-1) <= number < 2^n).  I
assume newer versions still use the same code.  SSH (specifically OpenSSH)
does odd things with its keygen, including setting e=35, so I don't think
that's a good example to follow.

>What about DSS keys?

I've heard of those.  I've even got one or two DSA certs, you can find them
"rare species" section of the museum.  It's right next to the "mythological
creatures" section, which holds the X9.42 DH certs.

Peter.
Permalink | Reply | 0 comments |
headers
Bill Sommerfeld | 4 Nov 2002 19:13
Picon

Re: Fwd: Re: IKEv2 Key Size Conformance Requirements

> My opinion is that the conservative course is to only require
> support of 1024 and 2048 bit keys, but I really don't much care (so
> long as we make a decision).

Unless someone can demonstrate there's a meaningful difference in
security between a 1022-bit and a 1024-bit key, may I suggest that
Postel's rule of thumb ("Be liberal in what you accept and
conservative in what you send") applies here?

 - MUST generate keys with moduli which are exactly at these bit sizes
 - SHOULD accept keys with moduli even if slightly smaller than the mandatory 
sizes.

					- Bill
Permalink | Reply | 10 comments |
headers
Teemu Alakoski | 4 Nov 2002 11:03
Picon
Picon

Public key distribution methods?

Hi,

I'm writing my diploma thesis about key exchange and public key
distribution in IPSec environment. 

I would like to know what are opinions on this list concerning different
ways to distribute public keys for use in IKE/IKEv2 authentication. I have 
understood that LDAPv3 is the strongest candidate for this purpose, and 
another mechanism is DNS TXT RRs as described in 
draft-richardson-ipsec-opportunistic -draft. Are there other mechanisms that 
should be taken into consideration?

Or should I be asking this on the pkix mailing list?

Thanks
Teemu Alakoski
Permalink | Reply | 5 comments |
headers
Stephen Kent | 4 Nov 2002 20:10
Picon

Re: Public key distribution methods?

At 12:03 PM +0200 11/4/02, Teemu Alakoski wrote:
>Hi,
>
>I'm writing my diploma thesis about key exchange and public key
>distribution in IPSec environment.
>
>I would like to know what are opinions on this list concerning different
>ways to distribute public keys for use in IKE/IKEv2 authentication. I have
>understood that LDAPv3 is the strongest candidate for this purpose, and
>another mechanism is DNS TXT RRs as described in
>draft-richardson-ipsec-opportunistic -draft. Are there other mechanisms that
>should be taken into consideration?
>
>Or should I be asking this on the pkix mailing list?
>
>Thanks
>Teemu Alakoski

Teemu,

Since IKE has provisions to "push" certs and CRLs to an IPsec (IKE) 
peer, neither DNS nor LDAP is needed as a means to distribute these 
data items. Note that unlike e-mail, where a sender needs to know the 
cert for a recipient before the sender can encrypt a message for that 
recipient, IPsec as a realtime protocol can exchange all of the PKI 
data items needed during the SA establishment procedure.

To be fair, there are some limitations with this approach. First, it 
means moving more bits across the wire during SA establishment, and 
we have seen some problems re fragmentation when the IKE UDP packets
(Continue reading)

Permalink | Reply | 4 comments |

Gmane