Subject: [KAML] Re: Chicago bar-BOF summary

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 6 Sep 2007 12:29:48 -0700

Do we have anyone else from NASA on this list?  JPL is an FFRDC, not  
a civil service lab.  We may have different perspectives on this.   
Also I know some of the push to do this came from other NASA concerns.

We want to create applications that may specifically require that the  
user authenticated with a smart card.  Based on NIST SP800-63 they  
may be medium-security applications where the card may have been used  
to get Kerberos credentials, or they may be high-security  
applications where the card has to be in the reader and used  
directly.  The bulk of the applications we need to worry about will  
be "medium".

I'm not sure I can comment on item 3.  I think that "we" think we can  
configure Sun Access Manager to do what we need there, and new  
standards are not immediately necessary.

I see 1, and 2 as not being necessarily different.  I think our goal  
is to come up with a way to represent authorization information, like  
what 800-63 specifies, in a portable, extensible manner.  I will take  
it on faith (for now) that SAML has the necessary flexibility for the  
job.  So what are the issues that need discussing?

Or do we just start discussing how to put SAML tokens into the  
authorization data field and what constraints we impose on how the  
tokens are encrypted/validated.

I need to know that there is an API path for getting that information  
out of the ticket and inspecting/querying it.  I also need to know  
that will be possible on *nix as well as Windows.  That means that  
whatever we propose needs to get implemented in at least one of the  
open-source Kerberos packages as well as in Windows.  That would seem  
to drag the GSSAPI folks back into the discussion at some point.  If  
we come up with a standard that solves NASA's problem, then I think  
Microsoft is likely to implement it.

Begin message:

> From: Leif Johansson <[email-masked]>
> Date: September 5, 2007 12:37:37 AM PDT
> To: "Henry B. Hotz" <[email-masked]>
> Subject: [Fwd: [KAML] Chicago bar-BOF summary]
>
> you didn't see this?
>
>     cheers Leif
>
> From: Leif Johansson <[email-masked]>
> Date: August 22, 2007 1:10:31 PM PDT
> To: [email-masked]
> Subject: [KAML] Chicago bar-BOF summary
>
>
>
> Hello and welcome to the kaml list. This list is the result of a  
> bar-BOF
> at the last IETF meeting in Chicago were a few SAMListas and well-
> known members of the kerberos wg met and tried to come up with a
> list of use-cases which might involve both SAML and kerberos.
>
> Let me first say that we are clearly talking about several rather
> loosely connected use-cases. This is probably not a complete
> list of things we discussed in Chicago and I hope everyone will
> contribute stuff of their own.
>
> The use-cases:
>
> 1. Was a smart-card used?
>
> This is my interpretation of problems posed by Douglas Engert
> of ANL and Henry Hotz of Nasa.
>
> The problem is to determine exactly how authentication was done
> at a relying party, for instance if pkinit with a smart-card was used.
> In general the RP may be at the end of a chain of (say) clients using
> a gssapi-based protocol with credentials delegation, for instance a
> SOAP-based service  sitting behind a web-application, both using
> NTLM/Negotiate for authentication. In this case the RP has no way
> to make decisions about how the initial authentication was done.
>
> In SAML parlance this may be framed both in terms of the concept
> of Level of Assurance and the SAML Authentication Context.
>
> It seems clear that any analysis of this use-case would need to span
> both Kerberos and GSS-API. In kitten there has been discussion
> about how to represent authz-data. This would clearly be related.
>
> 2. The standarized PAC
>
> An AD domain controller includes data about the groups a user is
> a member of in the PA-DATA field of the KDC-REP. A generalization
> of this concept might be to include a SAML authentication response
> in the PA-DATA. This could be used together with anonymous
> kerberos to control which identity information is made available
> to the RP.
>
> 3. WebSSO kerberos n-tier.
>
> A web-application using the SAML Web SSO profile needs a kerberos
> ticket for accessing kerberized backend services. This kerberos ticket
> needs to be produced by the Identity Provider and made available to
> the Relying Party (or Service Provider).
>
> Hope this is enough to get things started. I know the smart-card use-
> case was discussed on the heimdal list (although possibly not in the
> generality I presented above). Other use-cases have been discussed
> on other lists.
>
>        Cheers Leif
>
> _______________________________________________
> KAML mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/kaml
>
>

_______________________________________________
KAML mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kaml

---

From: "Tom Scavo" <[email-masked]>
Date: Thu, 6 Sep 2007 16:03:36 -0400

