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

classic Classic list List threaded Threaded
115 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

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

ietf+hardjono.net
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: [hidden email] [mailto:i-d-announce-
> [hidden email]] On Behalf Of [hidden email]
> Sent: Thursday, October 07, 2010 3:00 PM
> To: [hidden email]
> 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
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman
--On Thursday, October 07, 2010 03:25:23 PM -0400 Thomas Hardjono
<[hidden email]> wrote:

> 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.

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
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams-2
In reply to this post by ietf+hardjono.net
On Thu, Oct 07, 2010 at 03:25:23PM -0400, Thomas Hardjono wrote:
> 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.

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
--
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

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

> On Thu, Oct 07, 2010 at 03:25:23PM -0400, Thomas Hardjono wrote:
> > 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.
>
> 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
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams-2
On Thu, Oct 07, 2010 at 04:43:55PM -0400, Simo Sorce wrote:
> On Thu, 7 Oct 2010 15:39:21 -0500
> Nicolas Williams <[hidden email]> 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.
>
> 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
--
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams-2
On Thu, Oct 07, 2010 at 04:29:53PM -0500, Nicolas Williams wrote:
>       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.)

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
--
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams-2
In reply to this post by Simo Sorce
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
--
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Henry B. Hotz
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.

On Oct 7, 2010, at 4:46 PM, Nicolas Williams wrote:

> - 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.

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



_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Luke Howard
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
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Luke Howard
In reply to this post by Henry B. Hotz
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
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams-2
In reply to this post by Henry B. Hotz
[Note: please top-post.]

On Thu, Oct 07, 2010 at 05:38:47PM -0700, Henry B. Hotz wrote:

> On Oct 7, 2010, at 4:46 PM, Nicolas Williams wrote:
> > - 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.
>
> 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
--
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams-2
In reply to this post by Luke Howard
On Fri, Oct 08, 2010 at 04:03:33AM +0200, Luke Howard wrote:
> Consider using AD-KDCIssued instead of a server signature: it is
> 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.
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams-2
In reply to this post by Luke Howard
On Fri, Oct 08, 2010 at 03:40:22AM +0200, Luke Howard wrote:
> I'd like to see SAML used for this rather than transposing the MS PAC
> to POSIX :-)

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
--
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Luke Howard

On 08/10/2010, at 5:32 AM, Nicolas Williams wrote:

> On Fri, Oct 08, 2010 at 03:40:22AM +0200, Luke Howard wrote:
>> I'd like to see SAML used for this rather than transposing the MS PAC
>> to POSIX :-)
>
> 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

* http://k5wiki.kerberos.org/wiki/Projects/SAMLInKerberos
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce
In reply to this post by Nicolas Williams-2
On Thu, 7 Oct 2010 16:29:53 -0500
Nicolas Williams <[hidden email]> wrote:

> On Thu, Oct 07, 2010 at 04:43:55PM -0400, Simo Sorce wrote:
> > On Thu, 7 Oct 2010 15:39:21 -0500
> > Nicolas Williams <[hidden email]> 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.
> >
> > 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.

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

> 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).

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.

>  - 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

        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).

>       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.)

        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.

>     - 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.

        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.

> Basically, I don't think it's always appropriate, or even always
> 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.

> 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.

        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
>     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.

        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).

> 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.

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.

--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce
In reply to this post by Nicolas Williams-2
On Thu, 7 Oct 2010 16:48:35 -0500
Nicolas Williams <[hidden email]> wrote:

> On Thu, Oct 07, 2010 at 04:29:53PM -0500, Nicolas Williams wrote:
> >       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.)
>
> 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.

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.

--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce
In reply to this post by Nicolas Williams-2
On Thu, 7 Oct 2010 18:46:12 -0500
Nicolas Williams <[hidden email]> wrote:

> 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).

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).

>  - 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.

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

>     - 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.

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

>  - 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.

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..

>  - What's REQUIRED, RECOMMENDED and what's OPTIONAL.
>
> 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.

--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce
In reply to this post by Luke Howard
On Fri, 8 Oct 2010 03:40:22 +0200
Luke Howard <[hidden email]> wrote:

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

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

Simo.

--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce
In reply to this post by Luke Howard
On Fri, 8 Oct 2010 11:49:35 +0200
Luke Howard <[hidden email]> wrote:

>
> On 08/10/2010, at 5:32 AM, Nicolas Williams wrote:
>
> > On Fri, Oct 08, 2010 at 03:40:22AM +0200, Luke Howard wrote:
> >> I'd like to see SAML used for this rather than transposing the MS
> >> PAC to POSIX :-)
> >
> > 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
>
> * http://k5wiki.kerberos.org/wiki/Projects/SAMLInKerberos

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.

--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
ietf-krb-wg mailing list
[hidden email]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce
In reply to this post by Luke Howard
On Fri, 8 Oct 2010 04:03:33 +0200
Luke Howard <[hidden email]> wrote:

> 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?

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

Simo.

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