Draft Minutes for IETF-62 KINK Meeting

--=-=-=

Sorry for taking so long to get these out.  Please let me know if I've
missed anything.

-derek


--=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=minutes-62.txt
Content-Transfer-Encoding: quoted-printable
Content-Description: Draft Minutes from KINK at IETF-62

KINK Working Group
IETF-62
Friday, March 11, 2005

Co-Chairs: Derek Atkins and John Trostle

Minutes, edited from the jabber logs.

- Agenda Bashing

Nothing to add.  We swapped some ordering due to time constraints.

- draft-ietf-kink-kink editorial status

The editor is not here.
We should have a document by next ietf.

- rfc1510 v krb-clarifications / kcrypto

Ken Raeburn, "kerberos and kink"
  summary of changes from 1510.  quite a lot of changes, presenting
  ones relevant to kink.  crypto split out into separate doc, treat as
  black box.  fixed some bugs, cleaned up asn.1.  compatibility with
  existing implementations rather than older spec.  add ability to
  extend kerberos protocol in future.  krb-error did not get checksum
  added as shown in some of the krb-revisions drafts.  crypto rfc3961,
  black box crypto.  simple operations/attributes.  operations - how
  to generate keys from passphrase, random bits.  req'd checksum for
  each cryptosystem.  pseudorandom function based on encryption key;
  takes string of arb. bits, gives back random output string for key
  gen, other purposes.  encryption/decryption have integrity checking
  built in (lit describes as authenticated encryption).  treated as
  inseparable; newer auth encryption modes may make it difficult to
  separate them anyway.  encryption not deterministic (all
  cryposystems use rand confounder).  no assumption of fixed length
  output.  decrypt w/verf; may have padding octets at end, so length
  may change on decryption (doesn't matter for krb due to asn.1
  framing).  checksum systems - MAC, not hash functions; fns to
  generate/verify.  output not necessarily deterministic ... or fixed
  length.

question: what cksumtype have we defined already that's nondeterministic?

Jeff Hutzelman says md5-des, etc. are confounded i think

Sam Hartman: I believe some of the DES cksumtypes are nondeterministic
 [ verifies later that des-mac is non-deterministic ]

- 2401 v. 2401bis

Derek Atkins presents as Steve Kent could not attend.

Derek: steve couldn't be here today; he sent me a list.
  unfortunately he sent in email, so I cobbled together slides

Jeff H: are these slides available online?

Derek: download 2401bis; the list is in there.

Sam H: The slides are verbatim out of draft-ietf-ipsec-rfc2401bis

Derek: Processing model has been changed to address new scenarios.=20
  There is a new database - peer authorization database (PAD), which
  provides a link between IKE and SPD.  The processing model based on
  decorrelation of the SPD; allows caching of SPD entries.  If an
  implementation uses a decorrelated SPD, it should send the list of
  linked, decorrelated SPD entries via IKE v2 when negotiating an SA
  There is no longer a requirement to support nested SA's or "SA
  bundles"; instead this can be achieved through SPD and forwarding
  table configuration SPD entries were redefined to provide more
  flexibility.  TOS (IPv4) and traffic class (IPv6) have been replaced
  by DSCP and ECN.  The tunnel section has been updated to explain how
  to handle DSCP and ECN bits.  DSCP values may be copied from a
  tunnel header to the inner header by a receiver, based on per-sa
  configuration controls.  [10:26:35 AM] <jhutz> for tunnel mode SA's,
  an SG, BITS, or BITW implementation is now allowed to fragment
  before applying IPsec.  This applies only to IPv4; for v6 only the
  originator may may fragment.  2401bis clarifies that for all
  traffic crossing the ipsec boundary (including ipsec management
  traffic), the SPD or associated caches must be consulted.

Sam H: the problem here is there are apparently a lot of impls that
  will take an incoming packet, find a key to decrypt it, and accept
  it, without bothering to check whether it's on the right SA

Mike Thomas: does that affect KINK?

Derek: 2401bis defines how to handle the situation of an SG with
  multiple subscribers requiring different IPsec contexts a definition
  of reserved SPIs has been added.  text has been added explaining why
  ALL IP packets must be checked -- ipsec includes minimal firewall
  functionality to support access control at the IP layer

Mike T: It would be nice to get to the ones that might affect us

Derek: I know not all of these apply directly to KINK; steve didn't filter =
for me.

Sam H: Yes it would; this is not the most useful presentation.  Steve
  Kent didn't have much time to prepare it.

Derek: The tunnel section has been updated to clarify how to handle
  the ip options field and Ipv6 extension headers when constructing
  the outer header.  SA mapping for inbound traffic has been updated
  to be consistent with changes made in ah and esp for support of
  unicast, anycast, and multicast SAs.  Guidance has been added wrt
  how to handle covert channel created in tunnel mode by copying the
  dscp value to outer header.  Support for AH in IPv4 and IPv6 no
  longer required.  PMTU handling has been updated.  Appendix on
  PMTU/DF/fragmentation deleted.  Added text saying "The IPSP WG is a
  possible future source of guidance.  One of their goals is to
  produce an ID on a "Security Discovery, Policy Exchange, and
  Negotiation Protocol."