> tokens are encrypted/validated.

FWIW, we are embedding SAML assertions in short-lived X.509
certificates and using the latter as decorated authentication tokens
in grids.  The SAML assertions (not responses or other SAML protocol
constructs) contain authentication and attribute information used for
access control purposes.  A big advantage of this approach (we think)
is that the SAML goes along for the ride regardless of how the X.509
certificate is presented to the relying party, either TLS or some
message-level protocol such as WS-Security X.509 Token Profile.

Use cases are varied.  The presenter may be the subject or an entity
(such as a portal) acting on behalf of the subject.  The SAML
assertion may be issued by the same entity that issued the X.509
certificate (in which case the requirements on the SAML assertion are
minimal) or by some third party (in which case the assertion is a
signed, standalone token).

Tom Scavo
NCSA

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 06 Sep 2007 15:14:14 -0500

There are a few reasons I have not commented on this.

One is that NASA is the one concerned, but other agencies will have
the same problem. Good to see Henry responded.

Another is the concern Henry has below with Microsoft, i.e. getting
them to add anything we do to their KDC.

A third is I am not sure if SAML is the way to do this. I am not saying
it is not a good idea, but it may be complicated for the immediate problem.

The immediate problem is with the use of a PIV smartcard, and how to
prove to the service that it was used for the authentication. In addition
the certificate might contain additional information that is not of use
to the KDC, but is needed by the service. For example the FASC-N.

So in the case of PKINIT, I would like to see the KDC pass on the
certificate.

In a more general case, if a proxy certificate chain was used  (RFC 3820)
pass on the chain as well. A proxy certificate may have a ProxyPolicy:
    "The proxyPolicy field specifies a policy on the use of this
    certificate for the purposes of authorization."

The ProxyPolicy may not have any relevance for the KDC that is doing
authentication, but may for the final service which is doing the authorization.

The approach of passing on the certificate (and chain) keeps changes
to a minimum in the KDC.  Some may say that this emasculates Kerberos as
it is just passing on X509, but thats what makes it look so attractive,
it keeps the KDC changes and policy decisions to a minimum, and passes
on any additional authorization data the user/cert may have provided
to the final service.

Henry B. Hotz wrote:
> Do we have anyone else from NASA on this list?  JPL is an FFRDC, not a 
> civil service lab.  We may have different perspectives on this.  Also I 
> know some of the push to do this came from other NASA concerns.
> 
> user authenticated with a smart card.  Based on NIST SP800-63 they may 
> be medium-security applications where the card may have been used to get 
> Kerberos credentials, or they may be high-security applications where 
> the card has to be in the reader and used directly.  The bulk of the 
> applications we need to worry about will be "medium".
> 
> configure Sun Access Manager to do what we need there, and new standards 
> are not immediately necessary.
> 
> I see 1, and 2 as not being necessarily different.  I think our goal is 
> to come up with a way to represent authorization information, like what 
> 800-63 specifies, in a portable, extensible manner.  I will take it on 
> faith (for now) that SAML has the necessary flexibility for the job.  So 
> what are the issues that need discussing?
> 
> out of the ticket and inspecting/querying it.  I also need to know that 
> will be possible on *nix as well as Windows.  That means that whatever 
> we propose needs to get implemented in at least one of the open-source 
> Kerberos packages as well as in Windows.  That would seem to drag the 
> GSSAPI folks back into the discussion at some point.  If we come up with 
> a standard that solves NASA's problem, then I think Microsoft is likely 
> to implement it.
> 
> Begin message:
> 
>> Hello and welcome to the kaml list. This list is the result of a bar-BOF

-- 

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

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 06 Sep 2007 15:35:53 -0500

Tom Scavo wrote:
> certificates 

So you are talking RFC3820 proxy certificates?

> and using the latter as decorated authentication tokens

One problem is that PKINIT today does use any of these assertions
when issuing a TGT, and does not forward these assertions in the TGT.
Thus my suggestion of passing the cert and chain in the TGT.

Now if SAML processing is added to the KDC, maybe it should pass
along any SAML assertions found in the cert cert chain rather then
the full cert.

--

---

From: "Tom Scavo" <[email-masked]>
Date: Thu, 6 Sep 2007 16:56:40 -0400

> So you are talking RFC3820 proxy certificates?

Yes, we have a tool that issues a proxy certificate with a SAML
assertion bound to a non-critical certificate extension.  We also have
an online CA that issues short-lived end entity certificates with a
similar extension.

