Subject: Re: [Ietf-krb-wg] I-D Action:draft-sorce-krbwg-general-pac-00.txt

From: "Thomas Hardjono" <[email-masked]>
Date: Thu, 7 Oct 2010 15:25:23 -0400

Dear JHutz and Larry,

We would like to request this draft to be adopted as a Kerberos WG
work-item. We expect (and hope) it will involve considerable WG
discussions.

Thanks.

/thomas/

______________________

> -----Original Message-----
> From: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, October 07, 2010 3:00 PM
> To: [email-masked]
> Subject: I-D Action:draft-sorce-krbwg-general-pac-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : A Generalized PAC for Kerberos V5
> 	Author(s)       : S. Sorce, et al.
> 	Filename        : draft-sorce-krbwg-general-pac-00.txt
> 	Pages           : 12
> 	Date            : 2010-10-07
> 
> This draft proposes a generalized authorization structure for the
> Kerberos V5 protocol.  Such an authorization structure would allow
for
> greater interoperability among directory services and other related
> Kerberos services across differing realms.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-sorce-krbwg-general-pac-
> 00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 07 Oct 2010 16:18:12 -0400

> work-item. We expect (and hope) it will involve considerable WG

You're certainly welcome to discuss it here and to try to build a consensus 
to do this work.  It is definitely not within the scope of our current 
charter, but of course charters can be amended.

However, before we take on much new work, I'd like to see volunteers to 
help complete some of our existing work(*), or a clear indication from the 
WG that some of those work items are no longer of interest.  Once we have 
that we can begin to formulate a proposal for a charter revision. 
Particularly...

- When we published the GSS-API mechanism update and PKINIT, we committed
  to finish work to address hash algorithm agility in those protocols.
  In both cases, the work is nearly complete but has languished.

- Set/Change Password has been stuck for some time, I believe blocking
  on author cycles.  Is there still interest in the WG in seeing this
  work finished?

- We've seen no movement on referrals in a long time.  I know people are
  implementing and deploying some of the features described in this
  document; we need to get it finished and out the door.

- We still retain responsibility for a number of registries which we
  should be turning over to IANA.  A document has been submitted to
  us to address this; we should adopt this document, come to some
  consensus on registration policies, and get it published.

(*) Note, I'm not saying the existing work needs to be finished before we 
can take on new work, but I need to identify resources to complete the work 
we already have, some of which has been languishing for a long time.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Oct 2010 15:39:21 -0500

> work-item. We expect (and hope) it will involve considerable WG

Thomas, I think you'll be very interested in draft-adamson-nfsv4-multi-
domain-access-03.txt.  As a co-author of that draft, there's a number of
things I'd handle differently in a generic Kerberos PAC than you have
chosen to do in your I-D, mostly regarding the representation of IDs in
the PAC contents.

Nico
--

---

From: Simo Sorce <[email-masked]>
Date: Thu, 7 Oct 2010 16:43:55 -0400

On Thu, 7 Oct 2010 15:39:21 -0500
Nicolas Williams <[email-masked]> wrote:

> Thomas, I think you'll be very interested in
> draft-adamson-nfsv4-multi- domain-access-03.txt.  As a co-author of
> that draft, there's a number of things I'd handle differently in a
> generic Kerberos PAC than you have chosen to do in your I-D, mostly
> regarding the representation of IDs in the PAC contents.

Nico,
would you care to elaborate ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Oct 2010 16:29:53 -0500

> would you care to elaborate ?

Yes, but it would help a lot if we all first read each others' I-Ds.  I
haven't fully digested yours; I doubt you have fully digested ours.

That said, I'll elaborate, but I fear that my elaboration will not be
digestible without reference to draft-adamson-...

IMO the PAC should contain:

 - Various non-ID data associated with the client principal (e.g., home
   directory, possibly given as various different URLs).

 - User and group identities (associated with the client principal) in
   one or more representation forms:

    - REQUIRED: "global representation" form, a term we define in
      section 4 of our I-D, and which is very much like a SID, if not a
      SID

      Your I-D is not clear as to whether these are REQUIRED.

      Also, your I-D insists on using UUIDs to identify domains.  I
      would prefer something more easily mapped to a SID, and, I would
      prefer using SIDs outright.  (Arguably we could use SID authority
      #5, though I'd prefer asking MSFT for a new SID authority or two
      for our purposes.)

    - OPTIONAL: mapped to domain-local representations (which is what
      your I-D provides for)

      Your I-D isn't clear as to whether these are optional.

Perhaps one problem is the lack of normative language in your I-D (which
is understandable, given that it's a -00; our I-D is still missing
significant chunks of text).

Basically, I don't think it's always appropriate, or even always
feasible for a KDC (or similar service) to provide "mapped IDs".

Perhaps a side-trip through how we handle ID mapping in Solaris is in
order?  Short-version:

    OpenSolaris (now defunct), Solaris 11 (soon-to-be), and the OS used
    in our NAS appliance, map non-local SIDs to UIDs/GIDs in an
    "ephemeral" UID/GID range, using a next-available ID scheme.  By
    "ephemeral" we mean that on reboot the mappings are forgotten and
    the next-available ID is reset to the same initial value.

    This may sound crazy, but as long as ephemeral IDs do not leak (on
    disk, on the wire, in archives/backups), it's safe.

    We had the freedom to do this in Solaris because uid_t and gid_t had
    been signed 32-bit integral types and POSIX requires that UIDs and
    GIDs be non-negative, which meant we had almost 2^31 unused values
    of these two types that we could re-purpose for ephemeral ID
    mapping.

    Linux has long had uid_t and gid_t as unsigned 32-bit integral
    types, therefore on Linux one could not borrow any UIDs or GIDs for
    ephemeral ID mapping without an affirmative action on the part of a
    local/site/domain administrator, but it'd still be feasible.

We've been using this ephemeral ID mapping solution for a long time in
shipping products (namely, the NAS appliance).  If you have a system
that can map IDs thusly, then the mapped IDs from your I-D are not as
useful as the IDs in {domain ID, domain-local user/group ID} form, thus
my interest in the latter being REQUIRED.  But also, you might not be
able to produce domain-local "mapped IDs" either -- indeed, we'd likely
find it unacceptable to be forced to provide them.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Oct 2010 16:48:35 -0500

>       #5, though I'd prefer asking MSFT for a new SID authority or two

I should also expand on this.

For interoperability in the SMB protocol, which I'm certain that you'll
want, you'll want to be able to represent user/group IDs from
non-Windows domains as... SIDs.  Recent versions of Windows are picky
regarding the length of SIDs.  And while normal domain/computer SID
sizes can accomodate the 128 bits of a UUID, by convention the first RID
is not at all randomly selected, leaving you with just 96 bits to play
with for casting domain UUIDs to domain SIDs.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Oct 2010 18:46:12 -0500

BTW, I'm very glad that you're proposing a generic PAC.  I think we
should make sure that our two proposals are in harmony.

