headers
Amol Deshmukh | 1 Aug 2002 07:39

Keying Material

Hi,
    I am trying to interop, our IKE implementation with Cisco.
    From the keying material generated, the keys for
encryption/authentication are created. There is no way to find out if the
keys generated at both ends are the same.
    Could anyone please help me in this.

Thanks in advance,
-Amol.
Permalink | Reply | 3 comments |
headers
William Dixon | 1 Aug 2002 07:33
Picon
Favicon

RE: Clarification of potential NAT multiple client solutions

Jayant, what exactly do you mean by the "ipsec-passthu" technique ?  

-----Original Message-----
From: Jayant Shukla [mailto:jshukla <at> trlokom.com] 
Sent: Wednesday, July 31, 2002 2:54 PM
To: Brian Swander; ipsec <at> lists.tislabs.com
Subject: RE: Clarification of potential NAT multiple client solutions 

> -----Original Message-----
> From: owner-ipsec <at> lists.tislabs.com
[mailto:owner-ipsec <at> lists.tislabs.com]
> On Behalf Of Brian Swander

> Bottom line is that there are a variety of solutions for this
scenario.

o.k.! 

> 3. upper layer protocol awareness of the inbound & outbound IPsec SA 
> (where it doesn't use source IP and source port as the session
identifier.
> E.g. L2TP session ID mapped to the IPsec SA pair which doesn't use the
UDP
> source port or source IP address for peer uniqueness)

Why not just use IPsec pass-thru? Instead of mapping the L2TP ID to the
IPsec SA, just use information from the IPsec SA. 

> 4. application integration with IKE initiation such that it can rebind
to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Korver | 1 Aug 2002 07:58

Re: CERT REQ payload Handling Clarification

"Suresh Singh K." wrote:
> 
> Hi ,
>      Please clarify the following Issue for CERT REQ payload Handling :
> 
>       As the encoding of a CA 's  DN  into the CERT_REQ payload
> is done using BER ,one should be able to encode it using DER only
> (as DER is subset of BER). And the other end's BER decoding  software
> should be able to decode the DER encoding.
>      For decoding , we cannot assume that the other end with always
> encode the CA's DN in DER only. He can encode using the other
> two BER encoding method , in which case we should be able to
> decode any of the 3 encoding method for BER, including DER.
> 
> 
> Thanks in advance,
> 
>        Suresh
> 

Suresh,

I'm not aware of any restriction on DER vs. BER in the CERTREQ payload,
but you're probably right that you can't assume the other end will
always send DER.  But that probably doesn't imply that you need to
re-encode to DER.

The most common case is that the sender has the CA certificate that
contains the DN which is then used to populate the CERTREQ payload.
In fact, I would guess that most implementations pull the DN directly
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephane Beaulieu | 1 Aug 2002 15:12
Picon
Favicon

RE: Keying Material

Amol,

We used to have bakeoffs to deal with such issues.  Unfortunately, bakeoffs
are rare these days because most vendors achieved good basic
interoperability years and years ago.

Probably the easiest way to do this is to try sending packets through and
turning on debugging on the Cisco device.  It won't give you the keys, but
it'll tell you if authentication and/or decryption fail.

If your keys are incorrect, try and try again.

You might also want to try and interop with some of the open source IPsec
implementations.  You can probably modify their code to spew out the keys
you're looking for.

Good luck,
Stephane.

> -----Original Message-----
> From: owner-ipsec <at> lists.tislabs.com
> [mailto:owner-ipsec <at> lists.tislabs.com]On Behalf Of Amol Deshmukh
> Sent: Thursday, August 01, 2002 1:40 AM
> To: ipsec <at> lists.tislabs.com
> Subject: Keying Material
>
>
> Hi,
>     I am trying to interop, our IKE implementation with Cisco.
>     From the keying material generated, the keys for
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Richardson | 1 Aug 2002 16:03
Picon

Re: CERT REQ payload Handling Clarification


>>>>> "Ramana" == Ramana Yarlagadda <ramana.yarlagadda <at> analog.com> writes:
    Ramana> I think we have to use only DER encoding here and not the BER.
    Ramana> Becuase the protocol doesn't allow you to negotiate  encoding method .
    Ramana> And so BER encoding is not used in IKE.

  DER is a subset of BER.
  Your parser should always expect BER.

  DER is required in certain situations, which would be well spelt out -
typically under signatures.

  It would be nice if someone would write a seperate Informational document
on using PKIX with IKE.

]       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 | 1 comment |
headers
Rajesh Mohan | 1 Aug 2002 16:40

RE: Keying Material

Amol,

I would recommend you start with OpenBsd implementation. It definetly prints
SKEYID and IV updates to log file. isakmpd man pages will tell you how to
turn on log messages.