> along any SAML assertions found in the cert cert chain rather then

Again, just to illustrate our particular use of SAML, the relying
party traverses the certificate chain up to the first
non-impersonation proxy (which in practice is usually the EEC) and
consumes any and all bound SAML assertions.  So multiple assertions
may be involved, from multiple SAML issuers.

Tom Scavo
NCSA

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 6 Sep 2007 14:54:06 -0700

> the same problem. Good to see Henry responded.

Yeah, it's NASA, not JPL/Caltech, that's asking for the capability  
ATM.  The NASA PIV infrastructure solution is a bit more AD-centric  
than ours (as currently planned).

> them to add anything we do to their KDC.

As I understand it NASA asked Microsoft to add a PAC-like attribute  
that explicitly listed the 800-63 assurance level.  MS said no, but  
they would implement a similar capability if it passed the standards  
process.  This is pure rumor, and not binding on Microsoft you  
understand.

We've both said this is a concern, now, but I think we can put it  
aside for the time being.

> it is not a good idea, but it may be complicated for the immediate  

For this list, let me reiterate my feelings:  speaking for myself, I  
agree with you.  The fact that X509 and Kerberos share ASN1 as  
infrastructure is part of what made it possible to implement so much  
X509 functionality in Heimdal.  If we shift to XML encoding for SAML  
data then we are adding significantly to the infrastructure needed to  
provide a complete solution.  If we just forward the original cert,  
then it provides the necessary information, but doesn't require any  
additional infrastructure (even if we need to parse extra cert  
attributes).

Question:  Is it possible to create valid SAML tokens in XER?

Now I can speculate as to what JPLs position might be.  There are a  
significant number of developers in at least two organizations that  
are really heavy into all the SOA/XML services stuff.  We also have  
an official rep to OASIS.  I suspect that those guys would strongly  
advocate using real SAML tokens.  They probably have some use cases  
that would benefit from SAML-in-Kerberos.

> on any additional authorization data the user/cert may have provided

Does anyone have any use cases that demonstrate a SAML (KAML)  
solution is better/easier than just including the cert?  It's a  
classic question of how much processing do you put in the server vs  
the client.  A pre-evaluated SAML assertion should be simpler for the  
client, but would prohibit unanticipated uses of the original  
certificate data.

My own use case is a bit degenerate.  I think if PKINIT was used to  
get the ticket then I'm OK for medium-level authenticated access.  I  
could use some API improvements to make it easier to check that, but  
I don't actually think I need any protocol extensions yet.

> Henry B. Hotz wrote:
>> Do we have anyone else from NASA on this list?  JPL is an FFRDC,  
>> not a civil service lab.  We may have different perspectives on  
>> this.  Also I know some of the push to do this came from other  
>> NASA concerns.
>> We want to create applications that may specifically require that  
>> the user authenticated with a smart card.  Based on NIST SP800-63  
>> they may be medium-security applications where the card may have  
>> been used to get Kerberos credentials, or they may be high- 
>> security applications where the card has to be in the reader and  
>> used directly.  The bulk of the applications we need to worry  
>> about will be "medium".
>> I'm not sure I can comment on item 3.  I think that "we" think we  
>> can configure Sun Access Manager to do what we need there, and new  
>> I see 1, and 2 as not being necessarily different.  I think our  
>> goal is to come up with a way to represent authorization  
>> information, like what 800-63 specifies, in a portable, extensible  
>> manner.  I will take it on faith (for now) that SAML has the  
>> necessary flexibility for the job.  So what are the issues that  
>> need discussing?
>> I need to know that there is an API path for getting that  
>> information out of the ticket and inspecting/querying it.  I also  
>> need to know that will be possible on *nix as well as Windows.   
>> That means that whatever we propose needs to get implemented in at  
>> least one of the open-source Kerberos packages as well as in  
>> Windows.  That would seem to drag the GSSAPI folks back into the  
>> discussion at some point.  If we come up with a standard that  
>> solves NASA's problem, then I think Microsoft is likely to  
>> implement it.
>> Begin message:

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

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 6 Sep 2007 14:55:22 -0700

Out of curiosity, are these KX-509-issued certs?

On Sep 6, 2007, at 1:03 PM, Tom Scavo wrote:

> in grids.

---

From: "Taylor, Dennis C. (GSFC-720.0)[INDUS]" <[email-masked]>
Date: Thu, 6 Sep 2007 17:24:31 -0500

Henry,

