headers
Mohammad Awad | 1 Sep 2002 22:13
Picon
Favicon

the first message to responder

Hi all:
Is this scenario, the truth.
the responder must receive the first packet from the initiator
(e.g. src(10.1.1.1:333) dst(127.22.3.45:21)) to look it up in his SPD and 
decide upon the security services that must br afforded.
if it is that, what can be the link between this first message (from 
initiator), and the next ISAKMP one that begins the negotiation. Isn't it 
important to link those two messages to exponentiate that the same 
application/peer has them both?
thanx all

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com
Permalink | Reply | 0 comments |
headers
Michael Richardson | 2 Sep 2002 16:47
Picon

Re: suites - phase 1 vs 2


>>>>> "Charlie" == Charlie Kaufman <Charlie_Kaufman <at> notesdev.ibm.com> writes:
    Charlie> I'm trying not to use the terms phase 1 and phase 2 algorithms
    Charlie> because phase 1 negotiates both an IKE-SA and a Child-SA (ESP
    Charlie> and/or AH and/or IPcomp).  I believe the definition of a suite
    Charlie> should include the protocol it is securing. That means we need a
    Charlie> minimum of two suites: one of IKE and one for ESP. People are

  okay. agreed.

    Charlie> likely to want additional suites for ESP+IPcomp, for AH, and for
    Charlie> who knows what other combinations. If suites are independent of

  I think that we have ESP suites like:

  1) 3DES/MD5  (i.e. no IPcomp)
  2) 3DES/SHA1
  3) 3DES/MD5/LZS
  4) AES/SHA1/LZS
  ...

  that is, I'm pretty sure that we want the IPcomp choice (or not) to be part
of the ESP suite, not a seperate list.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr <at> sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
Permalink | Reply | 2 comments |
headers
Jerry Yao | 2 Sep 2002 16:04
Picon

Re: Clarification of potential NAT multiple client solutions

I think to solve the conflicts described in draft-ietf-ipsec-udp-encaps-03.txt sections 5.2 and 5.3, we
should include the port as a part of selector, than the server can pick out the corresponding SA to protect
the packets that send to clients behind the NAT. Is there any problem to involve port as a part of selector?

> We have had requests to clarify potential solutions to problem of multiple clients behind the same NAT
simultaneously connecting to the same destination IP address. draft-ietf-ipsec-udp-encaps-03.txt
sections 5.2 and 5.3 say you MUST avoid the problem.  Therefore you must implement some kind of solution for
this problem.  If your solution is not to support the scenario, you can still interoperate with others and
support just one client behind the same NAT with SA state to you at any one time.
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-03.txt
Permalink | Reply | 0 comments |
headers
S Lal | 3 Sep 2002 08:05
Picon
Favicon

Reg. ICMP handling in IPsec


Hi Ricky,

I find your description very useful as it complimnets the section 6 of RFC 
2401.

It seems that ICMP handling in IPsec is going to more prorietary way. But, 
how does the products will support the SPD entries with requiremnet that 
there should be a SA for Ping packets but separate action for ICMP errors ?

I have few questions regarding handling of ICMP messages from R1 to SGw1.
Based on the presence of SPI, you have marked that the message is meant for 
E1'. So, did you assume that SGw1 is acting as purely router and it does not 
support any of the managemnet applications like telnet/snmp which may use 
transport mode SAs. If SGw1 is supporting the both kinds of SAs, then how it 
will determine that the message is intended for me or the n/w supported 
behind me , i.e. E1' .

regards

To: ipsec <ipsec <at> lists.tislabs.com>
Subject: ICMP in IPSec
From: Ricky Charlet <rcharlet <at> redcreek.com>
Date: Fri, 14 May 1999 21:04:45 +0000
Organization: RedCreek Communications Inc.
Sender: owner-ipsec <at> lists.tislabs.com

--------------------------------------------------------------------------------

Howdy ()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Housley, Russ | 3 Sep 2002 18:21

RE: Last ditch proposal for crypto suites

Phill:

I think the SHOULD is the way to handle the key size issue.
Here is how the S/MIME WG addressed this issue in RFC 2633.

    A user agent SHOULD generate RSA key pairs at a minimum key size of
    768 bits. A user agent MUST NOT generate RSA key pairs less than 512
    bits long. Creating keys longer than 1024 bits may cause some older
    S/MIME receiving agents to not be able to verify signatures, but
    gives better security and is therefore valuable. A receiving agent
    SHOULD be able to verify signatures with keys of any size over 512
    bits. Some agents created in the United States have chosen to create
    512 bit keys in order to get more advantageous export licenses.
    However, 512 bit keys are considered by many to be cryptographically
    insecure.  Implementors should be aware that multiple (active) key
    pairs may be associated with a single individual. For example, one
    key pair may be used to support confidentiality, while a different
    key pair may be used for authentication.