Some further issues to think about:

 - Rationale for a PAC.

   IMO the best rationale for a PAC is this: it is a directory service
   usage optimization.

   Other rationales include:

    - simplify services (they don't need to know how to lookup
      everything that might appear in a PAC;
    - privacy protection (services lack permission to separately lookup
      some of the data delivered in a PAC).

 - How to identify domains (besides by name).

   IMO we'll want to use either SIDs outright or quantities easily cast
   into SIDs when necessary.  This does not rule out UUIDs.

    - How to enforce domain ID uniqueness.

      IMO, ultimately we'll want some sort of registry, else at least
      methods for detecting and coping with conflicts.

 - LDAP schemes (I need a word that cannot be confused with 'schema')
   models to go with the PAC (see our doc).

   Specifically:

    - how to discover LDAP services for multiple domains;
    - what schemas to expect.

 - What's REQUIRED, RECOMMENDED and what's OPTIONAL.

There's more, but that's a good set of issues to start with.

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 7 Oct 2010 17:38:47 -0700

I, for one, would not be opposed to some description of how to populate PAC data from a generic LDAP.  Trouble is, I doubt we can really do that without specifying schemas.  (Someone prove me wrong, please!)

Another pragmatic issue, which maybe doesn't go in the RFC because maybe it isn't solvable, is what a KDC should do if the source of the PAC information is unavailable.

>    - what schemas to expect.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 03:40:22 +0200

I'd like to see SAML used for this rather than transposing the MS PAC to POSIX :-)

I'd be interested to get Howard Chu and Scott Cantor in on this discussion...

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 04:03:33 +0200

Consider using AD-KDCIssued instead of a server signature: it is specified by RFC 4120 (5.2.6.2).

Also SignedPath (http://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation) is already implemented in MIT and Heimdal, so perhaps consider standardising that?

-- Luke

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Oct 2010 22:19:41 -0500

[Note: please top-post.]

On Thu, Oct 07, 2010 at 05:38:47PM -0700, Henry B. Hotz wrote:
> I, for one, would not be opposed to some description of how to
> populate PAC data from a generic LDAP.  Trouble is, I doubt we can
> really do that without specifying schemas.  (Someone prove me wrong,
> please!)

I certainly didn't mean that schema information could be left out.  In
fact, I thought it was clear that some amount of schema (e.g., RFC2307)
has to be required.

However, multiple schemas might be allowed as well, with clients having
to be prepared for any of them.  I can see two such schemas: RFC2307bis+,
and the ActiveDirectory schema.  The latter doesn't have to get
specified in an RFC (besides, AD supports RFC2307, effectively, via
IDMU, so perhaps just one schema will do).

> Another pragmatic issue, which maybe doesn't go in the RFC because
> maybe it isn't solvable, is what a KDC should do if the source of the
> PAC information is unavailable.

I'm not sure what you mean.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Oct 2010 22:29:55 -0500

> specified by RFC 4120 (5.2.6.2).

+1

> Also SignedPath
> (http://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation) is
> already implemented in MIT and Heimdal, so perhaps consider
> standardising that?

Probably, yes.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Oct 2010 22:32:20 -0500

> I'd like to see SAML used for this rather than transposing the MS PAC

SAML's great when you already have SAML usage to leverage, or when you
have other places where a "SAML PAC" could come in handy.  I suspect the
latter will be true, so, I guess I agree with you :)

Nico

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 11:49:35 +0200

> latter will be true, so, I guess I agree with you :)

Right, and we have code for SAML PACs (albeit sitting in a branch *). I'd be interested to see this reframed as a SAML attribute profile. I can of course understand the desire to get something working quickly, avoid the perceived complexity of SAML, etc. But anything we do will be around for years to come, so I think it's worth thinking about carefully.

-- Luke

* http://k5wiki.kerberos.org/wiki/Projects/SAMLInKerberos
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 08:34:59 -0400

On Thu, 7 Oct 2010 16:29:53 -0500
Nicolas Williams <[email-masked]> wrote:

> > > draft-adamson-nfsv4-multi- domain-access-03.txt.  As a co-author
> > > of that draft, there's a number of things I'd handle differently
> > > in a generic Kerberos PAC than you have chosen to do in your I-D,
> > > mostly regarding the representation of IDs in the PAC contents.
> > 
> Yes, but it would help a lot if we all first read each others' I-Ds.
> I haven't fully digested yours; I doubt you have fully digested ours.

Haven't fully digested yours yet, but I think I grasped the essence.

>  - Various non-ID data associated with the client principal (e.g.,
> home directory, possibly given as various different URLs).

If you read the list of attributes, home directory is one of them
(optional). So far I didn't go as far as proposing a
"networkHomeDirectory" attribute which would probably take the form of
a URI, but if people think it would be nice to have, I am fully ok with
that.

>       section 4 of our I-D, and which is very much like a SID, if not
> a SID

	SIDs are not directly translatable to a posix UID or a GID
	because they are "genderless". In POSIX the UID and GID space
	overlaps numerically, while SIDs are a single space. If you use
	a SID then you have to always perform a mapping, but you may
	not have access to a map. (more later)

	Bottom line, I explicitly wanted to represent UIDs and GIDs,
	because that's what you use on Unix machines.

>       Your I-D is not clear as to whether these are REQUIRED.

	All IDs (which directly represent UIDs and GIDs are required).

>       prefer using SIDs outright.  (Arguably we could use SID
> authority #5, though I'd prefer asking MSFT for a new SID authority
> or two for our purposes.)

	I am not attached to the UUID concept, I think we can easily
	change that to use another entity that is directly mappable to
	a SID if that is important. I didn't care too much, because if
	you want to talk to a Windows machine you are probably going to
	attach an MS-PAC to the ticket, not a PAD in this form.

>       Your I-D isn't clear as to whether these are optional.

	Mapping are "optional" in the sense that they are required only
	if the 2 domains have overlapping ID ranges that require
	remapping to avoid ID conflicts.

> Perhaps one problem is the lack of normative language in your I-D
> (which is understandable, given that it's a -00; our I-D is still
> missing significant chunks of text).

	Yes, there is a bit of that, we wanted some discussion before
	getting strict with the language.

> feasible for a KDC (or similar service) to provide "mapped IDs".

	IT is optional, if the KDC does not support mapping it can
	simply check the IDs do not conflict (by storing the realm ID
	range in some configuration) and filter unwanted IDs, or even
	just leave the client decide what to do. The last part is less
	ideal because it leaves space for conflicting translations
	among clients, but it would be an admin decision.

>     OpenSolaris (now defunct), Solaris 11 (soon-to-be), and the OS
> used in our NAS appliance, map non-local SIDs to UIDs/GIDs in an

	I know about ephemeral IDs but they are not really useful here.
	I want users to be able to login to a machine and write files
	on disk with their (possibly mapped) ID. So ephemeral IDs would
	be out of the equation.

>     We had the freedom to do this in Solaris because uid_t and gid_t
> had been signed 32-bit integral types and POSIX requires that UIDs and
>     types, therefore on Linux one could not borrow any UIDs or GIDs
> for ephemeral ID mapping without an affirmative action on the part of
> a local/site/domain administrator, but it'd still be feasible.

	Yes the idea is that careful admins will use different ranges
	of IDs in different domains (in a project I lead we do select
	an random 1 million IDs range as the base UID/GID and start
	allocating IDs from there, so that 2 different domains built
	with our product have a very high chance of having
	non-conflicting IDs).

> useful as the IDs in {domain ID, domain-local user/group ID} form,
> thus my interest in the latter being REQUIRED.  But also, you might
> not be able to produce domain-local "mapped IDs" either -- indeed,
> we'd likely find it unacceptable to be forced to provide them.

How do you represent a user in the system if you do not have a set of
credentials to use ?
I do not intend to require a specific way to do the mapping, if your
product works best with ephemeral mappings, then I would be happy to
see your KDC not map anything and let the client decide what to do.
In well (or luckily) configured domains ID ranges between domains do
not overlap so mapping is not even required, you just have to
administratively define ranges and KDC filters to avoid one domain
trying to spoof the other's range and breach security that way.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 08:43:47 -0400

On Thu, 7 Oct 2010 16:48:35 -0500
Nicolas Williams <[email-masked]> wrote:

> >       would prefer something more easily mapped to a SID, and, I
> > would prefer using SIDs outright.  (Arguably we could use SID
> For interoperability in the SMB protocol, which I'm certain that
> you'll want, you'll want to be able to represent user/group IDs from
> sizes can accomodate the 128 bits of a UUID, by convention the first
> RID is not at all randomly selected, leaving you with just 96 bits to
> play with for casting domain UUIDs to domain SIDs.

How do you resolve the problem of translating ?
1. SID -> UID/GID and
2. UID/GID -> SID.

The former can be done only if you accompany the SID with the
information of whether or not it is a user or group, adding to the
amount of info to carry.

The second can at best be done with an algorithmic mapping that would
potentially end up wrapping as you have to map 2 32bit spaces into 1
32bit space (the RID). Of course if we take Solaris limitation of
UId/GID spaces never being greater than 2^31, then the 2 spaces can be
mapped to a RID, and back.

This is actually the first mapping Samba used ages ago, but it falls
short as soon as the originator does not use an algorithmic approach
and instead create arbitrary mappings (Windows domains, and a lot of
samba domains). It also requires some games with ranges as well if you
want to map more than one domain, making it more difficult to fit all
IDs in a 32 bit space if the SID originator as a very high churn
(therefore the RIDs are high numbers).

If we have to store a map somewhere and we have to consult it from the
client, then we loose a lot of the advantages a PAC provides, although
it is a possible outcome. But then I would suggest that the KDC has
access to the map and provides the clients with a ready made
translation instead of having the client spend cycles contacting an
external service.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 08:54:08 -0400

On Thu, 7 Oct 2010 18:46:12 -0500
Nicolas Williams <[email-masked]> wrote:

>     - privacy protection (services lack permission to separately
> lookup some of the data delivered in a PAC).

One of the main rationales for me is connected with trusted
realms/domains and in particular cases where there is a one-way trust
(therefore the service cannot contact back the origin realm as it is
not trusted to access information there).

>    IMO we'll want to use either SIDs outright or quantities easily
> cast into SIDs when necessary.  This does not rule out UUIDs.

This is acceptable if it really helps some sort of interoperability.

>       methods for detecting and coping with conflicts.

How/Who would access this registry ? And how do you know if you are
looking at a conflict ?

>     - what schemas to expect.

My document is explicitly about *not* requiring access to foreign LDAP
servers, indeed I am seeking to come to a tool that is completely
agnostic about what is the other domain (or even your own) identity
manager. I do not want to force people to use a specific identity store
nor to use a specific LDAP schema. Either requirement would make the
PAD a *lot* less useful, and would pin it down to be just an
authentication speed-up instead of a real aid to help interoperability
between separate REALMs with very little trust between each other..

> There's more, but that's a good set of issues to start with.

We definitely need a good discussion, I so not like most of the
requirements you want to enforce in your draft, so I so not want to
steer the discussion by giving for granted those requirements should
"infect" this one :)

In particular I find unacceptable to mandate LDAP and especially the
RFC2307 schema, or even worse mandating how to configure your base dn.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 08:55:16 -0400

On Fri, 8 Oct 2010 03:40:22 +0200

> I'd like to see SAML used for this rather than transposing the MS PAC

Please elaborate. Are you saying you would want to stuff SAML
statements into a kerberos Authorization Data blob ?

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 08:59:25 -0400

On Fri, 8 Oct 2010 11:49:35 +0200
Luke Howard <[email-masked]> wrote:

> > SAML's great when you already have SAML usage to leverage, or when
> > you have other places where a "SAML PAC" could come in handy.  I
> > suspect the latter will be true, so, I guess I agree with you :)
> 
> 
> Right, and we have code for SAML PACs (albeit sitting in a branch *).
> I'd be interested to see this reframed as a SAML attribute profile. I
> can of course understand the desire to get something working quickly,
> avoid the perceived complexity of SAML, etc. But anything we do will
> be around for years to come, so I think it's worth thinking about
> carefully.
> 
> -- Luke
> 

The main problem I have with SAML is its verbosity.
You wouldn't be able to fit much information in a Kerberos ticket if
you have to use XML. Unless you are ok with tickets that are a few
hundred KiB in size (is that even possible, aren't tickets de facto
limited to 65k in size ?

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 09:00:26 -0400

On Fri, 8 Oct 2010 04:03:33 +0200

> already implemented in MIT and Heimdal, so perhaps consider

I see no problem using these for integrity purposes, do you want to
suggest some language for the draft? :)

Simo.

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 15:00:39 +0200

> between separate REALMs with very little trust between each other..

How do you assign ACEs on the objects you intend to authorise access to without some sort of name resolution protocol? The PAC is only part of the picture.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 15:01:13 +0200

> statements into a kerberos Authorization Data blob ?

Yes; even if the generation and consumption of it was somewhat brittle in an initial implementation, we might gain some future-proofing.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 15:02:01 +0200

> hundred KiB in size (is that even possible, aren't tickets de facto

I don't know where these ticket size limits came from; I think it's a Windows issue. But someone that understands RFC 4120 better than I can comment.

You can always compress the assertions.

-- Luke

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 09:13:40 -0400

On Thu, 7 Oct 2010 22:19:41 -0500
Nicolas Williams <[email-masked]> wrote:

> > > - LDAP schemes (I need a word that cannot be confused with
> > > 'schema') models to go with the PAC (see our doc).
> > > 
> > >   Specifically:
> > > 
> fact, I thought it was clear that some amount of schema (e.g.,
> RFC2307) has to be required.

As you see, I am very opposed to requiring a specific schema, I am
actually opposed to require LDAP or any other specific
identity information source... we need to clearly discuss this point
before anything else, or any discussion will be based on different
understanding of the problems we want to solve with this work and make
most discussions moot in the end.

> However, multiple schemas might be allowed as well, with clients
> having to be prepared for any of them.  I can see two such schemas:
> RFC2307bis+, and the ActiveDirectory schema.  The latter doesn't have
> to get specified in an RFC (besides, AD supports RFC2307,
> effectively, via IDMU, so perhaps just one schema will do).

Yeah and this is quickly going to be a nightmare. The reason to have a
PAC is to not have to know what's out there. If you have to, then you do
not need a PAC anymore you can just go and consult the directory.
If the PAD is to be used only as a speed up it is almost uninteresting.

> > maybe it isn't solvable, is what a KDC should do if the source of
> > the PAC information is unavailable.

First of all, this assumes that Kerberos information and identity
information reside in different databases, which is of course a
very common scenario right now.

The best option is that you refuse to give a TGT, like if the whole
service was down.
You could still return a TGT w/o a PAD but then clients would not be
able to access resources in any trusting REALM that relies on the PAD
in order to provide access. It would be a bit confusing for users to be
denied access or have limited access (some service will probably never
care about the PAD so they could keep working), but I think that could
be an admin decision.

Remember that for any other ticket you do not need to have any access
to the source of information as all the information the KDC needs is
carried in the PAD itself.
The KDC can decide to modify this information, for example it can
filters some IDs if the principal comes from a different REALM, or map
IDs, or stuff like that, but it will not need access to the original
information.
Of course, in case the KDC has to perform some mapping, it may still
need access to a database (potentially a 3rd database), and if that is
not available it may still refuse to carry on the operation or fallback
to some other mode of operation. But I am not sure these behaviors
should be dictated in this document.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 09:40:35 -0400

On Fri, 8 Oct 2010 15:00:39 +0200
Luke Howard <[email-masked]> wrote:

> > My document is explicitly about *not* requiring access to foreign
> > LDAP servers, indeed I am seeking to come to a tool that is
> > completely agnostic about what is the other domain (or even your
> > own) identity manager. I do not want to force people to use a
> > specific identity store nor to use a specific LDAP schema. Either
> > requirement would make the PAD a *lot* less useful, and would pin
> > it down to be just an authentication speed-up instead of a real aid
> > to help interoperability between separate REALMs with very little
> > trust between each other..
> 
> How do you assign ACEs on the objects you intend to authorise access
> to without some sort of name resolution protocol? The PAC is only
> part of the picture.

That is conveniently out of scope :-)

Simo.

---

From: Tom Yu <[email-masked]>
Date: Fri, 08 Oct 2010 10:57:36 -0400

Luke Howard <[email-masked]> writes:

> I don't know where these ticket size limits came from; I think it's
> a Windows issue. But someone that understands RFC 4120 better than I
> can comment.

As Martin Rex pointed out earlier, this is actually a limitation that
RFC 4121 imposes on delegated credentials: only 16 bits for the
length.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 8 Oct 2010 11:04:45 -0400

> RFC 4121 imposes on delegated credentials: only 16 bits for the

Note that the W3C is standardizing a binary encoding of XML (EXI). There's
not much apparent support for it, of course, though it's still early.

My main concern would be if there was an attempt to overload the PAC with
the kind of embedded security semantics that SAML supports. Absent that,
it's just a data format argument, and my argument would be to reuse
*something*, above all else.

It is good to know that the 16-bit limit will be with us well into the 21st
century. If you can work in some kind of segmented addressing scheme, I'll
die happy.

-- Scott

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 17:15:07 +0200

> RFC 4121 imposes on delegated credentials: only 16 bits for the

Aha! Still, constrained delegation is probably preferable these days, and you could always use put a SAML artifact in the authorisation data (pass by reference).

-- Luke

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 11:50:11 -0400

On Fri, 8 Oct 2010 17:15:07 +0200
Luke Howard <[email-masked]> wrote:

> >> a Windows issue. But someone that understands RFC 4120 better than
> >> I can comment.
> > 
> > As Martin Rex pointed out earlier, this is actually a limitation
> > that RFC 4121 imposes on delegated credentials: only 16 bits for the
> > length.
> 
> Aha! Still, constrained delegation is probably preferable these days,
> and you could always use put a SAML artifact in the authorisation
> data (pass by reference).

Reference to what ? where ?

Simo.

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 8 Oct 2010 11:54:55 -0400

> Reference to what ? where ?

An assertion ID referencing a token at a SAML authority, presumably. Not
quite the same as a SAML artifact, but similar.

-- Scott

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 12:08:21 -0400

On Fri, 8 Oct 2010 11:54:55 -0400
"Scott Cantor" <[email-masked]> wrote:

> An assertion ID referencing a token at a SAML authority, presumably.
> Not quite the same as a SAML artifact, but similar.