I am monitoring the list and can speak to the other NASA perspective,
perhaps sans JPL.  Sorry for the slow response, we are mostly all tied
up around activities related to card issuance--deadline this Oct.

NASA is AD centric in our plans for authentication.  It is the majority
case.  The other method is Sun Access Manager.  It is unclear whether
authentication within AM will be TLS to the card, SPNEGO to AD, or both.

I am back to speaking with Microsoft on getting a representation of the
LoA for authentication to be stored in their PAC.  This may be the best
near term approach for us.  NASA has approximately 5000 applications.
If LoA needs for many of them can be meet by a simple ACL addition then
that's the best path for us.  Around that path is the question about how
LoA is represented.  We think security group representation is probably
best...there are still issues about when, in the life an authentication
transaction, the group logic is implemented.

But this is all internal looking--long term I know we have to look at
external partners.  So, I am interested in the longer term approaches
concerning SAML, or having PKINIT populate the certificate in the TGT.
But of these, in general we don't want our owners/developers of the 5000
applications going anywhere near X.509 or other mechanisms...we will
probably internalize things, one way or another, so that some form of
group membership is available for inspection, and try to keep LoA
enforcement as simple as it can be.

I am just tied up a bit--apologies in advance for being quiet.

Dennis Taylor
NCAD Project
Ph: 301 286-4290; Fax: 301 286-2086

> -----Original Message-----
> From: Henry B. Hotz [mailto:[email-masked]]
> Sent: Thursday, September 06, 2007 3:30 PM
> To: [email-masked]
> Subject: [KAML] Re: Chicago bar-BOF summary
>

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 06 Sep 2007 17:33:01 -0500

> may be involved, from multiple SAML issuers.

One of my concerns with Kerberos in the middle; who is the relying
party? Is it the KDC or is it the service for which a service ticket

I would argue that in the user's view point it is the service.

Today the KDC has ignored any assertions in the cert (or cert chain
if it supports it at all) and has not passed any of this along to the
service.

There are at least two ways to pass this along:

   (1) Pass the cert and chain, then the service can make its own
       authorization decisions,

   (2) have the KDC find these assertions in the certs and pass them
       along in some new SAML.

   (1) is all but transparent to the KDC, and does not require it
       to understand any SAML or any of the asertions, and does not
       lose any information, in that is is passing on *ALL* the
       information it got including non-SAML information in the certs.

   (2) requires the KDC to parse the certs,and repackage the assertions.
       and it may lose other valuable information in the certs.

    Ticket size might be smaller in (1)the in (2)

KDC are for authentication, they are not expected to do authorization
but may add information to allow the service to do the authorization,
therefore I favor (1) over (2).

--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 6 Sep 2007 18:22:54 -0700

> transaction, the group logic is implemented.

So you just want another group added to the PAC to indicate whether  
the PIV card was used or not?  This would not seem to require any  
protocol changes, just a PAC implementation update.

> enforcement as simple as it can be.

So you're preferring kdc-determined SAML assertions (if the above  
isn't sufficient);  Doug's preferring just forwarding the original  
cert;  and I'm voting both ways at once.  ;-)

I don't suppose you have a use case that doesn't just boil down to  
"did they use the PIV card to get these credentials?"?

---

From: Scott Cantor <[email-masked]>
Date: Fri, 07 Sep 2007 01:05:31 -0400

> Question:  Is it possible to create valid SAML tokens in XER?

Everything in SAML is expressed in XML Schema terms. Arguably any XML 
encoding/serialization that fulfills the requirements of the schema and 
prose is still SAML. Arguably.

-- Scott

---

From: Leif Johansson <[email-masked]>
Date: Fri, 07 Sep 2007 09:22:08 +0200

Scott Cantor wrote:
> encoding/serialization that fulfills the requirements of the schema
> and prose is still SAML. Arguably.
Yeah encoding is something which will come up on the radar eventually
but I personally think its more about tools and integration-points and as
such borders on red-herring status from a protocol-design perspective.

    Cheers Leif

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 7 Sep 2007 10:48:07 -0700

> such borders on red-herring status from a protocol-design perspective.

Merely wondering if my objection to XML in this context could be made  
to "go away".  Presume not (reasonably anyway), therefore presume  
it's a red herring.

However  ;-)

Is it conceivable that we could define a standards compliant SAML  
token, that could be produced in XER, that would also be accepted  
outside the Kerberos community?  Given that the answer to the first  
two is yes, I won't believe the answer to the last is yes until  
someone tells me so.