Russ

At 08:49 AM 8/30/2002 -0700, Hallam-Baker, Phillip wrote:
>I don't think we should spec the RSA keystrengths since this is not
>typically a negotiated parameter, the parties tend to have one key and the
>trustworthiness of that key is the issue.
>
>i.e. the endpoint may reject a key because it does not accept the
>certificate (or other validation). If an end point rejects 1024 bit keys as
>a matter of policy that will be incorporated into the certification policy.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Touch | 3 Sep 2002 18:41
Picon
Favicon

Re: ICMP error generation

Sabrina Minshall wrote:
> Hi All,
>   suppose a VPN gateway encrypts a packet and the next hop to the
>   tunnel (endpoint) is unreachable. What should be done? Should
>   the packet be dropped (without generating an ICMP host/net
>   unreachable?).
> 
>   sabrina

This is more of a tunnel issue.

RFC2003, although not exactly what IPsec specifies, addresses these 
issues for IP-encapsulation tunnels already.

Notably Sec 3.2 says the packet SHOULD be dropped, and Sec 4.1 says that 
an ICMP Unreachable SHOULD be returned.

RFC2401 addresses the IPsec-specific version, which includes some 
additional filtering rules which do not appear to preclude 2003-style 
handling.

Joe
Permalink | Reply | 0 comments |
headers
Dan McDonald | 3 Sep 2002 18:18
Picon

Re: suites - phase 1 vs 2

>   I think that we have ESP suites like:
> 
>   1) 3DES/MD5  (i.e. no IPcomp)
>   2) 3DES/SHA1
>   3) 3DES/MD5/LZS
>   4) AES/SHA1/LZS
>   ...
> 
>   that is, I'm pretty sure that we want the IPcomp choice (or not) to be part
> of the ESP suite, not a seperate list.

You either need to also include AH (whether it's there or not), OR you need
to treat AH, ESP, and IPcomp as separate protocols.  You can't just include
subsets.  You need to either treat the whole problem, or decompose the
problem completely.

Dan
Permalink | Reply | 1 comment |
headers
Michael Richardson | 3 Sep 2002 18:58
Picon

Re: suites - phase 1 vs 2


>>>>> "Dan" == Dan McDonald <danmcd <at> east.sun.com> writes:
    >> 1) 3DES/MD5  (i.e. no IPcomp)
    >> 2) 3DES/SHA1
    >> 3) 3DES/MD5/LZS
    >> 4) AES/SHA1/LZS
    >> ...
    >> 
    >> that is, I'm pretty sure that we want the IPcomp choice (or not) to be part
    >> of the ESP suite, not a seperate list.

    Dan> You either need to also include AH (whether it's there or not), OR
    Dan> you need 
    Dan> to treat AH, ESP, and IPcomp as separate protocols.  You can't just
    Dan> include 

  I would actually prefer to do the former - include AH or not.
  This gets rid of the various debates about 
       IP ESP AH IP
vs     IP AH ESP IP
vs     IP AH IP ESP IP
...

  This becomes part of the ciphersuite. I think that ciphersuites would then
essentially become use cases. Does that give us too many of them? I doubt it.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr <at> sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
(Continue reading)

Permalink | Reply | 0 comments |
headers
Feng Ye | 4 Sep 2002 06:05
Picon
Favicon

IPSec NAT pass-through: how the server side distinguish different client?

Hello,

I have implemented IPSec NAT pass through in the
access box by looking at cookie/SPI values. I can
sucessfully do the 1 to 1 and 1 to many cases, but
can't do the many to 1 case, because I don't know how
to configure the public side VPN server. 
That server don't know how to distinguish different
clients behind the NAT, because they all have the same
tunnel endpoint IP address (the NAT public address),
and they all use ESP, and the same
encrypt/authenticate algorithm. So to the server, all
of them belongs to the same SA. Captured packets in
the server side shows that even different clients use
different SPI to talk to the server, the server
responses with the same SPI, thus caused the problem.
I tested with cisco 2600 and win2000 as the VPN
server, all has the same problem.
Is anybody there can give me a clue? Thanks a lot!

feng

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
Permalink | Reply | 1 comment |
headers
climbor | 4 Sep 2002 04:28

Question about KE payload

Hi all,

Here is my question:
How to construct the KE payload if there are multiple SA in the first Quick message and each SA have different
PFS group (say group 1 and group 2)? Construct multiple KE payload too? Or just select the longer one? Or
this is just a invalid case (Netscreen support multiple SA with different PFS group, I guest so from its manual)?

thanks
Permalink | Reply | 1 comment |

Gmane