That would mean the client would have to know how to reach this SAML
authority and fetch data from there ?
I'd be opposed to such a scheme.

Simo.

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 8 Oct 2010 12:26:02 -0400

> authority and fetch data from there ?

The reference is typically a URI and is an incredibly complex protocol known
as an HTTP GET.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2010 11:50:17 -0500

On Fri, Oct 08, 2010 at 09:13:40AM -0400, Simo Sorce wrote:
> actually opposed to require LDAP or any other specific identity
> information source... we need to clearly discuss this point before
> anything else, or any discussion will be based on different

The problem with this is that you can't always be in a position where
you can rely on getting the information you need via a PAC.  Not
everything will occur in the context of Kerberos or other security
mechanism that can carry arbitrary PAC-like contents.

Not having a way to lookup the relevant data is a problem.

> Yeah and this is quickly going to be a nightmare. The reason to have a

Can you elaborate?  If there were N>2 radically different schemas I'd
agree.  In practice there's really at most two, and with IDMU possibly
just one with minor variations.  That's not the stuff of nightmares.

> If the PAD is to be used only as a speed up it is almost uninteresting.

I guess we'll have to disagree on that.  But it's early.

> very common scenario right now.

In a cross-realm case that's always going to be a common scenario.

Nico

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 18:58:22 +0200

> Not having a way to lookup the relevant data is a problem.

Right, it's useful to see the PAC as an optimisation, not as a philosophy.

-- Luke

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 13:01:11 -0400

On Fri, 8 Oct 2010 12:26:02 -0400
"Scott Cantor" <[email-masked]> wrote:

> The reference is typically a URI and is an incredibly complex
> protocol known as an HTTP GET.

Sarcasm aside, the complexity of the protocol is the least of the
issues I am concerned about.

Simo.

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 8 Oct 2010 13:10:02 -0400

> issues I am concerned about.

My sarcasm meter is tripped when I see words like "complexity" thrown around
about SAML on a Kerberos list, but I don't know what the issues you're
concerned about are. If you're suggesting that it shouldn't be possible to
embed a reference like that in a ticket, I can't really agree, but I don't
necessarily think it's a subtitute for other approaches either.

But I'd be extremely concerned about yet more format reinvention.
 
-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2010 12:08:13 -0500

> not trusted to access information there).

I find one-way trusts to be too big an access control hammer.  I'm not
sure it that one-way trusts can be realistically avoided though, so I'll
grant that this is a good rationale for a PAC for the time being.

> This is acceptable if it really helps some sort of interoperability.

Sure it does: in the SMB protocol, for example.  But even if SMB didn't
exist, I don't see the need to invent a new wheel when an existing one
will do.

> How/Who would access this registry ? And how do you know if you are

