Subject: Re: [Seamoby] comments on CAR Discovery Requirements

From: "Hemant Chaskar" <[email-masked]>
Date: Sat, 16 Mar 2002 23:03:18

Hi Eunsoo,

In the CAR case, verifying "authenticity of sender" does involve verifying 
that it is your GAAR. This is because, here sender cannot be an arbitrary IP 
device, it has to be a GAAR. Otherwise, an AR can be trapped into exchanging 
capabilities with a bunch of ARs which are not actually its GAARs. The 
non-GAARs can then overwhelm AR with their capabilities and cause DOS 
attack.

Hemant

>From: "Eunsoo Shim" <[email-masked]>
>To: <[email-masked]>
>Subject: Re: [Seamoby] comments on CAR Discovery Requirements
>Date: Sat, 16 Mar 2002 18:34:43 -0800
>
>I mean the purpose of security is to verify the authenticity of the message
>sender and the integrity of the message rather than the correctness of the
>information contained in the message. I think whether the claimed GAAR is
>indeed a GAAR is about the correctness of the information.
>Thanks.
>
>Eunsoo
>----- Original Message -----
>From: "Eunsoo Shim" <[email-masked]>
>To: <[email-masked]>
>Sent: Saturday, March 16, 2002 4:05 PM
>Subject: Re: [Seamoby] comments on CAR Discovery Requirements
>
>
> > Hemant,
> >
> > I think it is very difficult to verify that the AR claiming to be a GAAR
>is
> > indeed a GAAR even though it is very desirable. So I'd be reluctant to 
>put
> > it as a requirement.
> > I have no problem about verifying the authenticity of a router.
> >
> > > > a) The solution MUST provide means for an AR to to verify that 
>another
> > > AR
> > > > claiming to be its GAAR is genuine. In other words, the other AR is
> > > indeed a
> > > > GAAR and it is an authentic router.
> >
> > Thanks.
> >
> > Eunsoo
> >
> > > ----- Original Message -----
> > > From: "Hemant Chaskar" <[email-masked]>
> > > To: <[email-masked]>
> > > Sent: Thursday, March 14, 2002 11:00 PM
> > > Subject: Re: [Seamoby] comments on CAR Discovery Requirements
> > >
> > >
> > > > Hi James:
> > > >
> > > > Rather than starting from scratch again in Minneapolis, may I 
>propose
> > > that
> > > > we start from the following baseline text for security requirements. 
>I
> > > think
> > > > this text very clearly and explicitly brings out the security issues
> > > > involved. If any additional statements are needed we can fill them 
>in.
> > > Sorry
> > > > to repeat this, but I did not see any reference to earlier 
>discussion
> > > on
> > > > this text in Hesham's email.
> > > >
> > > > "Solution to CAR discovery  MUST address the security concerns
> > > involved in
> > > > the various aspects such as GAAR discovery, capability exchange and
> > > CAR
> > > > selection. In particular,
> > > >
> > > > a) The solution MUST provide means for an AR to to verify that 
>another
> > > AR
> > > > claiming to be its GAAR is genuine. In other words, the other AR is
> > > indeed a
> > > > GAAR and it is an authentic router. The authenticity of a router MAY
> > > mean
> > > > that it is authorized to act as an access router by the jurisdiction
> > > of the
> > > > environment (operator network, organizatoinal LAN, home network 
>etc.)
> > > that
> > > > the router resides in.
> > > >
> > > > b)It MUST provide means for secure capability exchange between an AR
> > > and its
> > > > GAAR.
> > > >
> > > > c)It MUST provide secure means for the expression of MN requirements
> > > to CAR
> > > > selection algorithms."
> > > >
> > > > Regards,
> > > > Hemant
> > > >
> > > > >From: "James Kempf" <[email-masked]>
> > > > >To: "Hesham Soliman \(ERA\)" <[email-masked]>,
> > > > >"'Govind Krishnamurthi'" <[email-masked]>, <[email-masked]>
> > > > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements
> > > > >Date: Thu, 14 Mar 2002 14:34:29 -0800
> > > > >
> > > > >Hesham,
> > > > >
> > > > > >   > Re. the comments on security, maybe we need a more
> > > > > >   > comprehensive threat
> > > > > >   > analysis such as Claude did for paging?
> > > > > >   > The requirement I did was pretty generic.
> > > > > >
> > > > > > => Agreed. No need for a separate doc. This
> > > > > > is what I was hinting at when I said 'I can try'.
> > > > > > Because this is something that will take time.
> > > > > >
> > > > >
> > > > >Good, let's talk about this in the Minne-apple.
> > > > >Maybe we can get together a small group
> > > > >of volunteers to help. It should
> > > > >not take much time, and I agree that we
> > > > >don't need a separate document, but
> > > > >I think we need something more than
> > > > >we have now.
> > > > >
> > > > >             jak
> > > > >
> > > > >
> > > > >_______________________________________________
> > > > >Seamoby mailing list
> > > > >[email-masked]
> > > > >https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > > >
> > > > _________________________________________________________________
> > > > Join the world's largest e-mail service with MSN Hotmail.
> > > > http://www.hotmail.com
> > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
> > _______________________________________________
> > Seamoby mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>_______________________________________________
>Seamoby mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/seamoby

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Mon, 18 Mar 2002 08:07:29 -0800

Hemant,