Sam H: we just closed IPSP

Derek: Three approaches have been added for handling plaintext
  fragments on the protected side of the ipsec boundary.  Added
  revised text describing how to derive selector values for SAs (from
  the SPD entry or from the packet, etc).  Added a new table
  describeing the relationship between selector values in an SPD
  entry, the PFP flag, and resulting selector values in the
  corresponding SAD entry.  Added appendix B to describe
  decorrelation.  Added text describing how to handle an outbound
  packet which must be discarded.  Added text describing how to handle
  a discarded inbound packet (one that does not match SA on which it
  arrive).  IPv6 mobility header has been added as a possible
  next-layer protocol.  IPv6 mobility header message type has been
  added as a selector.  ICMP message type, code have been added as
  selectors.  Selector "data sensitiviy level" has been removed to
  simplify things.  Updated text describing handling ICMP error
  messages.  appendix on "categorization of ICMP messages" has been
  deleted.  Text for the selector name has been updated and clarified.
  The "next layer protocol" has been further explained and a default
  list of protocols to skip when looking for NLP has been added.  The
  text has been amended to say this doc assumes use of IKEv2 or an SA
  management protocol with comparable features.  Text has been added
  clarifying the algorithm for mapping inbound IPsec datagrams to SAs
  in the presence of multicast SAs.  The appendix "sequence space
  window code example" has been removed.  WRT IP addres and ports, the
  terms "local" and "remote" are used for policy rules (repl. "source"
  and "destination").  "Local" refers to the entiy being protected by
  the ipsec impl; "remote" refers to a peer entity(s).  The terms
  "source" and "destination" still used for packet header fields.

Any questions/comments?

Mike T: maybe have derek go through the list quickly and see if
  anybody believes it affects us.  did any of them actually affect kink at =
all?

Tero Kivenin: Discusses the changes.

Jeff H: yeah, the part abouf "IKEv2 or an SA management protocol with
  comparable features" affects KINK none of the rest sounded to me
  like it was of much interest to kink

Mike T: Ask tero whether we can have a normative reference to ikev2's
  sa creation payloads like we did with ikev1 to pick up these
  features?  So here's my take: we can either just live with 2401 SA
  right now, put capability for 2401 and 2401bis into this draft, or
  have a second rfc to update vor 2401bis features

Sam H: I expect 2401bis to clear the IESG "very soon"

Mike T: I sort of like the latter.  We directly use ikv1 sa creation
  by normatively referencing it.  Part of this is that I'm not sure
  about the upgrade strategy.  So if we can normatively reference
  parts of ikev2 in a future draft, that would make it a lot easier.
  We really don't want two different ways to access 2401bis
  negotiation, I think.

[ People seem to agree ]

Sam H: Tero, do you think that would be OK?

Tero: <shakes head> [ meaning yes ]

- discussion of open issues

KAMADA Ken'ichi : KINK issue list update  (see slides)

[ update on issue list; most issues were closed.  only three issues remain =
open ]

Jeff H: do we think kink needs its own key usages, or can it use the app nu=
mbers?

Jeff H: so, can anyone think of a reason why the U2U case shouldn't be
  simplified by having the initiator send his TGT, and making the
  responder talk to the KDC? =A0I'm not sure, but it seems like that
  would save a full round trip.  Of course, you still have the problem
  of telling when to use U2U.

Mike T: I don't think that works... if I remember correctly

Derek: as I recall it can be a DoS attack against the responder.

Jeff H: Hm.  yeah, I suppose that could be argued.  the question is
  whether it is worthwhile to save a round trip at the expense of
  having to deal with the potential DoS in some less-good way (like
  rate limiting SA creation)

Sam H: Having a network request that requires another service to do a
  network request is not desirable.  I.E. if you are initiating
  something, you should have to go do the leg work of talking to the
  KDC.

Mike T: They may in fact be disjoint connectivitywise with the kdc's.
  Say the one kdc is behind a firewall...

Jeff H: if they don't both have connectivity to the KDC, how did the
  responder get its tickets?  But sam's point is well-taken.

Sam H: U2U cross-realm is the interesting case

Mike T: I still don't understand 12 -- can ken talk about it?

Jeff H: Ken left, and I don't remember what 12 is (it's not on the srceen a=
nymore)

Sam H: What is 12?

Derek: #12 [**] Subsession keys (section 5 and 8)
       Are subsession keys ignored?  (Ken Raeburn)

Sam H: I can discuss 12 if you like.

Jeff H: I think discussing 12 is a good idea.  Discussing u2u might
  also be a good idea, but I'm not sure if it can be solved today.

Jeff H: I'd like to touch on key usages.  I'm fairly happy with the
  resolutions I saw to the other Kerberos-related issues the KRB-ERROR
  proposal annoys me, but we don't yet provide what you need and you
  may not want to wait for RFC1510ter to be published.