That will take some discussion.  One option would be to have some
number of bits dedicated to naming registrars, that way there can be
mane of them (I think that'd be a good thing).  Another is that each
federation must have a registrar, and a domain/realm cannot join a
federation if its domain ID conflicts with any other domain's in that
federation.

> [... see other sub-thread ...]

Giving services a way to avoid LDAP lookups is fine.  But I don't think
the matter is entirely avoidable (see other reply).

> steer the discussion by giving for granted those requirements should

I understand that there's a bigger gulf between us than the puddle I
thought there was yesterday.  I'm not sure that this gulf can be crossed
but I definitely want to try.  It would be a problem if we can't,
because obviously the two I-Ds in question are playing very much in the
same space, and interop issues may well arise if we continue down
radically different paths (and if that happens, what happens to these
documents?  I doubt both would make the Standards track).

> In particular I find unacceptable to mandate LDAP [...]

I do not find unacceptable to use (nor mandate) the use of the one
Internet protocol we have for directory access.

>                                             [...] and especially the
> RFC2307 schema, [...]

If it can be made to work in a federated way, then I'm OK with
RFC2307bis+.  I'm also OK with variants of that.  And I'm OK with
the AD schema.  I'd even be OK with a method of mapping various types of
requests to arbitrary schemas, with the mappings themselves published in
directories (this would be a lot of work, but if there really is an
enormous variety of schemas out there, I'd consider it).

>           [...] or even worse mandating how to configure your base dn.

There's no need to have a base DN be anything in particular provided
that you can have a referral issued from the expected base DN if you use
anything else.  That is just a simplification for discovery.  I [and
probably my co-authors] would be open to reconsidering that.  Both I-Ds
are in early stages.  I'd rather not consider all of our positions as
cast in stone (if nothing else because if we are aiming for the
Standards track then we'll need consensus, and that's hard to achieve
when one refuses to consider the needs and input of other participants).

Nico

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 13:28:22 -0400

On Fri, 8 Oct 2010 11:50:17 -0500
Nicolas Williams <[email-masked]> wrote:

> > > I certainly didn't mean that schema information could be left
> > > out.  In fact, I thought it was clear that some amount of schema
> > > (e.g., RFC2307) has to be required.
> > 
> > understanding of the problems we want to solve with this work and
> > make most discussions moot in the end.
> 

For the local domain data can, of course, also looked up in the local
identity information store, be it a directory or other kind of database.

For corss-relam trusts users data can be cached on the client side.

> > > having to be prepared for any of them.  I can see two such
> > > schemas: RFC2307bis+, and the ActiveDirectory schema.  The latter
> > > doesn't have to get specified in an RFC (besides, AD supports
> > > RFC2307, effectively, via IDMU, so perhaps just one schema will
> > > do).
> > 

You are assuming that LDAP is the identity information store and that
RFC2307 is used. That's not necessarily the case.

> > PAC is to not have to know what's out there. If you have to, then
> > you do not need a PAC anymore you can just go and consult the
> > directory. If the PAD is to be used only as a speed up it is almost
> > uninteresting.
> 
> > > > Another pragmatic issue, which maybe doesn't go in the RFC
> > > > because maybe it isn't solvable, is what a KDC should do if the
> > > > source of the PAC information is unavailable.
> > 

Sorry, I don't understand this comment.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 13:33:15 -0400

On Fri, 8 Oct 2010 18:58:22 +0200
Luke Howard <[email-masked]> wrote:

> > The problem with this is that you can't always be in a position
> > where you can rely on getting the information you need via a PAC.
> > Not everything will occur in the context of Kerberos or other
> > security mechanism that can carry arbitrary PAC-like contents.
> > 

Except that my proposal (and the text explains that) is not though as
an optimization.
It is though primarily to solve the issue of distributing users
credentials at login time w/o having to know the details of user
information management in foreign REALMs that are trusted by the REALM
the service is connected to.
The idea is that the PAD can carry enough information to create a local
cache that contains all the POSIX information relevant to the user that
is trying to log in, which is: username, uid, gid, (home), (gecos),
(shell), and group memberships. [parenthesis around information that
can also be generated or overridden locally and therefore technically
optional]

This is also the reason why I limited the information to the POSIX
attributes as those are the only ones on which all POSIX systems agree
without question. Anything else would have to be an extension as some
systems may handle it and some other not.

Simo.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2010 12:42:28 -0500

> How do you resolve the problem of translating ?

First of all, if you care to interop with SMB clients, then you'll have
to solve this.  (I realize that SMB is not an Internet protocol, but
that's not the same thing as having a license to ignore it.)

> 2. UID/GID -> SID.

The translations are only needed on systems that need UIDs/GIDs (I know,
a very obvious statement, but bear with me).  The translation is at
least a local problem, though some solutions might involve distributed
infrastructure.  In the case of Solaris we support a number of mapping
methods:

 - SID->UID/GID

    - Cache

      If a mapping has already been established, then use that.

    - Name-based mapping rules

      If there are local name-based mapping rules, then resolve the SID
      to a name, then check if it matches any rules, and if it does then
      apply the matching rule, then resolve the result to obtain a UID
      or GID.  This method can produce both, a UID and a GID for any
      given, resolvable SID.  If name resolution fails due to transient
      errors, then the mapping operation fails.  If the name resolution
      fails due to the SID not being resolvable then other methods are
      tried.

      Name resolution of SIDs can be done using LDAP or LSA RPC.

    - DS-based name mapping and IDMU-based mapping

      This method is based on resolving the SID to an LDAP object,
      finding an attribute naming a Unix user and/or group to map it to,
      then resolving that to a UID and/or GID.  The same considerations
      apply to name resolution failures as above.

    - Ephemeral ID mapping

      I've described this already.  This applies to all SIDs not mapped
      through the other methods, and to unresolvable SIDs if desired.

 - UID/GID->SID

    - Cache

      If a mapping has already been established, then use that.
      Ephemeral IDs are only mapped back to SIDs through this method.

    - Name-based mapping rules

      Same as above, but in the reverse direction.

    - DS-based name mapping and IDMU-based mapping

      Same as above, but in the reverse direction.

    - Local SID mapping

      Last resort, map UIDs and GIDs to a RID relative to the host's
      SID.  The host runs an LSA RPC service to provide name resolution
      of local SIDs to remote SMB clients.

> information of whether or not it is a user or group, adding to the

We did something very clever in Solaris: we allow a SID to map to both,
a UID and a GID.  Imagine for a moment that every Unix user has their
own private, empty group...  (indeed, one can manage Unix systems that
way).

This turned out to be critical because there are cases where groups own
files.  There are also cases where we can't resolve SIDs to determine if
they are users or groups.

Yes, there are cases where SIDs are unresolvable, such as where
applications on SMB clients make reference to local SIDs in ACLs on
files on remote servers.  Don't ask me why they do that, but if the
server doesn't honor this then the applications often break.

> mapped to a RID, and back.

We've certainly done better than algorithmic mapping.

We also considered doing a distributed non-ephemeral service.  But
there wasn't much value in that for us at the time.  In other words:
there are more options here than you might have thought of.

> translation instead of having the client spend cycles contacting an

So, you do or do not want a network optimization?  I'm confused ;)

Nico

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 8 Oct 2010 13:48:10 -0400

> I am not opposed to using SAML expressions in principle, although I am
> really not a fan of XMLish stuff.

That's where I stop arguing, because it's pointless. I think new formats are
more evil than worrying about the foibles of the many that already exist.
The arguments will never end and they're not terribly interesting.
 
> We actually discussed SAML as a
> possibility before throwing out the draft. The main concern I had was
> with the size of SAML declarations because of the limit on ticket size
> with delegation.

As I said, the idea of a 16 bit limit is nuts in 2010, but I don't know what
else to say about it.
 
> When it comes to URIs instead the problem I have is that I would like
> to avoid adding lookups from clients. As that add a number of
> requirements on the client and the server I am not willing to impose at
> this stage. For example it means clients can access this remote
> resource, which is not always possible/desirable. It also require
> adding a new server to the authentication infrastructure, with
> mechanism to allow the KDCs to sign and publish these SAML blobs. Add
> requirements to have garbage collection mechanism to remove expired
> blobs. And so on ... a lot more architectural complexity, not protocol
> complexity.

Yes, I'm not a huge fan of references either, it should merely be one of a
variety of types of data to allow for.

I saw from reading the draft and the other thread that you're talking about
POSIX data. That's extraordinarily limiting to me, but moreover I don't
understand how you could safely map UID or GID information across domains.
You seem to start with the premise that federation is involved (else I'd
just use LDAP and be done with it) but then defeat any hope of using it
safely by passing data that has no possible meaning across disparate
systems.

-- Scott

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 19:51:54 +0200

> blobs. And so on ... a lot more architectural complexity, not protocol

All fair comments.

Here's a simple way to approach this.

If the client does not present a PAC to the server, the server does S4U2Self for the client. This can be hidden inside the Kerberos or GSSAPI library. Recall that S4U2Self will traverse the trust hierarchy. Regardless of whether the PAC was presented in the AP-REQ or acquired using S4U2Self, it is available to the server for authorisation.

The open issue thus is how a KDC determines whether to include the PAC in a service ticket. It may use the putative size of the returned ticket as input into this decision.

Obviously this approach is completely orthogonal to the use of SAML as a data representation.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 19:54:29 +0200

> variety of types of data to allow for.

See the mail I just sent: as long as you know the principal name (i.e. you may want to do something different with anonymous tickets), you can approach dereferencing in a "Kerberos-native" way using S4U2Self.

(S4U2Self is a MS extension that returns a ticket to a service given for an arbitrary principal or certificate. Typically it's used to retrieve authorisation data for a client that authenticated using something other than Kerberos, but you can also use it for a client that authenticated with a Kerberos ticket lacking authorisation data.)

-- Luke

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 13:39:34 -0400

On Fri, 8 Oct 2010 13:10:02 -0400
"Scott Cantor" <[email-masked]> wrote:

> My sarcasm meter is tripped when I see words like "complexity" thrown
> around about SAML on a Kerberos list, but I don't know what the
> issues you're concerned about are. If you're suggesting that it
> shouldn't be possible to embed a reference like that in a ticket, I
> can't really agree, but I don't necessarily think it's a subtitute
> for other approaches either.
> 

I am not opposed to using SAML expressions in principle, although I am
really not a fan of XMLish stuff. We actually discussed SAML as a
possibility before throwing out the draft. The main concern I had was
with the size of SAML declarations because of the limit on ticket size
with delegation.

Simo.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 08 Oct 2010 14:11:13 -0400

--On Friday, October 08, 2010 01:48:10 PM -0400 Scott Cantor 
<[email-masked]> wrote:

> That's where I stop arguing, because it's pointless. I think new formats
> are more evil than worrying about the foibles of the many that already
> exist. The arguments will never end and they're not terribly interesting.

The problem is that for many of us, "new formats" includes XML.  We are 
constantly exposed to people who want to take perfectly good working things 
and recast them in XML because it's the latest thing.

-- Jeff

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 14:15:48 -0400

On Fri, 8 Oct 2010 12:42:28 -0500
Nicolas Williams <[email-masked]> wrote:

> > > you'll want, you'll want to be able to represent user/group IDs
> > > from non-Windows domains as... SIDs.  Recent versions of Windows
> > > are picky regarding the length of SIDs.  And while normal
> > > domain/computer SID sizes can accomodate the 128 bits of a UUID,
> > > by convention the first RID is not at all randomly selected,
> > > leaving you with just 96 bits to play with for casting domain
> > > UUIDs to domain SIDs.
> > 
> First of all, if you care to interop with SMB clients, then you'll
> have to solve this.  (I realize that SMB is not an Internet protocol,
> but that's not the same thing as having a license to ignore it.)

Yeah, I am happy to leave that to the smb client though (And I am a
Samba developer so I know what it means :)

> > 1. SID -> UID/GID and
> > 2. UID/GID -> SID.
> 
> The translations are only needed on systems that need UIDs/GIDs (I
> know, a very obvious statement, but bear with me).  The translation
> is at least a local problem, though some solutions might involve
> distributed infrastructure.  In the case of Solaris we support a
> number of mapping methods:
> 
>  - SID->UID/GID
> 
>     - Cache
> 

This is generally local only, it makes it difficult to access the same
data from 2 machines unless they share the cache. Which means you need
a shared server to assign mappings (infrastructure needed).

>       If there are local name-based mapping rules, then resolve the
> SID to a name, then check if it matches any rules, and if it does then
>       given, resolvable SID.  If name resolution fails due to
> transient errors, then the mapping operation fails.  If the name
> resolution fails due to the SID not being resolvable then other
> methods are tried.

SID -> Name requires translation, again infrastructure to be able to
communicate with the information holder. Un less you transmit the name
along side the SID of course.

>       Name resolution of SIDs can be done using LDAP or LSA RPC.

Yeah I would avoid that.

>       finding an attribute naming a Unix user and/or group to map it
> to, then resolving that to a UID and/or GID.  The same considerations

As I said in another thread, if I have to go to LDAP I can avoid the
PAC altogether.

>     - Ephemeral ID mapping
> 
>       I've described this already.  This applies to all SIDs not
> mapped through the other methods, and to unresolvable SIDs if desired.

Local only, IDs are not persistent, unsuitable for file access, and
access control on files unless you can also store the SID, which is not
the case in most file systems used by POSIX machines.

>       SID.  The host runs an LSA RPC service to provide name
> resolution of local SIDs to remote SMB clients.

This would technically be a security domain violation, and can have bad
consequences. But there are similar approaches (like samba does) that
use auxiliary Domains to represent this concept.

> We did something very clever in Solaris: we allow a SID to map to
> both, a UID and a GID.  Imagine for a moment that every Unix user has
> their own private, empty group...  (indeed, one can manage Unix
> systems that way).

Yes, this is an approach we've discussed in samba loong ago, the reason
why we do not do that is that you cannot enforce this rule on existing
installations where UIDs and GIDs have already been assigned and you
can't force the unification of the UID and GID spaces for the existing
entities.

> This turned out to be critical because there are cases where groups
> own files.  There are also cases where we can't resolve SIDs to
> determine if they are users or groups.

For clients of Windows domains this is fine, when the Domain Controller
is an existing Unix machine tho things are not so ideal, see the point
above.

> server doesn't honor this then the applications often break.

yes, but we are not here to discuss SID->POSIX mappings right :-)

> > The second can at best be done with an algorithmic mapping that
> > would potentially end up wrapping as you have to map 2 32bit spaces
> > into 1 32bit space (the RID). Of course if we take Solaris
> > limitation of UId/GID spaces never being greater than 2^31, then
> > the 2 spaces can be mapped to a RID, and back.
> 

It's a matter of perspective. If there is one thing I've leran in my
experience with id mapping, is that there isn't a single method that is
"better" than any other. It always depend on the conditions you can
impose.

> there are more options here than you might have thought of.

In samba we have pretty much implemented (or considered and not
implemented) basically all the options you present with the exception
of the ephemeral IDs because we are a server and IDs cannot be
temporary they have to be persistent.

So, yes, there are many options but they all present issues, so I would
not like to go through a double translation to/from SIDs, where we can
just transmit the POSIX IDs we have as-is.

Translation to/from SIDs is already required when you want to deal with
the MS-PAC and I would like to leave it there.

> > If we have to store a map somewhere and we have to consult it from
> > the client, then we loose a lot of the advantages a PAC provides,
> > although it is a possible outcome. But then I would suggest that
> > the KDC has access to the map and provides the clients with a ready
> > made translation instead of having the client spend cycles
> > contacting an external service.
> 

Uhmm not sure how you read it, but from my point of view, any mapping
we need to do I prefer to do it at the KDC level, once, when the TGT is
granted, rather then at the service level each time a client logs in,
over and over again.
Although I do not want to mandate that KDC have to do mapping, so I
would consider it optional and leave it to implementers whether they
want to do any translation (if necessary) at the KDC level or a the
service level.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 14:26:19 -0400

On Fri, 8 Oct 2010 12:08:13 -0500
Nicolas Williams <[email-masked]> wrote:

> > realms/domains and in particular cases where there is a one-way
> > trust (therefore the service cannot contact back the origin realm
> > as it is not trusted to access information there).
> 
> sure it that one-way trusts can be realistically avoided though, so
> I'll grant that this is a good rationale for a PAC for the time being.

Thanks, one-way trust impose a lot of constraints, but they also make a
lot of sense when you have service organizations talking/trusting other
organizations.

> Sure it does: in the SMB protocol, for example.  But even if SMB
> didn't exist, I don't see the need to invent a new wheel when an
> existing one will do.

Ok I do not have any reason to stick to UUIDs, as long as the
identifier is reasonably unique a 96bit identifier will do as well,
that should make it easy to map it to a SID when interop with Windows
clients/servers is required.

> > >       IMO, ultimately we'll want some sort of registry, else at
> > > least methods for detecting and coping with conflicts.
> > 

One way could be to use DNS, perhaps using a TXT record, and a second
one to hold a "short domain name" as well for other interop and
compatibility purposes.

> > LDAP [... see other sub-thread ...]
> 
> Giving services a way to avoid LDAP lookups is fine.  But I don't
> think the matter is entirely avoidable (see other reply).

We may open a discussion on information flow and where you see issues
that require access to the remote directory (keeping in mind access
issues connected to one-way trusts as well).

> thought there was yesterday.  I'm not sure that this gulf can be
> crossed but I definitely want to try.  It would be a problem if we
> can't, because obviously the two I-Ds in question are playing very
> much in the same space, and interop issues may well arise if we
> continue down radically different paths (and if that happens, what
> happens to these documents?  I doubt both would make the Standards
> track).

Yes I see value in discussing issues that may arise by combinining
these 2 IDs. What would be the right forum to discuss this topic ?

> Internet protocol we have for directory access.

Except that this is not just a communication protocol, LDAP is a whole
service and data storage philosphy etc... By mandating LDAP you make it
very difficult to use anything else. From older technologies like NIS
to SQL database etc... You would mandate at the very least a
translation layer which adds a whole host of issues.

Believe me I like LDAP, I use it every day, I just don't want to impose
my preference on others if I can help it (and I think I can).

Simo.

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 8 Oct 2010 14:28:03 -0400

> and recast them in XML because it's the latest thing.

It's far from the latest thing, it's already dead, right? JSON is the new
black. But "format" does not only mean the encoding, it also means the
structure and semantics of the content, the naming of attributes, etc.
That's where newness matters to me.

-- Scott

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 20:29:38 +0200

> translation layer which adds a whole host of issues.

I would argue that cross-realm name translation can't be ignored completely. What happens when an administrator wants to assign access to a resource for a foreign user that hasn't yet authenticated (and for which thus no cached PAC exists)?

-- Luke

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 14:35:31 -0400

On Fri, 8 Oct 2010 19:51:54 +0200
Luke Howard <[email-masked]> wrote:

> > When it comes to URIs instead the problem I have is that I would
> > like to avoid adding lookups from clients. As that add a number of
> > requirements on the client and the server I am not willing to
> > impose at this stage. For example it means clients can access this
> > remote resource, which is not always possible/desirable. It also
> > require adding a new server to the authentication infrastructure,
> > with mechanism to allow the KDCs to sign and publish these SAML
> > blobs. Add requirements to have garbage collection mechanism to
> > remove expired blobs. And so on ... a lot more architectural
> > complexity, not protocol complexity.
> 
> All fair comments.
> 
> If the client does not present a PAC to the server, the server does
> S4U2Self for the client. This can be hidden inside the Kerberos or
> GSSAPI library. Recall that S4U2Self will traverse the trust
> hierarchy. Regardless of whether the PAC was presented in the AP-REQ
> or acquired using S4U2Self, it is available to the server for
> authorisation.

I am not sure I see how this can work in a cross-realm trust case
(esp. with one-way trusts).

Assume REALM B trusts REALM A (not vice versa).

How can service in REALM B get the PAD for a principal in REALM A ?

> The open issue thus is how a KDC determines whether to include the
> PAC in a service ticket. It may use the putative size of the returned
> ticket as input into this decision.

Maybe, but if it doesn't provide a PAD then it may make it impossible
for the service to get it at all, see above.

> as a data representation.

Right.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2010 13:35:50 -0500

> Samba developer so I know what it means :)

I don't think that's how interop works.

> a shared server to assign mappings (infrastructure needed).

Of course it's local.

> >       [...]

Again, there are contexts where there can be no PAC.  Luke mentioned the
context where a user is viewing or editing an ACL.

> >       Name resolution of SIDs can be done using LDAP or LSA RPC.

You can avoid it, but then users can only see meaningless (to them) IDs
in some cases.

> the case in most file systems used by POSIX machines.

We store SIDs on disk in ZFS, so they are suitable for file access.

Also, as I said, one can pursue a dynamic ID mapping method with scope
larger than local.

> >     [...]

Can you elaborate?  Where's the "security domain violation"?

> can't force the unification of the UID and GID spaces for the existing

We do not even try to ensure that the UID and GID that a given SID maps
to are numerically equal.  Why should you?

> yes, but we are not here to discuss SID->POSIX mappings right :-)

I am.  We use SIDs extensively in Solaris.  I don't want to see a
Standards Track RFC that we cannot interop with, particularly when we
could have (as I believe we can) found a better, more interoperable
design.

> "better" than any other. It always depend on the conditions you can

I agree with the last sentence.  Given one set of constraints there may
be no method that is better than any other, and given another there may
be a method that is better than all the others.  I don't think this
matters very much.  What we need is to determine what constraints would
apply to an Internet Standard in this area.

Note that if you wish to pursue an Informational RFC then I can stop
discussing this matter now and leave you be.  If you prefer a Standards
track RFC then I care veyr much, and seeking consensus will require a
little more than the assertions you've made so far.

> Uhmm not sure how you read it, but from my point of view, any mapping

"...instead of having the client spend cycles..."

I read that as "network optimization".

> want to do any translation (if necessary) at the KDC level or a the

Behaviors can end up being mandated without having to have RFC2119
normative language.  Care is required here.

Nico

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 20:39:38 +0200

> How can service in REALM B get the PAD for a principal in REALM A ?

S4U2Self does work traverse the trust hierarchy, this is specified in [MS-SFU] and implemented by MIT (I don't think by Heimdal).

Granted it does require two-way trusts.

-- Luke

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 14:44:14 -0400

On Fri, 8 Oct 2010 20:39:38 +0200
Luke Howard <[email-masked]> wrote:

> S4U2Self does work traverse the trust hierarchy, this is specified in
> [MS-SFU] and implemented by MIT (I don't think by Heimdal).
> 

Yeah that's the issue I have with using this method.
Handling one-way trusts is one of the main aims of this work from my
side.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 14:48:27 -0400

On Fri, 8 Oct 2010 20:29:38 +0200
Luke Howard <[email-masked]> wrote:

> > Except that this is not just a communication protocol, LDAP is a
> > whole service and data storage philosphy etc... By mandating LDAP
> > you make it very difficult to use anything else. From older
> > technologies like NIS to SQL database etc... You would mandate at
> > the very least a translation layer which adds a whole host of
> > issues.
> 
> I would argue that cross-realm name translation can't be ignored
> completely. What happens when an administrator wants to assign access
> to a resource for a foreign user that hasn't yet authenticated (and
> for which thus no cached PAC exists)?

This is a real issue, and some level of communication may be needed at
the administrative level. But that's another level. It is reasonable to
expect that and administrative workstation have a different level of
access and facilities available than any other random client/service in
the domain.

Simo.

---

From: Michiko Short <[email-masked]>
Date: Fri, 8 Oct 2010 18:51:04 +0000

One way trusts are tricky that way. If the client does not bring it with them then there is no way to get the data since there is no trust the other way back to the client's realm since it does not trust the application server's realm. Keep this in mind when passing data since the server won't be able to look up data back at the client's realm if that lookup must be authenticated. If it is anonymous then you would be fine.  

Thanks,
Michiko Short | Program Manager | Windows Security & Identity

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simo Sorce
Sent: Friday, October 08, 2010 11:36 AM
To: Luke Howard
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] [SPAM] Re: I-D Action:draft-sorce-krbwg-general-pac-00.txt

On Fri, 8 Oct 2010 19:51:54 +0200
Luke Howard <[email-masked]> wrote:

> > requirements on the client and the server I am not willing to impose 
> > at this stage. For example it means clients can access this remote 
> > mechanism to allow the KDCs to sign and publish these SAML blobs. 
> > Add requirements to have garbage collection mechanism to remove 
> > expired blobs. And so on ... a lot more architectural complexity, 
> > not protocol complexity.
> 
> All fair comments.
> 

I am not sure I see how this can work in a cross-realm trust case (esp. with one-way trusts).

> The open issue thus is how a KDC determines whether to include the PAC 
> in a service ticket. It may use the putative size of the returned 

Maybe, but if it doesn't provide a PAD then it may make it impossible for the service to get it at all, see above.

Right.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 8 Oct 2010 15:03:35 -0400

On Fri, 8 Oct 2010 13:35:50 -0500
Nicolas Williams <[email-masked]> wrote:

> Again, there are contexts where there can be no PAC.  Luke mentioned
> the context where a user is viewing or editing an ACL.

[see below]

> You can avoid it, but then users can only see meaningless (to them)
> IDs in some cases.

True, if the OS have no caching then the user may see ugly numbers,
this can already happen in other cases with current technology if you
don't do caching (listing files on NFS while the LDAP server is down).
I don't think we need to worry about this. An implementer is of course
allowed to have additional lookup mechanisms to workaround or avoid
this kind of issues. What I really care is not *mandating* these
additional requirements in this document.

> > access control on files unless you can also store the SID, which is
> > not the case in most file systems used by POSIX machines.
> 

Solaris does it with ZFS, Linux doesn't do it (yet at least) with any
filesystem. Many other OSs don't either.
So I do not want to give for granted that SIDs are a good way to share
credentials in a POSIX world.

> > >       Last resort, map UIDs and GIDs to a RID relative to the
> > > host's SID.  The host runs an LSA RPC service to provide name
> > This would technically be a security domain violation, and can have
> > bad consequences. But there are similar approaches (like samba
> > does) that use auxiliary Domains to represent this concept.
> 

I could but I think we are really rolling out of topic here, please
ping me in private if you want to discuss this point.

> > > > information of whether or not it is a user or group, adding to
> > > > the amount of info to carry.
> > > 
> > > both, a UID and a GID.  Imagine for a moment that every Unix user
> > > has their own private, empty group...  (indeed, one can manage
> > > Unix systems that way).
> > 
> > Yes, this is an approach we've discussed in samba loong ago, the
> > reason why we do not do that is that you cannot enforce this rule
> > on existing installations where UIDs and GIDs have already been
> > assigned and you can't force the unification of the UID and GID
> > spaces for the existing entities.
> 
> We do not even try to ensure that the UID and GID that a given SID
> maps to are numerically equal.  Why should you?

The reason is that this way you could do an efficient algorithmic
mapping, if you have to resort to a distributed map then you can as
well use LSA too lookup the SID type and avoid double mapping.

> could have (as I believe we can) found a better, more interoperable

I am not sure how this I-D would be incompatible with your use of SIDs,
you have SID <-> POSIX IDs mappings anyway so for you it shouldn't make
any difference which set is transmitted, you can always resolve it back
and forth, right ?

> > experience with id mapping, is that there isn't a single method
> > that is "better" than any other. It always depend on the conditions
> > you can impose.
> 
> I agree with the last sentence.  Given one set of constraints there
> may be no method that is better than any other, and given another
> there may be a method that is better than all the others.  I don't
> think this matters very much.  What we need is to determine what
> constraints would apply to an Internet Standard in this area.
> 
> discussing this matter now and leave you be.  If you prefer a
> Standards track RFC then I care veyr much, and seeking consensus will
> require a little more than the assertions you've made so far.

I agree, I am willing to discuss and to compromise everywhere necessary,
but not at the expense of making it impossible for me to also reach my
goals of course.

> > > > If we have to store a map somewhere and we have to consult it
> > > > from the client, then we loose a lot of the advantages a PAC
> > > > provides, although it is a possible outcome. But then I would
> > > > suggest that the KDC has access to the map and provides the
> > > > clients with a ready made translation instead of having the
> > > > client spend cycles contacting an external service.
> > > 

I am not opposed to optimization when that can be achieved as a side
effect :)

> > we need to do I prefer to do it at the KDC level, once, when the
> > TGT is granted, rather then at the service level each time a client
> > logs in, over and over again.

Agreed!

Simo.

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Oct 2010 22:36:44 +0200

> The problem is that for many of us, "new formats" includes XML.  We are constantly exposed to people who want to take perfectly good working things and recast them in XML because it's the latest thing.

SAML is much more than a PAC recast in XML. Actually I'd argue that the proposed draft is the PAC recast in ASN.1 instead of NDR ;-)

-- Luke

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2010 15:44:39 -0500

On Fri, Oct 08, 2010 at 10:36:44PM +0200, Luke Howard wrote:
> > The problem is that for many of us, "new formats" includes XML.  We
> > are constantly exposed to people who want to take perfectly good
> > working things and recast them in XML because it's the latest thing.

+1

> SAML is much more than a PAC recast in XML. Actually I'd argue that
> the proposed draft is the PAC recast in ASN.1 instead of NDR ;-)

And yet also +1 to this.

The way I see it is that a plethora of encodings sucks but it's also a
fact of life.  And SAML does bring more to the table than simply another
encoding method (not least it brings the possibility of SAML
infrastructure re-use, and re-use is a generally a good thing).

In other words, while I agree with the sentiment regarding the addition
of yet another frickin' encoding, I find compelling reasons to dispense
with the sentiment.

Nico

---

From: Luke Howard <[email-masked]>
Date: Sat, 9 Oct 2010 00:13:45 +0200

> infrastructure re-use, and re-use is a generally a good thing).

So, one way to split this up would be into drafts describing:

* use of AD-SignTicket for constrained delegation
* an authorisation data type for containing SAML assertions
* a SAML attribute profile for a POSIX PAC

In terms of implementation: the first is done (MIT/Heimdal); prototype of the second can probably be polished up without too much effort.

See:

	http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

s.8.4 for an attribute profile that describes the DCE PAC (why anyone bothered with this I don't know!)

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 9 Oct 2010 00:22:55 +0200

Whatever happened to SESAME? It seems sufficiently obscure to not have a Wikipedia entry. :-)

https://www.cosic.esat.kuleuven.be/sesame/

-- Luke

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2010 17:24:23 -0500

We've chatted off-list, and we both believe the gulf between us is more
like a puddle.  I'm responding here in great part for the benefit of
others.

> additional requirements in this document.

I want interop and I want it while handling this case.  IMO handwaving
it away won't do.  What good is the ability to use ACLs for
authorization but not being able to build nor [worse!] understand ACLs??

I dunno about others, but I'd think that the need to address this issue
is so obvious that you could guarantee failure to obtain IETF consensus
without addressing it.  I could be wrong about that, but even then the
issue is critical for at least some of us (at least for me).

> credentials in a POSIX world.

I don't think providing for a SID-like representation of ID on the wire
in the PAC remotely means that consumer services must store SIDs on
disk.  I was specifically responding to the comment that ephemeral IDs
"are not suitable for file access" -- they're not, but it doesn't mean
that you cannot use the ID that was mapped into an eph ID for file
acces (exactly what we do).

Nor am I trying to get you to copy our approach.  I'm only asking that
the PAC provide a SID-like ({domain ID, user/group ID[, entity type]})
identifier because that's what we can handle best.  And also because
that's the fundamental quantity in the ID mapping problem at hand, and
whatever solution any OS implementor wishes to apply, this ID form will
one way or another be involved, even if implicitly.

> ping me in private if you want to discuss this point.

You made an assertion that is supposedly relevant to the design of your
and our facilities.  IMO you should either withdraw or justify that
assertion.

> well use LSA too lookup the SID type and avoid double mapping.

Even if you're doing algorithmic mappings there's no need to require
that the UID and GID that a SID maps to be numerically equal.

> any difference which set is transmitted, you can always resolve it back

If you don't provide SID-like IDs then we might not be able to use your
"mapped IDs".  This is one of the things I was alluding to with regard
to what is REQUIRED versus OPTIONAL.

> but not at the expense of making it impossible for me to also reach my

We've chatted off-list, and am glad to report that we both believe the
gulf between us is more like a puddle.

> I am not opposed to optimization when that can be achieved as a side

:)

> > normative language.  Care is required here.

Have a good weekend,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2010 17:32:55 -0500

> not much apparent support for it, of course, though it's still early.

Scott, is that based on a mapping to ASN.1 using PER?  Or is it
something else?  Just curious.

> century. If you can work in some kind of segmented addressing scheme, I'll

We can negotiate an increase.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Luke Howard <[email-masked]>
Date: Sat, 9 Oct 2010 00:35:03 +0200

> authorization but not being able to build nor [worse!] understand ACLs??

Exactly.

SAML might help in the general case: if I want to give "all users at Oracle" access to a resource, and those users are represented by the presence of a particular attribute in an assertion, then I might be able to do away with SIDs/UUIDs/etc entirely.

(Of course, general purpose filesystems that can store these sorts of ACLs may not exist...)

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 9 Oct 2010 00:37:07 +0200

> something else?  Just curious.

After skimming over this:

	http://www.w3.org/TR/2009/CR-exi-20091208/

I'd be inclined to just use gzip :-)

-- Luke

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2010 17:38:14 -0500

> understand how you could safely map UID or GID information across domains.

The moment one talks of mapping POSIX UIDs and GID from multiple local
POSIX namespaces onto another one has made POSIX much, much more useful
than before.  Hopefully one can also manage to retain compatibility with
POSIX apps (which I believe is feasible, yes).

> safely by passing data that has no possible meaning across disparate

I agree.  That's not really useful.  If you're going to assume
federation, then please specify the protocols needed to build the
federation.  Simply specifying the bits that a KDC puts in a PAC is not
sufficient to produce interoperable KDCs -- I'm not talking interoperation
within a realm, but across realms, and not having that seems intolerable
for a new federation proposal.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2010 17:39:42 -0500

> Handling one-way trusts is one of the main aims of this work from my

I think support for federations with one-way trusts is convenient, if
you can get it, but I wouldn't cry much if we didn't get it.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2010 17:46:56 -0500

> For corss-relam trusts users data can be cached on the client side.

Cached from... what?  From other PACs that have flown by?  But that's
not enough to make it possible to resolve the names/IDs that a user
needs to resolve.  That's just not a solution.

Let's put it this way: draft-adamson-... provides for the necessary
lookup methods.  If an implementor wants to implement only support for
the PAC but not the lookup method, that's fine.  You don't have to
implement draft-adamson-...  However, we, the IETF, cannot simply leave
solutions in this space unspecified.

Does that distinction help?

> RFC2307 is used. That's not necessarily the case.

