Subject: [Ipsec] Re: Ipsec Digest, Vol 22, Issue 1

From: Basudev achary <[email-masked]>
Date: Thu, 2 Feb 2006 12:28:53 +0530

Hi all ,
             In configure the IPsec VPN in PIX 252 model , if  Phase 1 is
connected and  phase 2 is not connected then what is error msgs is diaplay
on console /????

On 2/1/06, [email-masked] <[email-masked]> wrote:
>
> Send Ipsec mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www1.ietf.org/mailman/listinfo/ipsec
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ipsec digest..."
>
>
> Today's Topics:
>
>    1. Bug in IKEv2 shared secret authentication? (Thomas Otto)
>    2. RE: Bug in IKEv2 shared secret authentication?
>       ([email-masked])
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 1 Feb 2006 09:08:00 +0100
> From: Thomas Otto <[email-masked]>
> Subject: [Ipsec] Bug in IKEv2 shared secret authentication?
> To: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> Hi all,
>
> in case of shared secret based authentication, the AUTH payload is
> computed as
>
>   AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
>
> if the shared secret is a password or derived from a password,
> IKEv2 suggests to store prf ( shared secret, "Key Pad for IKEv2") rather
> than shared secret itself in the configuration file.
>
> However, since the prf is negotiated during the IKE_SA_INIT exchange,
> the question arises which prf shall be applied here.
>
> Is the "inner" prf pre-negotiated perhaps? Must the configuration file
> store the hash of all supported prfs (hmac-md5, hmac-sha1, hmac-tiger,
> aes128-xcbc)?
>
> I have found a related thread in the IPsec mailing list, which points out,
> that the inner prf has been introduced to accomodate handling with prfs
> which need a fixed-size key (instead of a key of arbitrary length).
>
> Can anyone clarify?
>
> Thomas
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 1 Feb 2006 10:45:28 +0200
> From: [email-masked]
> Subject: RE: [Ipsec] Bug in IKEv2 shared secret authentication?
> To: <[email-masked]>, <[email-masked]>
> Message-ID:
>         <[email-masked]>
> Content-Type: text/plain;       charset="iso-8859-1"
>
>
> Hi Thomas,
>
> You're quite right in that the PRF is negotiated -- and this
> context is not an exception.
>
> In my opinion, the most likely options are probably (1) having a
> policy which allows only one PRF, so only one stored hash is needed,
> (2) storing several hash values as you suggest, or (3) just storing
> the plain shared secret instead of the hash.
>
> Choosing between these is an implementation detail not specified
> in the protocol spec.
>
> About PRFs with fixed-size keys: now that 3664bis has been approved,
> we don't have any of those left (and I hope we don't specify any;
> the clarifications document spent quite a lot of time on those...).
>
> Best regards,
> Pasi
>
> > -----Original Message-----
> > From: Thomas Otto
> > Sent: 01 February, 2006 10:08
> > To: [email-masked]
> > Subject: [Ipsec] Bug in IKEv2 shared secret authentication?
> >
> > Hi all,
> >
> > in case of shared secret based authentication, the AUTH payload is
> > computed as
> >
> > AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
> >
> > if the shared secret is a password or derived from a password,
> > IKEv2 suggests to store prf ( shared secret, "Key Pad for
> > IKEv2") rather than shared secret itself in the configuration file.
> >
> > However, since the prf is negotiated during the IKE_SA_INIT exchange,
> > the question arises which prf shall be applied here.
> >
> > Is the "inner" prf pre-negotiated perhaps? Must the configuration file
> > store the hash of all supported prfs (hmac-md5, hmac-sha1, hmac-tiger,
> > aes128-xcbc)?
> >
> > I have found a related thread in the IPsec mailing list, which
> > points out, that the inner prf has been introduced to accomodate
> > handling with prfs which need a fixed-size key (instead of a key of
> > arbitrary length).
> >
> > Can anyone clarify?
> >
> > Thomas
>
>
>
> ------------------------------
>
> _______________________________________________
> Ipsec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipsec
>
>
> End of Ipsec Digest, Vol 22, Issue 1
> ************************************
>

--
Thanking U
P.Basudev
Mob: 09886242840
Email: [email-masked]
          [email-masked]
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec