Re: Status of Seamoby drafts

> the point is even if CTP were to be a proposed standard, it
> shouldnt be specifying what cryptographic suites to use.
> thats part of IPsec specs.
>

Yes.

How about:

The details of IKE key exchange and other details of the IPsec security
associations between routers ->
The details of the security associations between routers



            jak

> Vijay
>
> James Kempf wrote:
>
> > Vijay,
> >
> > Thanx for your comments, they essentially echo what I sent to Dave in
email
> > yesterday.
> >
> > Basically, since CTP is an experimental protocol, I'm proposing to Dave
that
> > the operational considerations for CTP security be worked out as part of
the
> > process of preparing it for reintroduction to Standards Track. In
addition,
> > there is a WG already working on routing protocol security. I think it
would
> > simplify configuration if CTP security could reuse as much of that work
as
> > possible (for example, the certificate profile) to avoid duplication.
> > Therefore, I've proposed to add the following text to the draft at the
end
> > of Section 6.2:
> >
> >     The details of IKE key exchange and other details of the IPsec
security
> >     associations between routers are to be determined as part of the
> >     research phase associated with finalizing the protocol for
> >     standardization. Prior to standardization, these details must be
> >     determined. Other working groups are currently working on general
> >     security for routing protocols. Ideally, a solution for CTP will be
> > based
> >     on this work, in order to minimize operational configuration of
routers
> >     for different protocols. Requirements for CTP will be brought to the
> >     appropriate IETF routing protocol security working groups for
> >     consideration.
> >
> >         jak
> >
> >
> >
> > ----- Original Message ----- 
> > From: "Vijay Devarapalli" <[email protected]>
> > To: "James Kempf" <[email protected]>
> > Cc: <[email protected]>
> > Sent: Thursday, July 15, 2004 11:04 AM
> > Subject: Re: [Seamoby] Status of Seamoby drafts
> >
> >
> >
> >>Jim,
> >>
> >>
> >>>draft-ietf-ctp: OPS AD Dave Kessens had some major Discuss comments
> >
> > about
> >
> >>>the lack of detail in the definition of how IKE is used, and lack of
> >>>discussion of "correctness" such as in draft-ietf-eap-keying. I'm
> >
> > currently
> >
> >>>working with Dave and Allison to resolve the Discuss.
> >>
> >>I looked up the security comments from the OPS directorate.
> >>
> >
> >
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=839&filename=draft-ietf-seamoby-ctp
> >
> >>>For example, Section 6.2 talks about using of IKE to dynamically
> >
> > negotiate
> >
> >>>keys for protection of Inter-Router traffic.  However, it doesn't say
> >
> > what
> >
> >>>IKE modes need to be implemented, or what IPsec ciphersuites are
> >
> > required.
> >
> >>this doesnt make a lot of sense to me.
> >>
> >>we can only say that there must be confidentiality protection
> >>for the secure channel between the access routers. we also say
> >>ESP in transport mode must be used. we also say a non-null
> >>encryption algorithm is to be used.
> >>
> >>implementations have to follow IPsec specifications.
> >>
> >>
> >
> >
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05.txt
> >
> >>specifies what algorithms to use with IKE.
> >>
> >>http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-06.txt
> >>specifies what cryptographic suites to use with IPsec.
> >>
> >>CTP actually doesnt care which cipher suites or algorithms from
> >>the above two drafts are used as long as the requirements for
> >>non-null encryption algorithm, authentication, and confidentiality
> >>protection is achieved.
> >>
> >>
> >>>Since context transfer security is an n by n problem, establishing the
> >
> > SAs
> >
> >>>to protect inter-router transfers is not an easy thing.  For this reaso
n
> >
> > one
> >
> >>>might conclude that pre-shared keys are difficult, since n(n-1) of them
> >>>would be necessary.  On the other hand, is it being suggested that each
> >>>router needs to be provisioned with a certificate? On reading the draft
> >
> > it
> >
> >>>isn't clear what's being recommended (or even considered).
> >>
> >>this comment is valid. but since we assume the access routers are
> >>part of the same administrative domain, they are provisioned with
> >>the required certificates to run IKE. (?)
> >>
> >>Vijay
> >>
> >>
> >>
> >>
> >
> >
> >
>
>