I know.  There's NIS, etcetera.  I'm not trying to solve this problem
for everyone no matter what they have now.  I'm trying to provide for an
interoperable federation solution that can reasonably be implemented and
deployed.  Using LDAP, a well-established Internet protocol, seems like
a reasonable thing to do.  A lot of people who use NIS still today know
that there are good reasons to migrate to LDAP.

> Sorry, I don't understand this comment.

Most multi-realm environments have a per-realm database.

Nico

---

From: Scott Cantor <[email-masked]>
Date: Fri, 8 Oct 2010 20:19:04 -0400

> something else?  Just curious.

I'm not that familiar with it, my only exposure is through discussions in the XML security WG. I don't think it's any relationship to ASN.1, more of a shorthand encoding using dictionaries to replace element names and such with binary IDs.

-- Scott

---

From: Scott Cantor <[email-masked]>
Date: Fri, 8 Oct 2010 20:24:26 -0400

> I'd be inclined to just use gzip :-)

It's basically only of interest if parsers directly support it as an encoding, unlike gzip which would be a pre/post op.

-- Scott

---

From: Scott Cantor <[email-masked]>
Date: Fri, 8 Oct 2010 20:32:34 -0400

On Oct 8, 2010, at 6:35 PM, Luke Howard <[email-masked]> wrote
> (Of course, general purpose filesystems that can store these sorts of ACLs may not exist...)

I don't think it's necessary, using mappings to shadow accounts or groups that represent the local privilege assignments is pretty common.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2010 19:42:18 -0500

On Sat, Oct 09, 2010 at 12:35:03AM +0200, Luke Howard wrote:
> SAML might help in the general case: if I want to give "all users at
> Oracle" access to a resource, and those users are represented by the
> presence of a particular attribute in an assertion, then I might be
> able to do away with SIDs/UUIDs/etc entirely.
> 

What is a "group" in the sense used in POSIX?  (Or Windows?)

A group is a set of users who all have the same access to the same
resources.  (More or less.  Of course it's possible for a user in one
group to have more or less access, than other users in the same group,
to resources whose ACLs reference that group.  But allow me to handwave
that nit for the sake of argument.)

A SAML attribute whose presence/absence in an assertion achieves the
same effect as the user being / not being a member of a "group"... might
as well be thought of as a group.  No, the fact that the SAML attribute
has nothing like a GID (or SID) associated with it isn't terribly
important (except in the sense that having a primary key to refer to the
attribute by will help map it onto a GID or SID).

In other words, the only reason to be interested in such SAML attributes
over "groups" here is because you already use the former without
equivalents of the latter.  I'd be more interested in SAML attributes
which are not so group-like in effects.  Or in assigning IDs to SAML
attributes so we needn't really use them.

Nico

---

From: Simo Sorce <[email-masked]>
Date: Sun, 10 Oct 2010 16:35:08 -0400

On Fri, 8 Oct 2010 17:46:56 -0500
Nicolas Williams <[email-masked]> wrote:

> > > where you can rely on getting the information you need via a
> > > PAC.  Not everything will occur in the context of Kerberos or
> > > other security mechanism that can carry arbitrary PAC-like
> > > contents.
> > > 
> > For the local domain data can, of course, also looked up in the
> > local identity information store, be it a directory or other kind
> > of database.
> > 
> implement draft-adamson-...  However, we, the IETF, cannot simply
> leave solutions in this space unspecified.
> 

Yes, I am not opposed to implementer using additional standards to deal
with the issue of resolving ids and names for administrative purposes.

> > > Can you elaborate?  If there were N>2 radically different schemas
> > > I'd agree.  In practice there's really at most two, and with IDMU
> > > possibly just one with minor variations.  That's not the stuff of
> > > nightmares.
> > 
> > You are assuming that LDAP is the identity information store and
> > that RFC2307 is used. That's not necessarily the case.
> 
> for everyone no matter what they have now.  I'm trying to provide for
> an interoperable federation solution that can reasonably be
> implemented and deployed.  Using LDAP, a well-established Internet
> protocol, seems like a reasonable thing to do.  A lot of people who
> use NIS still today know that there are good reasons to migrate to
> LDAP.

Again, my only aim is to not make LDAP mandatory in this document. If
that's what everybody is going to use in the end I am fine. Not going
to complain.

> > > > > > because maybe it isn't solvable, is what a KDC should do if
> > > > > > the source of the PAC information is unavailable.
> > > > 
> > > > First of all, this assumes that Kerberos information and
> > > > identity information reside in different databases, which is of
> > > > course a very common scenario right now.
> > > 

I've re-read the discussion, I think we misunderstood each other. I
meant that the actual kerberos keys and the user information may be
stored in 2 different databases for the same realm. It is common to use
bdb to store kerberos keys and use another database (NIS, LDAP, ec...)
to store user data instead.
IT may happen that one of the 2 is unavailable, and I was commenting
that IMO, is either is unavailable the KDC should just behaves like
they are both unavailable. But I don't think this needs to be dictate
in the standard unless we determine it has security or other interop.
side effects we need to deal with in a standardized way.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Sun, 10 Oct 2010 16:37:09 -0400

On Fri, 8 Oct 2010 17:39:42 -0500

> you can get it, but I wouldn't cry much if we didn't get it.

If we keep separated access to foreign directories from the PAD
mechanisms, then we can achieve the goal. It will mean some actions are
not possible unless name<->id information is available anonymously. But
I believe that for some environments that's good enough.

Simo.

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 10 Oct 2010 23:18:34 -0500

On Sun, Oct 10, 2010 at 04:35:08PM -0400, Simo Sorce wrote:
> Yes, I am not opposed to implementer using additional standards to
> deal with the issue of resolving ids and names for administrative
> purposes.
> 
> > [...]
> 

So, it was never my intention that your document should require the use
of LDAP.  Our I-D talks about a PAC, though it doesn't specify one, and,
IMO, should not only not specify one (that should be done separately,
and in this WG), but also should not require the use nor implementation
of one either.

My intention is to make sure that your I-D and ours are not only not in
conflict, but usable together, even if each piece can also be used
independently of the other.

> stored in 2 different databases for the same realm. It is common to
> use bdb to store kerberos keys and use another database (NIS, LDAP,
> ec...) to store user data instead.

Ah.

> side effects we need to deal with in a standardized way.

Hmmm, sure.

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 11 Oct 2010 10:27:32 -0700

> I'm not sure what you mean.

A Kerberos request times out after 1 second.  An LDAP request times out after some uncertain amount of time that's frequently 10's of seconds.  If a KDC needs to do an LDAP lookup to satisfy its request then it can't.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Oct 2010 12:45:36 -0500

On Mon, Oct 11, 2010 at 10:27:32AM -0700, Henry B. Hotz wrote:
> A Kerberos request times out after 1 second.  An LDAP request times
> out after some uncertain amount of time that's frequently 10's of
> seconds.  If a KDC needs to do an LDAP lookup to satisfy its request
> then it can't.

Indeed, and that's could be a problem in cross-realm cases, particularly
if you want the KDC to be able to provide a full listing of a
principal's group memberships (if it cannot, then you run into problems
with ACLs that have DENY ACEs with group subjects).  This can be dealt
with by limiting the groups that one uses in DENY ACEs, or even by not
using any groups as subjects of DENY ACEs, as well as by judicious use
of nested groups.

If each KDC only looks up information local to its realm, then the KDC
can be co-located with (or located close to) whatever name services it
will need.  But you'll only get information about a principal from its
realm's KDCs, and from KDCs in a ticket's transit path and the service's
realm, which gets us into the group DENY ACE issue.

And note too that LDAP isn't the issue.  The issue is that the KDC needs
to lookup information about a principal that is by nature distributed.

We might need an error code that says "try again in a few seconds".
Though, of course, getting a new such error into use is hard.  But in
practice I suspect timeouts can be held to just at logon time, and by
the time the client backs off just once, or at most twice, the KDC
should be ready anyways.

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 11 Oct 2010 11:19:39 -0700

LDAP was just the likely example.  The problem is generic to having an external-to-kdc source for authorization (PAC) data.

> the time the client backs off just once, or at most twice, the KDC

Purely for discussion's sake let me throw out a scenario:

Client requests tgt.  KDC fails to get authZ data and returns PAC-less tgt.

Client uses said tgt to get service tickets as traditional, until . . .

Client tries to access service which needs a PAC.  Service tells client that, and client automatically renews its tgt (possibly a few times if necessary) to get one with a PAC.

Client reacquires service ticket and lives happily ever after.

Like I said, I'm not sure this is the right solution, though I like the idea of postponing the retry-for-PAC operation until it's actually necessary.  Otherwise I think we should update 4120 to specify appropriate timeout/retry behavior to cover the possibility of extended delays supporting extended features.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 11 Oct 2010 11:39:03 -0700

> and recast them in XML because it's the latest thing.

+1 X3  ;-)

I suppose if I brought up X.509 attribute certificates as another possible PAC format, everyone would shoot me, right?

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Oct 2010 13:41:11 -0500

> Client requests tgt.  KDC fails to get authZ data and returns PAC-less

The client can't know that there is no PAC, nor that services will
require it.  If the KDC needs to add the PAC then the KDC must not issue
a ticket in the event of name services failures.

HOWEVER, if the service can deal with the absence of the PAC, then
there's no problem.  If the PAC is merely a network optimization, then
indeed, there's no problem.

This might be a good reason to view the PAC as a network optimization,
though if the KDC will issue PAC-less tickets on name service timeouts,
then the clients might too often end up with PAC-less tickets.  In which
case what would be the point of the PAC?

I'm inclined to believe that the KDC should not issue PAC-less tickets
when PACful tickets are desired, even if the PAC is viewed as merely a
network optimization.

> Client tries to access service which needs a PAC.  Service tells
> client that, and client automatically renews its tgt (possibly a few
> times if necessary) to get one with a PAC.

The service has not way to tell the client that it needs a new ticket,
except maybe by returning KRB_AP_ERR_BAD_INTEGRITY.  But for at least
some important protocols (e.g., SSHv2 with gss keyex) this is not a
retriable error, and the user will notice.

> Client reacquires service ticket and lives happily ever after.

I doubt this.  See above.

> Like I said, I'm not sure this is the right solution, though I like
> the idea of postponing the retry-for-PAC operation until it's actually
> necessary.  Otherwise I think we should update 4120 to specify
> appropriate timeout/retry behavior to cover the possibility of
> extended delays supporting extended features.

Maybe, but older clients won't implement the new rules.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Oct 2010 13:48:03 -0500

On Mon, Oct 11, 2010 at 11:39:03AM -0700, Henry B. Hotz wrote:
> I suppose if I brought up X.509 attribute certificates as another
> possible PAC format, everyone would shoot me, right?

No.  IMO any type of "attribute" encoding currently in use somewhere may
turn out to be desirable in PACs.

The principle here is that if you already have an infrastructure
deployed, then you should be able to leverage it, even if that infra
uses a horrible data representation format.  (A sort of love-the-sinner-
hate-the-sin attitude.)

The right thing to do is to have PACs have typed holes.  Authz-data
already is a typed-hole, of course, and AD-KDC-ISSUED too has a typed-
hole.  The trick/option may be to add a signature that the KDC can
verify but which the service cannot forge.

Nico

---

From: Luke Howard <[email-masked]>
Date: Mon, 11 Oct 2010 20:53:25 +0200

> verify but which the service cannot forge.

The approach Heimdal and MIT adopted was to sign the complete set of authorisation data with the TGS key. With this deployed adding a per-auth datum TGS signature seems undesirable.

-- Luke

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 11 Oct 2010 14:59:22 -0400

> verify but which the service cannot forge.

Speaking as an individual...
I don't think it's worthwhile to define a "PAC" which is a typed-hole 
collection of various different types of what are essentially authorization 
data.  Instead we should just use the authorization data hole directly.

I do agree that it's generally a good idea to have authorization data types 
corresponding to whatever sorts of authorization/attribute information is 
already out there, rather than trying to shoehorn all those things into an 
unnecessary common abstraction.  I'm fine with seeing AD types for X.509 
attribute certificates, RADIUS attributes, SAML assertions, and so on. 
There's not really an interop problem here, provided that AD-IF-RELEVANT is 
used when appropriate, and there's plenty to be gained in terms of 
usefulness.

I also agree that the current form of AD-KDC-ISSUED is a bit of a problem, 
and it would be better to have something which cannot be forged by the 
service and does not depend on the session key of the ticket to which it 
applies.  I'm not sure how to do this in a way that doesn't create an 
interoperability problem; particularly, if we come up with AD-KDC-ISSUED2, 
then it more or less always has to be wrapped in AD-IF-RELEVANT, which 
reduces its utility somewhat.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 11 Oct 2010 12:17:30 -0700

