Subject: [Ietf-krb-wg] Kerberos WG IETF72 meeting summary

From: Larry Zhu <[email-masked]>
Date: Thu, 31 Jul 2008 05:11:27 -0700

This is a SUMMARY of the Kerberos WG meeting held this week in Dublin of Ireland as part of the 72st IETF meeting. Full minutes will be posted on a later date.

-- larry

Kerberos Working Group - IETF 72 meeting summary

ACTION ITEMS:
* Nicolas Williams - send an updated version of set-change password
* Chairs - finish review and writeup of cross-realm problem statement
* Larry Zhu – respond to one last comment to the naming draft
* Larry Zhu – follow up on the remaining comments for the anonymous ID
* Leif Johansson – summarize discussions on missing attributes in the data model document
* Gareth Richard – respond to existing and future comments for the OTP currently in WGLC
* Sam Hartman and Larry Zhu – resolving open issues in the Kerberos preauth framework document
* Larry Zhu and Tim Polk – validation of KDF test vectors and followup
* Shoichi Sakane – Explain to the list why DNS is not acceptable for the DHCPv6 options.
* chairs – writeup of summary of starttls discussion
*shawn Emery – update the hash agility document per agreements in last meeting and the list
* Larry Zhu – refresh IAKERB and get it ready for WGLC

DECISIONS (to be validated):
* “SHOULD” remove AD-INITIAL-VERIFIED-CAS in the anonymos draft
* restrict anonymous PKINIT to full anonymous and turn off KDC’s ability to add back partial anonymity
* add a padata to PKINIT to enforce the ticket session is derived from the DH or ECDH exchange.

SESSION SUMMARY:

We reviewed the status of several documents that are working their way
through the queue, and discussed several documents which have recently
concluded IETF or Working Group Last Call.

·         The set-change password document is waiting for an updated version which the author didn't quite get in before the meeting, and then it will go to Tim and the IESG.

·         The cross-realm problem statement document finished WG last call some time ago, and has been waiting for the chairs to finish their review and writeup.

·         All issues for PKINIT ECC document has been resolved and is waiting for go-ahead from Tim.

·         There were comments for missing attributes in the data-model documents. Leif is to follow up with a summary of discussion to the list. A new revision and another last call are expected.

·         There were a few remaining issues for the anonymous draft, and a new revision is expected. No decision is made whether another last call is necessary.  The working group had two decision to be validated on the list: 1) SHOULD” remove AD-INITIAL-VERIFIED-CAS in the anonymos draft, 2) restrict anonymous PKINIT to full anonymous and turn off KDC’s ability to add back partial anonymity

·         There is one comment unresolved for the naming draft and it is expected to be straightforward.

·         The last revision of the hash agility document does not address all the comments, and Shawn is to publish a new revision.

·         The PKINIT KDF document need test vectors to be validated.

The OTP document is currently in working group last call.

We then proceeded to the technical discussion section. Sam Hartman reviewed recent updates to the Preauth Framework document and discussed open issues. We discussed a MITM issue under one specific configuration where the channel is established using anonymous Diffie-Hellman. This issue was discovered in the context of the encrypted challenge preauth data type introduced in the last revision, and the working group discussed several options to fix the issue. One way to fix it is to combine the long term key with the replaced key. We discussed unique channel binding using anonymous PKINIT. In addition, we will add a padata to PKINIT to combine the reply key with the ticket session key thus no party can unilaterally determine the ticket session key. The ticket key is later used in Kerberos preauth framework in naming the outer channel, with the additional change to combine the client session key and ticket session to form the armor key, no party can unilaterally determine the armor key.

At the open mic, Shoichi Sakane mentioned the proposal he brought to
the dhc working group to create a DHCPv6 option for identifying a KDC. There is no support in the working group and Shoichi is asked to explain to the list why DNS is not acceptable in the applicable environment.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Jul 2008 11:26:25 -0400

How would you feel about a DHCP option structure that included 
1) a default realm
2) a set of 0 or more mappings from realm to KDC IP address?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nobuo OKABE <[email-masked]>
Date: Thu, 31 Jul 2008 15:34:44 +0100 (IST)

Hi all,

As pointed out int the meeting, we summarized reasons
why DHCP-based KDC discovery is more suitable than
the existing KDC discovery described in RFC4120
for the industrial systems.

From: Larry Zhu <[email-masked]>
Subject: [Ietf-krb-wg] Kerberos WG IETF72 meeting summary
Date: Thu, 31 Jul 2008 05:11:27 -0700

> the dhc working group to create a DHCPv6 option for identifying a KDC. There is no support in the working group and Shoichi is asked to explain to the list why DNS is not acceptable in the applicab…