Therefore it's still a red herring.  We now return to our regularly- 
scheduled discussion.

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 7 Sep 2007 13:50:48 -0400

> outside the Kerberos community?

If by accepted you mean "usable with any existing SAML code", the answer is
clearly no.

-- Scott

---

From: Leif Johansson <[email-masked]>
Date: Fri, 07 Sep 2007 20:40:25 +0200

> If by accepted you mean "usable with any existing SAML code", the answer is

I've talked to Love Hörnquist Åstrand (who can speak for himself
actually) - the heimdal lead - about SAML in the kdc (or any other
part of the code for that matter). He was mostly worried about
how the integration could happen safely. I think his position would
be similar to what a developer working on code never touched
by ASN.1 would be: this is a large piece of something I have no
control over and no way to audit.

So yes Scott, it is true that no SAML library supports XER out
of the box today but that is probably a minor problem compared
to figuring out how (say) something like heimdal could depend
on something like opensaml without creating an unmanageable
monster.

These are important things to figure out eventually but we
should probably keep the horse ahead of the cart for now and
concentrate on semantics.

    Cheers Leif

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 07 Sep 2007 14:11:48 -0500

Henry B. Hotz wrote:
> So you just want another group added to the PAC to indicate whether the 
> PIV card was used or not?  This would not seem to require any protocol 
> changes, just a PAC implementation update.
> 
> So you're preferring kdc-determined SAML assertions (if the above isn't 
> sufficient);  Doug's preferring just forwarding the original cert;  and 
> I'm voting both ways at once.  ;-)

Well, I could argue both ways too... If the addition of a LOA group membership
solves your problem, and Microsoft is willing to add it, great, but
unfortunately is a Microsoft only solution.

If one would like to see Kerberos forward on authorization information
that may be in certs or a cert chain, which might be useful to applications
like Sun Access Manager or useful in grid applications, then passing on the
cert chain should be easy.

This would also be useful for anonymous Kerberos, which could accept any
cert from a trusted CA and pass on the cert to the final application,
which could use the cert for authorization.

> 
> I don't suppose you have a use case that doesn't just boil down to "did 
> they use the PIV card to get these credentials?"?

What if you need the FASC-N from the cert? the SubjectAltName with
the OID=2.16.840.1.101.3.6.6?

--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 10 Sep 2007 14:29:10 -0700

> unfortunately is a Microsoft only solution.

I would be happier with this solution if the PAC format were at least  
an informational RFC.  The format is now well known and widely  
implemented, but AFAIK the description document isn't available  
without all the old warnings.  People have also found in practice  
that the PAC scales to an unpleasant size in many real deployments.

> which could use the cert for authorization.

Isn't there a conceptual mis-match between "anonymous Kerberos" and  
including the cert that actually identifies the person anyway?  Not  
sure I understand your use case.

> the OID=2.16.840.1.101.3.6.6?

We don't use the FASC-N, but the point that a cert may include  
information that you don't know that you need until later is still  
valid.  Just because I don't currently see a need for anything beyond  
whether a smart card was used or not, doesn't mean there isn't such a  
need.  In fact I rather suspect there is.  That would argue for  
including the cert.

OTOH there is probably also a need for some information that's not in  
the cert (which is created by NASA), but *is* in our institutional  
LDAP server.  That would argue that some pre-crunched authZ data is  
sufficient since other information is needed for the authorization  
decision anyway.

----

Let me but this back in more non-US-Gov't terms.

What can we say about what authorization information should be in the  
Kerberos ticket?  Speaking off the top of my head (so I may be wrong)  
I would say:

1) The certificate organization may provide information which the  
Kerberos organization does not believe is useful, but which the  
application service's organization wants.  The Kerberos service needs  
to provide essentially everything from the cert.

2) The application service's organization may want to use information  
from some 4th or 5th party's organization in addition to control  
access.  There will be many deployments that need local  
customization.  There are at least two, and frequently 4 or more  
sources of authorization information.  It's infeasible (and maybe  
literally impossible) to provide all information that might be needed.

3) The fragmentation/federation of information needed for the  
complete authorization decision precludes an efficient centralized  
decision.  However providing what information is centrally available  
in the Kerberos ticket is more efficient than requiring a separate  
query for that information.

I think these design comments don't fully resolve things in my mind,  
but I will now vote for just including the user's PKINIT cert (and  
optionally the cert chain) as authorization info.  That's w.r.t. the  
use cases I have in front of me.  I still think there are other use  
cases though.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Wed, 12 Sep 2007 09:12:34 +0200