The purpose of putting authentiation onf any GAAR information is
precisely to allow a receive to trust that the information came from a
reliable source. The only other way a receiver could determine that a
router claiming to be a GAAR is, in fact, a GAAR would be to get
information from another source that it trusted and compare it. But how
would the receiver trust that? Putting a signature on the GAAR
information and requiring a trust relationship ensures that the receiver
can trust the GAAR information.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 18 Mar 2002 08:07:29 -0800

Hemant,

            jak

---

From: "Phil Neumiller \(N9FCW\)" <[email-masked]>
Date: Mon, 18 Mar 2002 20:38:25 -0500

What makes you so sure of this James?  Security concerns belong in the 
security WG.   I guess  I have said this about 100 times now.  Recall that
the charter of the WG deals with seamless mobility, not security.

---

From: "Phil Neumiller \(N9FCW\)" <[email-masked]>
Date: Mon, 18 Mar 2002 20:38:25 -0500

---

From: "James Kempf" <[email-masked]>
Date: Mon, 18 Mar 2002 18:08:27 -0800

Phil,

Every Internet draft is required to have a section called "Security
Considerations." This section must deal with how the particular protocol
or standard handles security. There has been a history in IETF of saying
"use IPsec" in this section (commonly called "IPsec pixie dust"), thus
putting the burden of security design for the protocol on the IPsec WG
(in effect, deferring it). In the last year, this has changed and the
IESG has been requiring that the sections contain more substance saying
specifically how the protocol will use IPsec, if the WG proposes that it
should, or explicitly describing how security is done if not.

The theory behind pushing security back on the WG is that the WG is in a
better position to know what the security solutions are for their
particular protocol than the IPsec WG. Not that everybody in the WG
should necessarily care, but at least someone with some security
background and interest should.

Thus, the security groups like IPsec and IKE now concern themselves
specifically with protocols that do security and not with the security
design for other protocols. It is analgous with MIBs. The SNMP working
group doesn't do MIBs for other protocols, they work on SNMP.

            jak

PS: If you don't like it, then I'd suggest you complain at the IESG
Plenium on Thurs. nite if you are in Minneapolis, or to someone from the
IESG  Security Area Directorate if not.

----- Original Message -----
From: "Phil Neumiller (N9FCW)" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Hemant Chaskar"
<[email-masked]>; <[email-masked]>
Sent: Monday, March 18, 2002 5:38 PM
Subject: Re: [Seamoby] Verifying that a sender is a GAAR

---

From: "James Kempf" <[email-masked]>
Date: Mon, 18 Mar 2002 18:08:27 -0800

Phil,

            jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 19 Mar 2002 11:26:02 -0800

Hi, Phil,

I am not sure a single WG can look into all the protocols being designed in
the IETF and provide proper security solutions in time.
There must be lots of common requirements and possibility of using common
infrastructure/tools but each protocol may also have considerations for
security specific to it. And such considerations should be done at the same
time when the protocol is designed, I believe.
Thanks.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 19 Mar 2002 11:26:02 -0800

Hi, Phil,

Eunsoo

---

From: "Phil Neumiller \(N9FCW\)" <[email-masked]>
Date: Tue, 19 Mar 2002 20:33:27 -0500

Thanks for the reminder Jim.  I just see soooo much discussion about
security in MIP and
now SeaMoby that it seems to detract from the real issues sometimes and bog
things down.
Maybe I believe too much in security Pixie dust.... :-)    BTW, there are
some nice commercial
options becoming available with small foot prints for embedded devices with
full PKI
implementations.  These packages can solve many of the problems that are
discussed, however,
they are not necessarilly IETF created (not invented here).  Is it possible
to specify a level of
encryption that is required and the necessary hooks and leave the
implementation up to
network equipment vendors/manufacturers or does the IETF have to solve the
worlds problems?

Best regards,

-Phil
----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Phil Neumiller (N9FCW)" <[email-masked]>; "Hemant
Chaskar" <[email-masked]>; <[email-masked]>
Sent: Monday, March 18, 2002 9:08 PM
Subject: Re: [Seamoby] Verifying that a sender is a GAAR

---

From: "Phil Neumiller \(N9FCW\)" <[email-masked]>
Date: Tue, 19 Mar 2002 20:33:27 -0500

Best regards,

-Phil

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Mar 2002 17:44:47 -0800

>Is it possible

Not only is it possible, it is desirable.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Mar 2002 17:44:47 -0800

jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Mar 2002 19:33:12 -0800

> > network equipment vendors/manufacturers or does the IETF have to
solve
> the

All right, there seems to be some misunderstanding about my response,
based on the private email I'm getting.

The level of detail in the security part of the specification has to be
high
enough that it is possible to implement the specification so that
it interoperates. Thus, it is possible to allow vendors to add value
in areas such as, for example, the cryptographic algorithms. It is
desirable because
progress in cryptographic alogrithms is constant, so specifying one
single cryptographic algorithm risks having the spec quickly become
obsolete (or crackable, given increases in computing power).
Additionally, it is very desirable to specify defaults that are
nonIPR encumbered, while leaving space for other algorithms
that may have IPR. Thus, specifying DES with the option for
RSA (though I guess now the patent has expired on RSA,
so it is not a good example) or another proprietary algorithm is an
example.
Of course, if there is no good nonIPR encumbered alternative,
then there is no choice.

Hope that is clearer...

                jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Mar 2002 19:33:12 -0800

solve

Hope that is clearer...

                jak