> a ticket in the event of name services failures.

The client can see how big the authorization data field is if nothing else.  For this scenario, I'm not proposing the client cares unless a service tells it to care.

> indeed, there's no problem.

Presumably usually the case.

> case what would be the point of the PAC?

The PAC is probably most useful in cross-realm situations when it not only optimizes some stuff, but also provides information that may be unavailable to the target service by any other means.

> when PACful tickets are desired, even if the PAC is viewed as merely a

Presumably the cross-realm (or whatever) case is uncommon enough to justify PAC-less tickets for (e.g.) local use until a PAC-ful ticket is actually needed.  I'm not talking "network optimization" so much as "graceful degradation" here.  An LDAP server is probably more failure-prone than a KDC.

> retriable error, and the user will notice.

Agree that this requires new functionality and probably updates to standards.  Makes this scenario ugly and unattractive IMO.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 11 Oct 2010 12:17:43 -0700

> Obviously this approach is completely orthogonal to the use of SAML as a data representation.

I generally like this approach better than what I proposed.  (Should finish catching up on the thread before responding I suppose.)

One down side is that it assumes things about which party can access what that may not be true.  (This is a slightly bigger problem than the 1-way trust issue discussed, since it may be due to firewall configurations or other ancillary restrictions.)  I'll post a use case separately.

---

From: Luke Howard <[email-masked]>
Date: Mon, 11 Oct 2010 21:27:21 +0200

> The client can see how big the authorization data field is if nothing else.  For this scenario, I'm not proposing the client cares unless a service tells it to care.

The client can see how big the ticket is, that's it; it might be dangerous to make assumptions on the contents based on size.

> Agree that this requires new functionality and probably updates to standards.  Makes this scenario ugly and unattractive IMO.

Better for the server to acquire a PAC-ful ticket using S4U2Self, if it needs one (as Simo points out, this requires bidirectional trust).

--luke

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Oct 2010 14:36:36 -0500

On Mon, Oct 11, 2010 at 12:17:30PM -0700, Henry B. Hotz wrote:
> The client can see how big the authorization data field is if nothing
> else.  For this scenario, I'm not proposing the client cares unless a
> service tells it to care.

Well, no, it can't.  It can only guess from ticket size as to whether
the PAC is present or not.  Also, there may be N authz-data elements
that services may need, but the KDC might have failed to obtain data for
M<N authz-data elements, and then there's no way that the client can
guess whether the KDC included those.

Now, the client could try to get a service ticket for the same cname as
sname (but the KDC is not likely to issue such a ticket), or if the
client has a host principal (not all do), then it could get a service
ticket for it so as to extract the authz-data and determine whether the
KDC put in all authz-data elements that services will need to see.

I don't think there's anything the client can do to reliably ensure that
the KDC did what it needed to before the client tries to authenticate to
other services.

> Presumably usually the case.

Simo does not want to consider his PAC a network optimization.

> The PAC is probably most useful in cross-realm situations when it not
> only optimizes some stuff, but also provides information that may be
> unavailable to the target service by any other means.

Then it's not a network optimization.

> > I'm inclined to believe that the KDC should not issue PAC-less
> > tickets when PACful tickets are desired, even if the PAC is viewed
> > as merely a network optimization.
> 
> Presumably the cross-realm (or whatever) case is uncommon enough to
> justify PAC-less tickets for (e.g.) local use until a PAC-ful ticket
> is actually needed.  I'm not talking "network optimization" so much as
> "graceful degradation" here.  An LDAP server is probably more
> failure-prone than a KDC.

Again, issuing PAC-less-ness when services demand PAC-ful-ness !=
graceful degradation.

> Agree that this requires new functionality and probably updates to
> standards.  Makes this scenario ugly and unattractive IMO.

But there's older clients to worry about.

So far the only solution I see is that the KDC must not issue PAC-less
tickets for principals whose tickets are expected to be PAC-ful.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Oct 2010 14:46:39 -0500

On Mon, Oct 11, 2010 at 02:59:22PM -0400, Jeffrey Hutzelman wrote:
> I don't think it's worthwhile to define a "PAC" which is a
> typed-hole collection of various different types of what are
> essentially authorization data.  Instead we should just use the
> authorization data hole directly.

+1

Luke points out that Heimdal and MIT have an authz-data element to sign
the relevant portions of the ticket (including all other atuhz-data
elements) with a realm key.  Between that, AD-IF-RELEVANT and
AD-KDC-ISSUED we have everything we need.

Instead of defining new PAC-like authz-data we should just assign
authz-data types for specific encodings of specific data structures.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Oct 2010 14:59:25 -0500

> or acquired using S4U2Self, it is available to the server for

I had missed this message.  Yes, I agree that this would work.  And
because such services (other than ones that expect the Windows PAC)
don't exist yet, we are free to pursue this approach.

> Obviously this approach is completely orthogonal to the use of SAML as

Yes.

Nico

---

From: Luke Howard <[email-masked]>
Date: Mon, 11 Oct 2010 22:06:45 +0200

> don't exist yet, we are free to pursue this approach.

Right, it would have been interesting had SSPI done something similar. But S4U didn't exist when W2K shipped (and perhaps Microsoft wouldn't have done it anyway).

-- Luke

---

From: Simo Sorce <[email-masked]>
Date: Mon, 11 Oct 2010 16:47:42 -0400

On Mon, 11 Oct 2010 11:19:39 -0700
"Henry B. Hotz" <[email-masked]> wrote:

> LDAP was just the likely example.  The problem is generic to having
> an external-to-kdc source for authorization (PAC) data.
> 
> >> seconds.  If a KDC needs to do an LDAP lookup to satisfy its
> >> request then it can't.
> > 
> > Indeed, and that's could be a problem in cross-realm cases,
> > particularly if you want the KDC to be able to provide a full
> > listing of a principal's group memberships (if it cannot, then you
> > run into problems with ACLs that have DENY ACEs with group
> > subjects).  This can be dealt with by limiting the groups that one
> > uses in DENY ACEs, or even by not using any groups as subjects of
> > DENY ACEs, as well as by judicious use of nested groups.
> > 
> > If each KDC only looks up information local to its realm, then the
> > KDC can be co-located with (or located close to) whatever name
> > services it will need.  But you'll only get information about a
> > principal from its realm's KDCs, and from KDCs in a ticket's
> > transit path and the service's realm, which gets us into the group
> > DENY ACE issue.
> > 
> > And note too that LDAP isn't the issue.  The issue is that the KDC
> > needs to lookup information about a principal that is by nature
> > distributed.
> > 
> > Though, of course, getting a new such error into use is hard.  But
> > in practice I suspect timeouts can be held to just at logon time,
> > and by the time the client backs off just once, or at most twice,
> > the KDC should be ready anyways.
> > 
> > Nico
> > -- 
> 
> 

This is bad, each service ticket there after would lack the PAC.

> times if necessary) to get one with a PAC.

This requires changes to applications to deal with this error and
require them to know how to obtain tickets, which may be subject to
whatever constraints.
Think of a forwarded TGT obtained initially through PKINIT.

Now, technically, the KDC could simply decide to attach a PAC to the
service ticket if the TGT didn't have one, but this works only within
the same realm. And in that situation the service can probably lookup
the needed information even without access to a PAC ...

but in a cross-realm case you would be left without much chances, but a
fatal failure.

I think that if PACs are in use you must not release a TGT unless the
PAC is available.

> the idea of postponing the retry-for-PAC operation until it's
> actually necessary.  Otherwise I think we should update 4120 to
> specify appropriate timeout/retry behavior to cover the possibility
> of extended delays supporting extended features.

This may already be needed for other extensions. Don't you have the
same problem with KDCs that needs to contact OTP servers as a
pre-authentication plugin ?

Simo.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 11 Oct 2010 13:48:07 -0700

> guess whether the KDC included those.

It can tell if there isn't any authZ data.  If there are multiple authZ elements which may individually fail (not just this PAC) then yeah, were's stuck.

> Simo does not want to consider his PAC a network optimization.

But he and I are happy that it happens to be.  Also there are issues of who can ask for what from whom which the "optimization" happens to solve.

> Then it's not a network optimization.

See above.

> Again, issuing PAC-less-ness when services demand PAC-ful-ness !=

It depends on what fraction of services are which.  If most services either don't need the PAC (for one reason or another) then PAC-less tickets are a degraded-but-functional facility.

> tickets for principals whose tickets are expected to be PAC-ful.

I don't entirely disagree.  It gets really messy really fast if you can't assume your entire infrastructure.

Remember that my starting point was authN in KDC and authZ in LDAP, and the latter (in my experience) is slower and less reliable.  The entire combination has unpleasant aspects.

---

From: Simo Sorce <[email-masked]>
Date: Mon, 11 Oct 2010 16:56:51 -0400

On Mon, 11 Oct 2010 12:17:30 -0700
"Henry B. Hotz" <[email-masked]> wrote:

> > require it.  If the KDC needs to add the PAC then the KDC must not
> > issue a ticket in the event of name services failures.
> 
> > there's no problem.  If the PAC is merely a network optimization,
> > then indeed, there's no problem.
> 
> > This might be a good reason to view the PAC as a network
> > optimization, though if the KDC will issue PAC-less tickets on name
> > service timeouts, then the clients might too often end up with
> > PAC-less tickets.  In which case what would be the point of the PAC?
> 

You nailed it.

> is actually needed.  I'm not talking "network optimization" so much
> as "graceful degradation" here.  An LDAP server is probably more

I guess a KDC could release PAC-less tickets for the local realm and
force a PAC only on cross-realm tickets. I think this could be an
acceptable compromise.
I would hope implementations would give control of whether and for
which tickets to allow or not allow to return PAC-less tickets to
admins, which can then decide whether to allow PAC-less or not and for
what kind of tickets.

> >> client that, and client automatically renews its tgt (possibly a
> >> few times if necessary) to get one with a PAC.
> > 
> > The service has not way to tell the client that it needs a new
> > ticket, except maybe by returning KRB_AP_ERR_BAD_INTEGRITY.  But
> > for at least some important protocols (e.g., SSHv2 with gss keyex)
> > this is not a retriable error, and the user will notice.
> 

Yes, allowing for PAC-less, may indeed cause more work than simply
allowing for longer delays in the TGT acquisition timeout.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Mon, 11 Oct 2010 16:58:22 -0400

On Mon, 11 Oct 2010 21:27:21 +0200
Luke Howard <[email-masked]> wrote:

> > The client can see how big the authorization data field is if
> > nothing else.  For this scenario, I'm not proposing the client
> > cares unless a service tells it to care.
> 
> The client can see how big the ticket is, that's it; it might be
> dangerous to make assumptions on the contents based on size.
> 
> Better for the server to acquire a PAC-ful ticket using S4U2Self, if
> it needs one (as Simo points out, this requires bidirectional trust).

bidirectional trust is not only what is required it requires also that
the KDC trusts the service to impersonate the user to some degree,
which you may or may not want to allow on all services.
Granted, this is not S4U2Proxy, but still...

Simo.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Oct 2010 15:57:22 -0500

> This is bad, each service ticket there after would lack the PAC.

BTW, Luke describes how services can use S4U2Self to obtain a ticket
with the missing PAC data.  Separately Martin points out that clients
can use user2user to observice their TGTs' authz-data.

The KDC could always add an authz-data element to indicate that it
should have added others but failed to due to transient failures.  Then
the services could use Luke's approach to obtain the missing authz-data.

> pre-authentication plugin ?

Probably.  But a client using OTP pre-auth is likely to be able to
impose different timeout processing on those such AS exchanges.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Oct 2010 16:03:41 -0500

On Mon, Oct 11, 2010 at 01:48:07PM -0700, Henry B. Hotz wrote:
> Remember that my starting point was authN in KDC and authZ in LDAP,
> and the latter (in my experience) is slower and less reliable.  The
> entire combination has unpleasant aspects.

My experience is that clients that do asynchronous LDAP searches can get
pretty good performance.  But also, for some searches (such as searches
keyed by multi-valued attributes, as in the case of RFC2307 group
membership searches) you're really at the mercy of the server: does it
index the attribute's values properly?  or does it do full
table^H^H^H^H^Hclass scans?

Nico

---

From: Simo Sorce <[email-masked]>
Date: Mon, 11 Oct 2010 17:18:15 -0400

On Mon, 11 Oct 2010 15:57:22 -0500
Nicolas Williams <[email-masked]> wrote:

> should have added others but failed to due to transient failures.
> Then the services could use Luke's approach to obtain the missing
> authz-data.

I see 2 problems with this, although it could be an acceptable
compromise.