> without all the old warnings.  People have also found in practice that
> the PAC scales to an unpleasant size in many real deployments.
What we are trying to do here is probably a bit more general than PAC
which afaik
contains information about group membership. By comparison a SAML attribute
assertion is far more portable, based on published standards and equiped
with more
expressive power. In addition SAML is a very short stretch for MSFT to
implement
at least technically.

    Cheers Leif

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 12 Sep 2007 11:15:40 -0700

Jeffrey Altman just posted a link on the krbdev list.  I guess it's  
no longer even nominally proprietary.

http://msdn.microsoft.com/library/en-us/dnkerb/html/MSDN_PAC.asp

On Sep 12, 2007, at 12:12 AM, Leif Johansson wrote:

>> that
> What we are trying to do here is probably a bit more general than  
> PAC which afaik contains information about group membership. By  
> comparison a SAML attribute assertion is far more portable, based  
> on published standards and equiped with more expressive power. In  
> addition SAML is a very short stretch for MSFT to implement at  
> least technically.
>
>     Cheers Leif

---

From: Gerald Beuchelt <[email-masked]>
Date: Thu, 13 Sep 2007 15:32:46 -0400

Yes, this has been out for a while. If I remember correctly, they even 
posted a document that describes all the holes in the PAC that were not 
covered by this article or the old (expired) draft.

