Subject: [KAML] LoA proposal

From: "Paul Rabinovich" <[email-masked]>
Date: Wed, 19 Sep 2007 10:55:07 -0400

Hello,

	In the attached document I attempted to summarize LoA-related traffic in this and krb lists and to sketch a proposal. From Sam's e-mail it looks like we need to produce an I-D by Oct 1. I'll start right away on putting the proposal in the attached document into the I-D format, and will send it out in the next couple of days.

	Best regards,
	PR

Paul Rabinovich | Software Architect | EXOSTAR LLC
13530 Dulles Technology Dr., Suite 200, Herndon, VA 20171
PH +1.703.793.7808 | FAX +1.703.793.7741

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

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 19 Sep 2007 12:04:08 -0700

Not sure there isn't a bit of scope creep in the proposal.  Seems to  
me the scope is providing authorization information based on how the  
original authentication was done, not to define new authentication  
mechanisms per-se.  We need to be careful what we say about OTP and  
SAML authentication in the absence of approved RFC's or other standards.

I think we can "agree to disagree" on what what kind of authorization  
information is needed/appropriate based on prior discussion.  Let me  
suggest a different organization;  we should define two kinds of  
information:

1) RAW information, which provides details about how the original  
authentication was done.

2) EVALUATED information, which provides a policy judgement about the  
quality/strength/implications of the authentication method.

Examples of RAW information would be the kind of OTP token used, or  
the cert (and/or cert path) for a PKINIT authentication.  If a SAML  
token caused the ticket to be issued then that SAML token might be  
included.

Examples of EVALUATED information would be a SAML token asserting the  
SP800-63 LoA of the authentication, or the PAC data defined by  
Microsoft.  DCE authorization info probably also qualifies (just to  
keep an ASN1-encoded type in the mix).

All of the above are optional, based on local policy requirements.   
Any/all of the above examples MUST be includable without conflict.   
Not that it would have been a problem, but the above clearly  
distinguishes whether a SAML token generated the authentication, or  
the authentication generated the SAML token, and both SAML tokens  
might be included.

I'd propose that the EVALUATED information gets included/excluded  
based on the same mechanism used by Microsoft to include/exclude the  
PAC.  I'd propose the RAW data is excluded by default, but included  
if requested by some other mechanism.

On Sep 19, 2007, at 7:55 AM, Paul Rabinovich wrote:

>
> 	Hello,
>
> 	In the attached document I attempted to summarize LoA-related  
> traffic in this and krb lists and to sketch a proposal. From Sam's  
> e-mail it looks like we need to produce an I-D by Oct 1. I'll start  
> right away on putting the proposal in the attached document into  
> the I-D format, and will send it out in the next couple of days.

----

> 11. The “simple” profile will support forwarding of authentication  
> info defined as a CHOICE:
>
> -       User ID/password: an ENUM or OCTET STRING saying “user ID/ 
> password”.
> -       X.509 certification path: an ENUM or OCTET STRING saying “X. 
> 509 path” plus a SEQUENCE/SET of certificates.
> -       X.509 end-entity certificate only: an ENUM or OCTET STRING  
> saying “X.509 single cert” plus the certificate.I'd vote for an  
> ENUM on space efficiency grounds.

I'd vote for ENUM on space efficiency grounds.
> -       OTP: an ENUM or OCTET STRING saying “OTP” (QUESTION: are  
> there any important flavors/subdivisions?)
Take a look at section 5.1.1 of draft-ietf-krb-wg-kerberos-sam-03.txt.
> -       QUESTION: Is multifactor authentication of interest?
Absolutely.  If nothing else the use of multifactor authentication is  
needed for the higher levels in SP800-63, so it's already implied.   
Do we need to explicitly define a way to carry the number of factors  
used in the original authentication?  I don't think so, but I may be  
wrong.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Paul Rabinovich" <[email-masked]>
Date: Wed, 19 Sep 2007 16:01:23 -0400

Henry,

	My comments are inline.

	Regards,
	PR

-----Original Message-----
From: Henry B. Hotz [mailto:[email-masked]] 
Sent: Wednesday, September 19, 2007 3:04 PM
To: Paul Rabinovich
Cc: [email-masked]
Subject: Re: [KAML] LoA proposal

[PR] I do not propose to introduce support for new authentication
mechanisms. The document tries to document existing mechanisms used by Kerb
and, perhaps, those probable to be used in the medium term. To my knowledge
MS already issues Kerb tickets based on WS-Federation assertions with SAML
tokens consumed by MS ADFS.

[PR] Perhaps, it's not clear from the document but the idea is for the
ticket to have one or more auth info's, one per profile. So, a TGT/ST may
have two profiles, one NIST (EVALUATED), one Simple (RAW) (or any number, as
we defined more profiles). It seems to me this makes it safer from future
evolution perspective as more profiles can be added (i.e., there may be many
EVALUATED profiles). KDC will have to be configured with a required set of
profiles (i.e., all STs in the realm will contain the same set).

----

> 11. The "simple" profile will support forwarding of authentication  
> -       User ID/password: an ENUM or OCTET STRING saying "user ID/ 
> password".
> -       X.509 certification path: an ENUM or OCTET STRING saying "X. 
> 509 path" plus a SEQUENCE/SET of certificates.
> saying "X.509 single cert" plus the certificate.I'd vote for an  

> -       OTP: an ENUM or OCTET STRING saying "OTP" (QUESTION: are

---

From: Leif Johansson <[email-masked]>
Date: Fri, 21 Sep 2007 10:12:50 +0200

> 	In the attached document I attempted to summarize LoA-related traffic in this and krb lists and to sketch a proposal. From Sam's e-mail it looks like we need to produce an I-D by Oct 1. I'll start…

Looks like a good summary of the discussion we've had on
the list and elsewhere. I do think we need to start at a lower
level and produce a clean problem-statement-draft before
we get into a discussion about the bits and where they go.

I'll try to produce some text too.

    Cheers Leif