We are trading A) waiting a few more second to get a TGT and then never
have problems thereafter, with potentially saving a second or 2 at TGT
time, and B) then have each authentication to a service have to wait
seconds because they have to contact the KDC.

By doing it this way we are increasing the load on the KDC because now
it can potentially have to fetch authZ information many time for each
user instead of once at TGT time and never thereafter until the TGT
expires.

Also, because the service will do s4u2self it means this overhead may
happen *every* time a user connects to the service. Because the service
cannot return this info to the client, and unless it is so smart to
keep a cache of self-obtained tickets (for how long ?).

Think of a webserver that wants to use the PAC in order to do
authorization (based on group memberships). Then every single HTTP
request may end up triggering a S4U2Self operation. Granted in such a
case you would probably implement some form of caching, but I hope the
example makes sense.

> > > Like I said, I'm not sure this is the right solution, though I
> > > like the idea of postponing the retry-for-PAC operation until it's
> > > specify appropriate timeout/retry behavior to cover the
> > > possibility of extended delays supporting extended features.
> > 

Perhaps, but then you can do the same for a client expecting a PAC in
the ticket ;-)

Simo.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Oct 2010 14:21:25 -0500

> lot of sense when you have service organizations talking/trusting other

I think we have to accept one-way trusts, but I don't really think they
make that much sense.  I'd much rather have something like bi-di trust
that's "weak" in one direction: weak meaning that the KDCs for one realm
will issue service tickets for only a few select service principals to
client principals from the other realm.  Thus in a weak bi-di trust you
might have clients from some realms only be able to get LDAP (or
whatever) service tickets from a weakly-trusting realm, and those
services would likely also treat those foreign clients with much
suspicion (e.g., by limiting what their access dramatically).

> clients/servers is required.

Thanks, that's helpful.

> one to hold a "short domain name" as well for other interop and

You'd need a reverse lookup facility for this, replete with an
in-addr.arpa.-type zone.

Also, the DNS cannot be the "registrar" for "short domain names" if
those aren't actual DNS domainnames.

IMO these registrations are best left to the federation itself.  That
is, when a domain wants to join a federation it must, among other
things, register its domain ID and short-form name in a service provided
by that federation.  Federations will require some minimum of common
infrastructure (such as a realm to provide for transit paths to all
domains in the federation, but also most likely at least a _small_ LDAP
directory containing registration information).

> these 2 IDs. What would be the right forum to discuss this topic ?

Good question.  I'm not sure.  I don't think we have enough work to
justify a new WG, and neither NFSv4 nor KRB-WG are really appropriate
for all the parts of these two I-Ds.  The soon to be ABFAB WG sounds
much more appropriate, but they may not welcome the distraction.  No
other WGs seem appropriate.

Dear KRB-WG chairs, would you mind if we continue this discussion here?

> translation layer which adds a whole host of issues.

As I clarified elsewhere, I don't mean that KDCs should be REQUIRED to
implement LDAP as their method for resolving client principals' PAC
contents.  I do mean that for draft-adamson-... we should make LDAP
required-to-implement.  I don't mean that other protocols cannot be
used, nor that LDAP must be used.

I'm not sure how much experience you have at the IETF, but these
implement-versus-use distinctions matter.  In order to get a protocol to
eventually be an Internet Standard there must be minimum, interoperable
implementation requirements.  Such requirements typically do not and
should not (must not! IMO) preclude variations that are not required-to-
implement but which are nonetheless common.  I can't think of many cases
where we impose requirements to use something rather than merely
implement it.  Even the DNS, which is so ubiquitous, is not required to
be used (except, of course, in the case of discovery methods that use
SRV RRs and so on, but the alternative in those cases is to use
different discovery methods if you don't want to use DNS).

> my preference on others if I can help it (and I think I can).

My reason for wanting LDAP here is that it is the Internet protocol that
we have for this.  Whether LDAP is a nice/great/lousy protocol is not
nearly as important to me.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Oct 2010 16:22:03 -0500

> I see 2 problems with this, although it could be an acceptable

I see the same problems, but if we think transient failures leading to
PAC-less tickets will be rare then this could be a graceful fallback.
OTOH, because services will be doing extra lookups, this graceful
fallback could merely create more pressure, leading to more failures.

> Perhaps, but then you can do the same for a client expecting a PAC in

No, because the client can't know that it should expect the PAC, not
existing clients.  But since existing OTP-capable clients are so few (or
non-existent) at this time, we could expect them to have different
timeout behavior.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Mon, 11 Oct 2010 17:29:39 -0400

On Mon, 11 Oct 2010 13:48:03 -0500
Nicolas Williams <[email-masked]> wrote:

> > > The problem is that for many of us, "new formats" includes XML.
> > > We are constantly exposed to people who want to take perfectly
> > > good working things and recast them in XML because it's the
> > > latest thing.
> > 
> > +1 X3  ;-)
> > 
> No.  IMO any type of "attribute" encoding currently in use somewhere
> may turn out to be desirable in PACs.
> 
> uses a horrible data representation format.  (A sort of
> love-the-sinner- hate-the-sin attitude.)
> 

This is a requirement anyway. There are cases where you want to use the
PAC in the OS but it comes in by way of a lesser trusted Application.
In that case you must validate the PAC with the KDC (yeah this may
require some new protocol extension, or other trickery :-).

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Mon, 11 Oct 2010 17:35:14 -0400

On Mon, 11 Oct 2010 22:06:45 +0200
Luke Howard <[email-masked]> wrote:

> Right, it would have been interesting had SSPI done something
> similar. But S4U didn't exist when W2K shipped (and perhaps Microsoft
> wouldn't have done it anyway).

MS has the same constraint I'd like to have: working one-way trusts
setups. That pretty much rules out a technicque that requires:
a) two way trusts
b) all clients of domain 2 be able to reach the KDCs of domain 1

I still would like to fall back to S4U only as a deployment option, not
to have it as the default method.

Simo.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 11 Oct 2010 14:45:41 -0700

I did say this scenario was for discussion's sake only.  It's safe to say that nobody likes it, I guess.

> require them to know how to obtain tickets, which may be subject to

"Renew" as in "kinit -R".  No need to go all the way back to the original AS mechanism, or ask for a new OTP or card plugin.

> I think that if PACs are in use you must not release a TGT unless the

Valid points.  See reply to Nico.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 11 Oct 2010 15:02:52 -0700

> to have it as the default method.

Agree on all points.  There are going to be situations where organizational requirements prohibit a 2-way trust, but not a 1-way.  This isn't just a technical issue.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 11 Oct 2010 15:03:07 -0700

> non-existent) at this time, we could expect them to have different

AFAICT neither 4120, nor draft-ietf-krb-wg-otp-preauth, say anything at all about protocol timeouts.  However all (well, both MIT and Heimdal) implementations have a 1-second timeout for getting an AS-REP.  

IMO that means that a change in timeout behavior is required, and requires some mention in draft-sorce-..., even if it's only an implementation note in an appendix.

---

From: Simo Sorce <[email-masked]>
Date: Mon, 11 Oct 2010 18:18:28 -0400

On Mon, 11 Oct 2010 15:03:07 -0700
"Henry B. Hotz" <[email-masked]> wrote:

> >> Perhaps, but then you can do the same for a client expecting a PAC
> >> in the ticket ;-)
> > 
> > existing clients.  But since existing OTP-capable clients are so
> > few (or non-existent) at this time, we could expect them to have
> > different timeout behavior.
> 
> 
> AFAICT neither 4120, nor draft-ietf-krb-wg-otp-preauth, say anything
> at all about protocol timeouts.  However all (well, both MIT and
> Heimdal) implementations have a 1-second timeout for getting an
> AS-REP.  
> 
> IMO that means that a change in timeout behavior is required, and
> requires some mention in draft-sorce-..., even if it's only an
> implementation note in an appendix.

Noted.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Oct 2010 17:37:04 -0500

Right.

> Heimdal) implementations have a 1-second timeout for getting an

Plus exponential back-off.

> implementation note in an appendix.

The problem is that clients are free to be blissfully unaware of
authz-data.  Also, because of the existing exponential back-off and
re-try client behavior, KDCs should have enough time, and clients should
be able to get the tickets they need.

I'd like to see an error code added that says "try again in a bit" or
"don't resend your AS-REQ yet, don't timeout yet, your AS-REP is
coming".

I'm not sure that updating RFC4120 via this I-D is a good idea.  I'd
rather have a separate, very short I-D updating RFC4120 just to add text
on client timeout/retry behavior and/or any new error codes.

Nico

---

From: Simo Sorce <[email-masked]>
Date: Mon, 11 Oct 2010 18:46:04 -0400

On Mon, 11 Oct 2010 17:37:04 -0500
Nicolas Williams <[email-masked]> wrote:

> rather have a separate, very short I-D updating RFC4120 just to add
> text on client timeout/retry behavior and/or any new error codes.

I'd also prefer to not update RFC4120 here, but have a separate one.

Simo.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 11 Oct 2010 16:48:03 -0700

> I'd also prefer to not update RFC4120 here, but have a separate one.

Nit:  is it an update if we're defining previously undefined stuff?

In any case I like the idea of defining a new reply that says "wait xx for a reply", and saying it needs to be returned within the current expected timeout (i.e. 1 second).  Do we have a volunteer to write it?  Should be really short;  I hope there aren't any non-obvious side effects.

Given how open-ended certificate validation can be, I'd think it could be useful for PKINIT deployments sometimes.  OTP is obviously another beneficiary.

Of course, implementation wise, it probably means a multi-threaded/-tasking KDC.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Oct 2010 18:52:09 -0500

Yes.

> In any case I like the idea of defining a new reply that says "wait xx
> for a reply", and saying it needs to be returned within the current
> expected timeout (i.e. 1 second).  Do we have a volunteer to write it?
> Should be really short;  I hope there aren't any non-obvious side
> effects.

We might want to define a new kdc-options flag to indicate that the
client can handle this.

> Given how open-ended certificate validation can be, I'd think it could
> be useful for PKINIT deployments sometimes.  OTP is obviously another
> beneficiary.

No kidding.

> multi-threaded/-tasking KDC.

That was implied by any pre-auth method, KDB backend, or authz-data
polulation method that could block for long periods of time.  The
update needn't say anything about that (though as a comment to
implementors it'd be OK).
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 11 Oct 2010 17:18:23 -0700

On Oct 11, 2010, at 4:52 PM, Nicolas Williams wrote:

>> Do we have a volunteer to write it?

That didn't sound like a volunteer.  Given how long it takes to get stuff cleared for release here I'm not a good choice.

---

From: Luke Howard <[email-masked]>
Date: Tue, 12 Oct 2010 21:19:23 +1100

> Granted, this is not S4U2Proxy, but still...

S4U2Self is always allowed. The policy knob controls whether S4U2Self can issue forwardable tickets or not.

This is not an exposure because services can always forge tickets to themselves.

-- Luke

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Oct 2010 14:18:22 -0400

--On Monday, October 11, 2010 01:48:07 PM -0700 "Henry B. Hotz" 
<[email-masked]> wrote:

> It can tell if there isn't any authZ data.

No, it really cannot.  Authorization data is in the encrypted part of the 
ticket and is not visible to clients, period.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Oct 2010 14:48:06 -0400

> Dear KRB-WG chairs, would you mind if we continue this discussion here?

I don't see a problem with that, for now.  Eventually this will have to 
find a home, and it's beginning to sound like this isn't going to be it.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Oct 2010 13:49:55 -0500

On Tue, Oct 12, 2010 at 02:18:22PM -0400, Jeffrey Hutzelman wrote:
> No, it really cannot.  Authorization data is in the encrypted part
> of the ticket and is not visible to clients, period.

Martin points out that the user can always get a u2u ticket for
themselves and then observe the authz-data (assuming that the TGS
wouldn't strip the authz-data from the TGT as part of a policy of not
revealing that data to the user).
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Oct 2010 15:31:33 -0400

> revealing that data to the user).

That assumes the authz data is the same for every service.  It might not 
be, and particularly for foreign-realm services, the KDC might well have a 
policy of not revealing some of that data to the foreign realm.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Oct 2010 14:35:23 -0500

On Tue, Oct 12, 2010 at 03:31:33PM -0400, Jeffrey Hutzelman wrote:
> That assumes the authz data is the same for every service.  It might
> not be, and particularly for foreign-realm services, the KDC might
> well have a policy of not revealing some of that data to the foreign
> realm.

Yes, and in a cross-realm situation the user really can't see the same
authz-data that services will see.

It would have been nice if the KDC-REP EncKDCRepPart had had an
authz-data field so the client could see what authz-data the KDC added
to the resulting ticket that the KDC is willing to show the client...

Nico