Subject: Re: [abfab] draft-wei-abfab-fcla-01 is uploaded, please review it

From: [email-masked]
Date: Tue, 1 Nov 2011 23:02:10 +0800

Hi, Alejandro

  SAML/AAA is the underlying mechanisms for authentication in this draft. 
  In step 3, RP -> IdP : <samlp:AuthnRequest>, It MAY require some 
addtional infomation, such as NAI - which is used to identify subject, 
security token - which is used to assure the subject is the holder of the 
key. Then IdP construct assertion 
   step 4, IdP -> RP : <samlp:Response>, which contains assertion 
information.

The credential (e.g. MSK) is NOT transferred directly from IdP to RP in 
this draft, It is SAML assertion that is trasported between them. The two 
cited references define SAML/AAA mechanisms, but I am NOT sure whether 
they consider this case.

Thanks for your comments.

------------
Yinxing Wei 

Alejandro Perez Mendez <[email-masked]> 
发件人:  [email-masked]
2011/10/31 20:56

收件人
[email-masked]
抄送

主题
Re: [abfab] draft-wei-abfab-fcla-01 is uploaded, please review it

Hi Yinxing,

After reading the draft, I have a doubt concerning with your proposal.  In 
section 4, step 3, the text says:
When RP receieves the request from UE, it checkes whether the
       credential is avialable.  If not, RP initiates AAA request to
       retrieve credential from IdP [I-D.ietf-abfab-aaa-saml]
       [I-D.jones-diameter-abfab].

It is not clear to me how credentials (MSK or similar) are transported to 
the RP, since it seems (due to the references you cite) that it is done 
through SAML.
Can you provide further details on this, please?

Regards,
Alejandro

Hi, All 

  The -01 version of draft-wei-abfab-fcla is uploaded, please follow the 
link http://www.ietf.org/id/draft-wei-abfab-fcla-01.txt to open it. 

  Please review it, any comments are welcome! 

Filename:                  draft-wei-abfab-fcla
Revision:                  01
Title:                                   Federated Cross-Layer Access
Creation date:                  2011-10-31
WG ID:                                   Individual Submission
Number of pages: 9

Abstract:
  Network stratum and application stratum form a federation to
  faciliate user's access.  Network operator acts as Identity Provider
  (IdP), and application reuses underlying network's security
  capabilities to simlify application's access.  This document is to
  introduce such federated cross-layer access use case and message
  flows. 

------------ 
Yinxing Wei
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

_______________________________________________
abfab mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/abfab

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 01 Nov 2011 18:28:57 +0100

Hi Yinxing,

> security token - which is used to assure the subject is the holder of
> the key. Then IdP construct assertion
> The credential (e.g. MSK) is NOT transferred directly from IdP to RP
> in this draft, It is SAML assertion that is trasported between them.
> The two cited references define SAML/AAA mechanisms, but I am NOT sure
> whether they consider this case.

If the MSK or derived key is not transferred to the RP, how can it
verify the identity of the UE? That's the point that is not clear to me
in the flow. You say that the credential used by the UE is derived from
the MSK. Then the acceptor (the RP) has to be able to verify somehow
this credential, either:

1) It obtains the credential from the AAA which took place in the
authentication
2) It delegates the verification of the credential to the AAA, but in
this case, you have to define the interface between the RP and the AAA
for this purpose, since as you commented, SAML is not indicated for that.

Regards,
Alejandro

> *Alejandro Perez Mendez <[email-masked]>*
> After reading the draft, I have a doubt concerning with your proposal.
> In section 4, step 3, the text says:
> It is not clear to me how credentials (MSK or similar) are transported
> to the RP, since it seems (due to the references you cite) that it is
> done through SAML.
> link _http://www.ietf.org/id/draft-wei-abfab-fcla-01.txt_to open it.
>
> ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated to
> maintain secrecy and are not permitted to disclose the contents of
> this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the originator of the message. Any views expressed in this message are
> those of the individual sender.
> [email-masked] <mailto:[email-masked]>
> _https://www.ietf.org/mailman/listinfo/abfab_