<snip>

        PAC Credential Information (PAC_LOGON_INFO)

    PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential
    information for the client of the Kerberos ticket. The data itself
    is contained in a KERB_VALIDATION_INFO structure, which is NDR
    encoded. The output of the NDR encoding is placed in the
    PAC_INFO_BUFFER structure of type PAC_LOGON_INFO.

    typedef struct _KERB_VALIDATION_INFO {
        FILETIME Reserved0;
        FILETIME Reserved1;
        FILETIME KickOffTime;
        FILETIME Reserved2;
        FILETIME Reserved3;
        FILETIME Reserved4;
        UNICODE_STRING Reserved5;
        UNICODE_STRING Reserved6;
        UNICODE_STRING Reserved7;
        UNICODE_STRING Reserved8;
        UNICODE_STRING Reserved9;
        UNICODE_STRING Reserved10;
        USHORT Reserved11;
        USHORT Reserved12;
        ULONG UserId;
        ULONG PrimaryGroupId;
        ULONG GroupCount;
        [size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds;
        ULONG UserFlags;
        ULONG Reserved13[4];
        UNICODE_STRING Reserved14;
        UNICODE_STRING Reserved15;
        PSID LogonDomainId;
        ULONG Reserved16[2];
        ULONG Reserved17;
        ULONG Reserved18[7];
        ULONG SidCount;
        [size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids;
        PSID ResourceGroupDomainSid;
        ULONG ResourceGroupCount;
        [size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP ResourceGroupIds;
    } KERB_VALIDATION_INFO;

    Reserved fields are not defined in this document and are not used in
    the construction of access control tokens.

</snip>

However, note that there is no patent covenant or even simple licensing 
terms for the backend infrastructure, so while implementing these data 
structures might be covered *to the extend that they are documented 
here), the necessary backend infrastructure might require additional 
licensing and royalties.

Best,

Gerald

Henry B. Hotz wrote:
> Jeffrey Altman just posted a link on the krbdev list.  I guess it's no 
> longer even nominally proprietary.
>
>> which afaik contains information about group membership. By 
>> comparison a SAML attribute assertion is far more portable, based on 
>> published standards and equiped with more expressive power. In 
>> addition SAML is a very short stretch for MSFT to implement at least 
>> technically.
>>
>>     Cheers Leif
>

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 13 Sep 2007 12:52:03 -0700

On Sep 13, 2007, at 12:32 PM, Gerald Beuchelt wrote:

> However, note that there is no patent covenant or even simple  
> licensing terms for the backend infrastructure, so while  
> implementing these data structures might be covered *to the extend  
> that they are documented here), the necessary backend  
> infrastructure might require additional licensing and royalties.

I'm not sure what you mean.  Can you give an example of something  
that might require a license?  In my mind (I'm not a lawyer) an  
implementation is either independent, or not.  Since Microsoft  
doesn't publish actual code for any of this an implementation is  
either pirated from unpublished code, or it's independent, isn't it?
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Gerald Beuchelt <[email-masked]>
Date: Thu, 13 Sep 2007 16:55:55 -0400

It is my understanding (and I am also no lawyer!) that the article by 
John Brezak carries a patent license regarding the actual content of the 
document itself.

Now, this document specifies the PAC for Windows 2000, with the 
exception of 18 reserved fields. What it also does not specify is any 
PAC changes in XP, 2003, Vista, or 2008. It also does not specify any 
backend infrastructure (e.g. discovery or resolution services, policy 
tools, or data storage, etc.) that might or might not be covered by 
patents or other intellectual property rights. Also, some of the default 
SIDs in the Windows implementation that are required for evaluating 
group membership (e.g. EVERYONE, etc.) are also not included in this 
document.

In addition, I do seem to remember that Microsoft at some time offered a 
complete description (purportedly including the 18 reserved fields) of 
the PAC that came with a license explicitly prohibiting implementation. 
Since I did not touch this document, I cannot speak to its actual content.
So, as I am not a lawyer, I am quite paranoid when it comes to other 
people's IPR and license terms. Therefore I am just cautioning the use 
of these specifications, since they are (i) old (Windows 2000), (ii) not 
peer-reviewed, and (iii) not published by an established standards 
organization with a clear IPR regime.

Sorry to be such a pain, but if the majority of this group is intend on 
pursuing the NT PAC path, I would suggest that someone approaches 
Microsoft to get clarification about the status of the spec.

Best,

Gerald

Henry B. Hotz wrote:
>> licensing terms for the backend infrastructure, so while implementing 
>> these data structures might be covered *to the extend that they are 
>> documented here), the necessary backend infrastructure might require 
>> additional licensing and royalties.
>
> I'm not sure what you mean.  Can you give an example of something that 
> might require a license?  In my mind (I'm not a lawyer) an 
> implementation is either independent, or not.  Since Microsoft doesn't 
> publish actual code for any of this an implementation is either 
> pirated from unpublished code, or it's independent, isn't it?

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 13 Sep 2007 16:24:11 -0500

> group membership (e.g. EVERYONE, etc.) are also not included in this 

There was also the IETF:
draft-brezak-win2k-krb-authz-01.txt
from October 2002, I still have a copy, but does not address XP, 2003
or Vista.

Samba has been working on using the PAC created by Windows, and trying
to get XP to use a Samba/Heimdal created PAC. So they may have addressed
a lot of these issues.

http://samba.org/ftp/unpacked/trunk-cluster/source/libads/authdata.c
referes to KERB_VALIDATION_INFO

> Microsoft to get clarification about the status of the spec.

I don't think trying to add something to the Microsoft PAC is a good idea.
But if they add something "Level of assurance" to the PAC using it is
another story.

Adding another auth_data element of SAML does not require the Microsoft PAC.

--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 13 Sep 2007 18:57:59 -0700

Anyone know the compatibility of the PAC with other authorization  
data?  DCE authN data is, I presume, ASN1 encoded.  I think the PAC  
is just a memory dump.  A SAML token is XML.

Even if we ignore DCE, can we guarantee that an XML blob and the PAC  
can coexist if needed?  I think I'm seeing some provisions for that,  
but want to confirm.

 ><I don't have anything to add to Doug's comments.>>

On Sep 13, 2007, at 2:24 PM, Douglas E. Engert wrote:

> Gerald Beuchelt wrote:
>> It is my understanding (and I am also no lawyer!) that the article  
>> by John Brezak carries a patent license regarding the actual  
>> content of the document itself.
>> exception of 18 reserved fields. What it also does not specify is  
>> any PAC changes in XP, 2003, Vista, or 2008. It also does not  
>> specify any backend infrastructure (e.g. discovery or resolution  
>> services, policy tools, or data storage, etc.) that might or might  
>> not be covered by patents or other intellectual property rights.  
>> Also, some of the default SIDs in the Windows implementation that  
>> are required for evaluating group membership (e.g. EVERYONE, etc.)  
>> are also not included in this document.
>
> There was also the IETF:
>> In addition, I do seem to remember that Microsoft at some time  
>> offered a complete description (purportedly including the 18  
>> reserved fields) of the PAC that came with a license explicitly  
>> prohibiting implementation. Since I did not touch this document, I  
>> cannot speak to its actual content.
>> So, as I am not a lawyer, I am quite paranoid when it comes to  
>> other people's IPR and license terms. Therefore I am just  
>> cautioning the use of these specifications, since they are (i) old  
>> (Windows 2000), (ii) not peer-reviewed, and (iii) not published by  
>> an established standards organization with a clear IPR regime.
>> Sorry to be such a pain, but if the majority of this group is  
>> intend on pursuing the NT PAC path, I would suggest that someone  
>> approaches Microsoft to get clarification about the status of the  
>> spec.
>
>>>> implementing these data structures might be covered *to the  
>>>> extend that they are documented here), the necessary backend

---

From: Gerald Beuchelt <[email-masked]>
Date: Fri, 14 Sep 2007 08:16:23 -0400

One issue we might run into is the actual character encoding - is there 
a reasonable gurantee that UTF-8 is supported? Thinking along the lines 
of ASN.1 and XER encoding, we might at least want to consider FastInfo 
(ITU-T X.891 - ISO/IEC 24824-1) which is a public standard for encoding 
XML in binary form.

As far as combining multiple authdata tokens go: I can see how this 
could possibly work by adding additional data after the NT PAC. But this 
would require the Windows implementation to ignore data appended after 
the PAC itself - one would have to try this out and see if it breaks 
anything.

Other than that, I seems to remember Nico Williams' framework for 
stacking payload on top of the existing Kerberos data. What eve happened 
to this?

BTW: Nico and I had been floating a few ideas about a SAML/GSSAPI 
combination in 2005 to some folks in the SAML world, as well as the 
IETF. Here are some slides describing our ideas in an overview 
presentation: 
http://www.idealliance.org/proceedings/xml05/slides/beuchelt.pdf

Maybe some of that is still recoverable.

Best,

Gerrt

Henry B. Hotz wrote:
> data?  DCE authN data is, I presume, ASN1 encoded.  I think the PAC is 
> just a memory dump.  A SAML token is XML.
>
>>> by John Brezak carries a patent license regarding the actual content 
>>> of the document itself.
>>> people's IPR and license terms. Therefore I am just cautioning the 
>>> use of these specifications, since they are (i) old (Windows 2000), 
>>> (ii) not peer-reviewed, and (iii) not published by an established 
>>> standards organization with a clear IPR regime.
>>> Sorry to be such a pain, but if the majority of this group is intend 
>>> on pursuing the NT PAC path, I would suggest that someone approaches

---

From: Gerald Beuchelt <[email-masked]>
Date: Fri, 14 Sep 2007 08:34:28 -0400

Douglas E. Engert wrote:
>> John Brezak carries a patent license regarding the actual content of 
>> the document itself.
>>
>> patents or other intellectual property rights. Also, some of the 
>> default SIDs in the Windows implementation that are required for 
>> evaluating group membership (e.g. EVERYONE, etc.) are also not 
>> included in this document.
>>
>
> There was also the IETF:
(Disclaimer: I have not been actively working on these subjects for a 
few years - please be patient with me and correct my failing memory :-))