========================================================================
1. Summary

   - The scope of this memo is industrial systems,
     such as PA (Process Automation), FA (Factory Automation) and
     BA (Building Automation).

   - This memo describes reasons why DHCP-based KDC discovery
     is more suitable than DNS-based KDC discovery described
     in RFC4120 (= the RFC4120-way) for the industrial systems.

   - The main reason is that some industrial systems don't use DNS
     because they have already had their own name spaces and
     naming systems rather than FQDN and DNS.

   - Less servers benefits the industrial systems:
     1) Less messages simplifying the systems.
     2) Less servers contributing reliability,
        and reducing management cost.

   - We understand that RFC4120 does not require DHCP for KDC discovery.
     However, we will have to solve DNS discovery
     when considering the RFC4120-way.
     And it is natural way to use DHCP for the purpose.

   - DHCP-based KDC discovery is more efficient under those
     systems (=expecting not to use DNS).

   - Please read the followings for the details.

2. Background (what's industrial systems?)

   Industrial systems, such as PA (Process Automation),
   FA (Factory Automation) and BA (Building Automation),
   are a kind of sensor systems.
   The systems have a large number of devices, i.e. sensors and actuators,
   usually called field devices
   by which the systems control plants, factories, buildings, etc...

   The field devices have the following features:
   1) Their resources, e.g. processing capability, memory size,
      footprint, power consumption and user i/f, are limited
      even though they are physically large.
   2) The field device is controlled as an I/O by a administrative device,
      usually called controller, with a legacy communication technology.
   3) Security of the field devices have not been cared
      because they are regarded as being on I/O buses, not networks.

3. High-level goal and some requirements

3.1. IP and security can enhance the industrial systems.

   Our goal is to introduce latest IP-based network technology
   into field devices for enhancing the entire system.
   1) Network architecture (=IP technology) can enhance
      the systems including the field devices.
   2) The field devices will require security if network architecture
      is introduced. The field devices will not be I/O devices anymore.

3.2. Auto-configuration benefits the industrial systems.

   Auto-configuration will also be important for large systems
   like the industrial systems if introducing new technology or capability:

   1) Reducing engineering cost when installing/configuring
      large number of field devices over spread area.
      The following are existing large systems.
      The size of a plant
      (= the size of an industrial system = the number of field devices)
      is growing.

      - An example of single large PA system:
        About 20000 field devices over 2km*2km area
        http://www.process-worldwide.com/fachartikel/pw_fachartikel_2699276.html

      - An example of distributed PA systems:
        About 30000 field devices for 26 distributed sites
        over 30km*30km area
        http://www.mikrocentrum.nl/FilesPage/3462/Presentatie%20C3-1.pdf
        http://www.nam.nl/home/Framework?siteId=nam-en&FC2=/nam-en/html/iwgen/algemeen/zzz_lhn.html&FC3=/nam-en/html/iwgen/algemeen/over_de_nam.html

      - An example of single large BA system:
        170000 control points of 16500 field devices in
        729,000 sq. meters (7.8 million sq. ft.) building complex.
        http://www.echelon.com/company/press/2003/echelon_mori.htm

   2) Reducing the chance of human error.

   3) Making disaster-recovery easier.

3.3. Security mechanism suited to resouce-limited devices are necessary.

   Kerberos-based security can be suited resouce-limited devices,
   i.e. the field devices, because of not requiring
   public key cryptography (of course, when not using PKINIT).

4. Some industrial systems don't use DNS.

   For field devices, there have been multiple technologies (see Section 6)
   which don't use DNS because of having already had their own name spaces
   and naming systems even though introducing IP (partially at this moment).

   For example, TAG is the common logical identifier for PA systems and
   Device ID is the common logical identifier for BA systems.
   (You may think those names are not so abstracted, though....)

5. KDC discovery with DHCP is more suitable than the one with DNS.

   If Kerberos is introduced into the field devices,
   auto-configuration will be achieved with the following steps:
   1) Learning DNS address(es) by DHCP
   2) Learning KDC address(es) by DNS based on RFC4120-way.
   However, DNS will be used by kerberos-related part only.
   Most application will not use DNS as described above.

   If DHCP can advertise KDC-related information instead of DNS,
   there are the following advantages.
   1) It can reduce messages handled by the field devices.
      Consequently, it can reduce footprint of the field devices.
   2) It can reduce the number of servers.
      Consequently, it contribute to management cost of the systems.

6. References

   There have been multiple technologies for field devices.
   Examples:
   - FOUNDATION Fieldbus (http://www.fieldbus.org/)
   - PROFIBUS (http://www.profibus.com/)
   - BACnet (http://www.bacnet.org/)
   - LonWorks (http://www.echelon.co.jp/products/lonworks.html)
   - Modbus (http://www.modbus.org/)
   - ........

   You can learn about communication technology
   of field devices with wikipedia:
   - http://en.wikipedia.org/wiki/Fieldbus
   - http://en.wikipedia.org/wiki/BACnet
   - http://en.wikipedia.org/wiki/LonWorks
   - .........
========================================================================

thanks,

----- Nobuo Okabe, Ph.D. (Yokogawa Electric Corporation)