HTH,
-Rajesh M

> -----Original Message-----
> From: owner-ipsec <at> lists.tislabs.com
> [mailto:owner-ipsec <at> lists.tislabs.com]On Behalf Of Stephane Beaulieu
> Sent: Thursday, August 01, 2002 6:42 PM
> To: Amol Deshmukh; ipsec <at> lists.tislabs.com
> Subject: RE: Keying Material
>
>
> Amol,
>
> We used to have bakeoffs to deal with such issues.
> Unfortunately, bakeoffs
> are rare these days because most vendors achieved good basic
> interoperability years and years ago.
>
> Probably the easiest way to do this is to try sending packets
> through and
> turning on debugging on the Cisco device.  It won't give you
> the keys, but
> it'll tell you if authentication and/or decryption fail.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Korver | 1 Aug 2002 17:47

Re: CERT REQ payload Handling Clarification

Michael Richardson writes:
>   DER is a subset of BER.
>   Your parser should always expect BER.
>  
>   DER is required in certain situations, which would be well spelt out -
> typically under signatures.
> 
>   It would be nice if someone would write a seperate Informational document
> on using PKIX with IKE.

Although it doesn't answer this question (yet), the intention of
draft-ietf-ipsec-pki-profile-00.txt is to address these sorts of
issues (of which there are many).

-brian
briank <at> briank.com
Permalink | Reply | 0 comments |
headers
Brian Swander | 1 Aug 2002 18:48
Picon
Favicon

RE: Clarification of potential NAT multiple client solutions

There are lots of problems with that form of passthru with transport
mode.  Just a couple: 

1. if you have multiple simultaneous connections behind the NAT, the NAT
will have difficulty mapping the unseen spis from the external host to
the outgoing SPI it has seen since it only uses time proximity and no
better smarts.  This problem also exists for tunnel mode passthru.  So
it cannot claim to be an industrial strength solution.
2. Still have the demux issues of multiple clients behind the same NAT
talking to the same external server
3. Still need to modify IKE to get the negotiation to succeed (QM
proxies addrs at least)
4. Still need to deal with the incorrect transport layer xsum

In short, passthru is potentially tolerable for tunnel mode in some
scenarios, but fails pretty badly for transport.

bs

-----Original Message-----
From: Jayant Shukla [mailto:jshukla <at> trlokom.com] 
Sent: Thursday, August 01, 2002 9:36 AM
To: William Dixon; Brian Swander; ipsec <at> lists.tislabs.com
Subject: RE: Clarification of potential NAT multiple client solutions 

Hi William,

I am referring to the method used by NAT boxes to let IKE & IPsec
traffic pass through based on cookies and SPI. It is the same method
that caused problem for the earlier version of your draft that required
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jayant Shukla | 1 Aug 2002 18:35

RE: Clarification of potential NAT multiple client solutions

Hi William,

I am referring to the method used by NAT boxes to let IKE & IPsec
traffic pass through based on cookies and SPI. It is the same method
that caused problem for the earlier version of your draft that required
eight bytes of zeros to be inserted after the UDP header.

Regards,
Jayant
www.trlokom.com 

> -----Original Message-----
> From: owner-ipsec <at> lists.tislabs.com 
> [mailto:owner-ipsec <at> lists.tislabs.com] On Behalf Of William Dixon
> Sent: Wednesday, July 31, 2002 10:33 PM
> To: Jayant Shukla; Brian Swander; ipsec <at> lists.tislabs.com
> Subject: RE: Clarification of potential NAT multiple client solutions 
> 
> 
> Jayant, what exactly do you mean by the "ipsec-passthu" technique ?  
> 
> -----Original Message-----
> From: Jayant Shukla [mailto:jshukla <at> trlokom.com] 
> Sent: Wednesday, July 31, 2002 2:54 PM
> To: Brian Swander; ipsec <at> lists.tislabs.com
> Subject: RE: Clarification of potential NAT multiple client solutions 
> 
> 
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Fluhrer | 1 Aug 2002 18:33
Picon
Favicon

Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt

At 07:04 AM 7/30/02 , Uri Blumenthal wrote:
>
>Plus, IV doesn't REALLY have to be random. It's something people are 
>talking about now because of the threat brought up by S. Fluhrer when
>more than one user sits on one SA.

This appears that this needs to be emphasized -- CBC has IVs and the
current counter mode draft has IVs, but they're not really the same
thing, and they do not have the same constraints on them.  A few months
ago, I pointed out a weakness in CBC mode with predictable IVs.  This
weakness is specific to how CBC mode works, and counter mode with
predictable IVs has no corresponding weakness.  The only constraint on
counter mode is that the IVs never repeat.

--

-- 
scott
Permalink | Reply | 0 comments |

Gmane