The samba 3 domain model is distincly different from the AD/Windows 
200x  and NT4 domain models in that it is completely non-interoperable: 
you can not mix samba domain controllers into an AD or NT4 domain, or 
vice versa. The now-in-alpha samba 4 tries to address this - I will 
probably take a closer look at where they are at this point in time.

>> offered a complete description (purportedly including the 18 reserved 
>> fields) of the PAC that came with a license explicitly prohibiting 
>> implementation. Since I did not touch this document, I cannot speak 
>> to its actual content.
Agreed.

> Adding another auth_data element of SAML does not require the 
Assuming that Windows (and other Kerb implementations) ignore data after 
the PAC, yes?

Best,

Gerald

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 17 Sep 2007 10:05:05 -0500

Henry B. Hotz wrote:
> Anyone know the compatibility of the PAC with other authorization data?  
> DCE authN data is, I presume, ASN1 encoded.  I think the PAC is just a 
> memory dump.  A SAML token is XML.
> 
> Even if we ignore DCE, can we guarantee that an XML blob and the PAC can 
> coexist if needed?  I think I'm seeing some provisions for that, but 
> want to confirm.

Yes. RFC 4120 section 7.5.4 defines the Authorization Data Types.
There are OSF-DCE(64) SESAME(65), AD_OSF_DCE_PKI_CERTID(66)
AD_WIN2K_PAC(128) and AD_ETYPE_NEGOTAION(129). Others can be added
but the Authorization Data Types are not listed in IANA.

The PAC (128) is wrapped in a AD_IF_RELEVANT(1) which implies it is
optional.

--