Sam H: You really do not want to wait for 1510ter

Mike T: right... I'm cool with nuking the krb-error keying

Jeff H: 1510ter is supposed to go to WGLC by august..  If that
  happens, I'd guess it would be published around this time next year.
  It could take longer...

Sam H: #12.  field in ap-req for subsession keys in gssapi, key in
  tkt..  client proposes a key in its message.  acceptor proposes a
  new key, using client key and session key.  acceptors key is used.
  - another option: diff keys in different directions
  - another: not use subkey

Sam H: issue: session key could be long-lived

Mike T: but isn't the subkey as well??  it's in the same ticket

Derek: matatcisco: no, subkey is in AP-REQ

Jeff H: no.  a subkey can be negotiated for each AP-REQ/AP-REP.  So
  reusing the same kerberos ticket for another connectioin/session
  does not mean you have to reuse the same key.

Mike T: so our use of nonce is the moral equivalent of the subsession key.

Jeff H: It might be; I've not read that part of your doc in enough detail y=
et.

Sam H: propose same thing as gssapi..  client subkey overrides session
  key; server subkey overrides client subkey re nonce: no, it's not
  integrated into the crypto

Mike T: yes it does!  it's used to generate the key!

Jeff H: Mike, can you give me a ref to the part of the document I
  should look at for this?

Mike T: if we're using kcrypto, does that imply use of the subsession
  key I don't know what that means!

Sam H: no..  subsession key is an optional field.  "MUST not send.
  SHOULD ignore on receive".  we should take to the list.

Mike T: my feeling is that if it ain't broken now, we shouldn't change it

Jeff H: No. =A0kcrypto has no effect on this question

Mike T: which issue are we on?
Derek: 37
Mike: thanks

Jeff H: at first glance, the key derivation described in section 8
  looks like the use of the nonce is sufficient to make it not
  necessary to use subkeys.

Derek: good.  that means our conclusion to #12 is okay.
Jeff: correct

Jeff H: we can use key usages, send mail to cliff to get them
  registered.  we don't need to wait until 1510ter.

Mike: mic!

Jeff H: yes, I think your conclusion to #12 is ok

Sam H: I think we can close #37 if there is consensus on the new text for s=
ection 8

Derek: #37.  Assume 37 is closed.  Note that sam will have to read/review i=
ke.

Jeff H: oh...  one of the nonce's is non-optional, right?

Sam H: 4.3 wasn't enough detail for NULL/zero-length string.

Derek: okay.  37 closed.


Derek: Okay, #2.  when do you use U2U?  Pad?  decide which principle
  to use?  use PAD?

Mike T: pad? what is that?
Derek: PAD is a 2401bis concept

Sam H: KINK has principle of remote host in the PAD.  Auth based on
  errors from kdc.  other side must have way to say "use U2U this
  time"

  I think KINK needs to know in advance what principal it's
  going to talk to, whether it is U2U or not.  Obviously if it's not
  U2U, you have to know what service to request a ticket for.  But
  even in the U2U case, you can't just trust the other guy's assertion
  of what principal you should auth to.

  Three issues:
  (1) what principal to use -- needs to be in PAD
  (2) whether to use U2U -- PAD, or learning from remote side.
      you can use KDC errors for optimization, but can't depend on them.
  (3) in cross-realm U2U, in what realm do you rendesvous?

Mike T: I don't think we violate the "depend" maxim

Jeff H: initiator gets ticket in target realm

Sam H: people believe it will work with the target's realm.  if that's
  the case, it is clearly the right thing.

Mike T: that's how it was all explained to me by matt hur and sasha
  right... this was discussed in great depth a long time ago

Jeff H: this morning I read the expired -06 draft, since nothing newer
  was in the I-D repository.  In that document, the intiator was
  supposed to send a TGT-REQ and do U2U if and only if it got an error
  from the KDC indicating it "can't get a service ticket" for the
  responder.

Mike T: me too :)
Mike T (to Jeff H): yep

Jeff H: The problem with that is the KDC can't always know that -- the
  issue is whether the responder knows its key/password, or only has
  tickets presumably you can't get a service ticket for a PKINIT-only
  client, but there can be other cases where you have to use U2U

Mike T: only work...

Jeff H: When the next version of the document is published, I'll look at it

Mike T: ok... it's going to take me a while to slog through it... I
  can honestly use some help on the kcrypto stuff...

Jeff H: raeburn's your man for kcrypto.  but it's really pretty
  straightforward, or at least we hope it is.

Mike T: mostly it's my vague familiarity, and getting the wordsmithing
  correct yeah, I guess I can take a stab at it and send him the
  sections to see if they look right

Jeff H: probably not a bad idea

--=-=-=


-- 
       Derek Atkins                 617-623-3745
       [email protected]             www.ihtfp.com
       Computer and Internet Security Consultant

--=-=-=--