Subject: direction address type

From: Sam Hartman <[email-masked]>
Date: Mon, 8 Apr 2002 16:26:45 -0400 (EDT)

At the meeting here at MIT, John and I discussed the directional
address type.  The main concern I had was I didn't know how to perform
negotiations to see when you could use the address type.  John pointed
out recently that the address type would be useful without any
negotiation mechanism.  In particular, it would be useful in
situations where both parties to a krb_mk_priv or krb_mk_safe already
know the other party supports.  For example this could be used to
resolve one of my comments about the set-password draft.

It is my intent to write up text for Cliff that adds such an address
type for clarifications.  I believe this is consistent with the
discussion at MIT; our concern about having directional address type
for clarifications was semantic; no one seemed to object to including
it if it could be defined.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 09 Apr 2002 09:41:06 -0500

> it if it could be defined.

Yes, sounds like a good idea. 

For extensions, we should also look at address ranges, or an address mask.
I see too many situations where one would like to treat a cluster as a
single machine. The cluster may have 100s of nodes, with multiple interfaces
per node. But these addresses are always in a sub net, so one or two ranges
could represent the cluster, rather then hundreds. I understand that 
the current method breaks down with about 50 addresses. So the method
used today, is to use no addresses. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 9 Apr 2002 11:23:11 -0400

> used today, is to use no addresses. 

I would prefer/like to have a hostname host address type and push the
matter to the name service. Yes, DNS is not secure, no, not many people
use DNSSEC, and so on. But a hostname host address type seems like the
right thing to me and as secure as the name service.

An address range/mask address type will only be useful in very specific
circumstances.

Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 9 Apr 2002 09:08:49 -0700 (PDT)

> An address range/mask address type will only be useful in very specific

   One thing consider here is that mobility makes you
   want to steer well clear of using IP addresses as
   any form of identity. Looking at the larger
   picture here is probably a good idea.

		Mike

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 09 Apr 2002 15:03:30 -0500

What we are really trying to do is make sure the credentials are being
used form the correct host. The addresses in the tickets was an attempt
at this. 

Well, what could we do if we had DNSSEC? 

What about dynamic DNS? 

The change to add address ranges was meant to facilitate the use of the IP address
in environments where it still made sense. This does not preclude other better methods
to pin down the misuse of a ticket. 

--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 9 Apr 2002 20:13:27 -0700 (PDT)

> to pin down the misuse of a ticket. 

As I said, mobility really wants you to think
about this really hard. Essentially, mobility is
like multihoming with a semi-infinite number of
interfaces -- ie, Sam's scenario from hell. That
is, you might get a message from a care of address
that you cannot predict. Thus, using the IP
address as a form of identity -- or a second line
of defense as I suspect is the case here -- is
going to break whenever you move. Considering that
there's much to recommend about Kerberos
mechanisms for mobility (especially for fast
handoffs), it would be nice to try to solve this
outside of the domain of yet another klunky
overloading of IP address semantics as a form of
identity.  They rilly, rilly are just routing tags
after all even though it's a usage mistake that's
as common as dirt.

		Mike

---

From: Derek Atkins <[email-masked]>
Date: 10 Apr 2002 00:13:11 -0400

True, your CareOf address may change, but your HOME
address wont.  And _that_ is what gets put in the ticket.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 10 Apr 2002 11:42:06 -0500

> address wont.  And _that_ is what gets put in the ticket.

The goal is to prove a ticket is being used from the
intended host. Another way to do this is to have the host
which is trying to use a ticket prove its identify. This 
could be done by using a host key. This could be a
Kerberos server principal, a user principal (proves the
user is using the ticket) or a PKI key from DNSSEC.
There are lots of issues, like every device needs a key,
the host needs to be involved with using a ticket, where in the
past this has been done by the application. 

But there are still situations where there are static
IP addresses, without NAT that could benefit from using 
the address range. It is not a large change, so I would 
still like to see it in extensions. 

--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 10 Apr 2002 12:46:32 -0400

> still like to see it in extensions. 

How complicated do you envision this address type to be? Ranges might
need exclusions, for example.

I figure two SEQUENCEs of IP-RANGE-OR-IP-MASK, the first sequence being
a list of exclusions and IP-RANGE-OR-IP-MASK being a CHOICE of
IPv4-RANGE, IPv6-RANGE, IPv4-MASK and IPv6-MASK should do.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 10 Apr 2002 13:08:02 -0400

On Wed, Apr 10, 2002 at 07:04:47PM +0200, Johan Danielsson wrote:
> Nicolas Williams <[email-masked]> writes:
> 
> You don't need to complicate things with exclusions, just add multiple
> ranges.

Exclusions would be a space optimization. Hopefully there's no need for
it. But then, I would prefer to have a secure name services and a
hostname address type. Can't the GSS-TSIG stuff for DNS be leveraged
into a kerberized DNS? A cheap alternative to DNSSEC? Thoughts for some
other list. Sigh.

> /Johan

Cheers,

Nico

---

From: Sam Hartman <[email-masked]>
Date: 10 Apr 2002 13:56:22 -0400

Doug, we agreed to drop the address type entirely from krb_safe and
krb_priv for extensions.

We agreed to consider hostname and other address types for tickets,
but I think I'd need to see a concrete proposal that included how
you'll authenticate things before I could go for that.

I'm mostly assuming almost all uses of extensions will have null
addresses.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 11 Apr 2002 15:00:09 -0500

> I'm mostly assuming almost all uses of extensions will have null

One way would be to give a start and end address of a range.
 
HostAddress ::=     SEQUENCE  {
                    addr-type[0]             Int32,
                    address[1]               OCTET STRING
                    address-end[2]           OCTET STRING OPTIONAL
}

Where the interpretation of the address-end is dependent on the addr-type.
It might only work on IPv4, where lower bits of the address are usually
associated with a sub net and all the addresses in the range are included. 
IPv4 would treat the addresses as 32 bit numbers. 

How would this ASN.1 be treated by current implementations? Would they
ignore the optional address-end, or complain? 

--

---

From: Sam Hartman <[email-masked]>
Date: 11 Apr 2002 16:02:38 -0400

>>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

    Douglas> One way would be to give a start and end address of a
    Douglas> range.

Sure, but this provides no actual authentication.  The discussions in
the meeting seemed more about having some way to bind the host key to
the tickets, so you'd have to use some host identifier along with the
ticket to  get a TGS request to work.

I'd argue that actual IP-address based security just doesn't buy
anything today.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Apr 2002 16:21:21 -0400

> I'd argue that actual IP-address based security just doesn't buy

Indeed. With Kerberos tickets I see the use of HostAddress as a
mitigation that acheives little unless a number of other things are in
place, such as strong ISNs (and that is not possible with TCP - 32-bits
are just not enough). But technology changes, and HostAddress may well
prove useful in time (think SCTP, Secure DNS), so while I think it
should not really be used it should still be supported in extensions.

The directional HostAddress won't hurt though.

Nico

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 12 Apr 2002 15:18:35 -0500

> ticket to  get a TGS request to work.

Yes, actually two discussions. 
> I'd argue that actual IP-address based security just doesn't buy

Yes, it is looking more and more like the IP address is becoming useless. 
But as Nick points out it might be more usefull in the future. 

--